Mathias Bigge: warum HTML pervers ist und XHTML nicht...

Beitrag lesen

Hallo Michael,

danke für Deine ausführliche Antwort.

Eben das ist eine Strategiefrage. Und die könnte beispielsweise _auch_
davon abhängig gemacht werden, ob (und welcher!) DOCTYPE in einem
Dokument drin steht (nach dem Motto: HTML 4.01 schreiben auch die DAUs
rein, da parsen wir mal defensiv und langsam; wer XHTML 1.1 macht,
weiß schon eher, was er tut, und wird dann auch die Strafe des zwei-
maligen Parsens in Kauf nehmen, falls das Dokument eben doch nicht
valide ist). Irgendwie in diese Richtung müssen die M$IE-Programmierer
bei Quirks-Mode und Compliant Mode ja auch gedacht haben.

Ich befürchte auch, dass die Microsoft-Leute wieder einmal früh die Zeichen der Zeit erkannt haben, und dass ihr Eiertanz bezüglich der Normen nicht auf Unfähigkeit beruht, sondern erfolgsorientierte Machtstrategie ist.

Natürlich gibt es performance-relevante Aspekte im Bereich HTML,
etwa die Größenangabe für Bilder oder dergl.
Eben.

Ich denke, wir sind einer Meinung, dass die wichtigsten Performance-Aspekte bei HTML für viele Sites die Größenangaben bei Bildern und Tabellen sind, vielleicht noch die unnötige Komplexität mancher Tabellenkonstruktionen selbst. Eine interessante Frage ist für mich, welche Beschleunigung man durch Verbesserung des übrigen HTML-Codes erreichen kann. Ich wundere mich oft, in welchem Tempo die Standardbrowser selbst den absurdesten Befehlswust verarbeiten, etwa von Frontpage, Word, oder GoLive generierte Seiten. Selbst die fast schon epischen JS-Konstrukte von Adobe werden meist in 0,Nix gefressen. Natürlich gibt es Ausnahmen, etwa die Textmassen in SELFHTML oder anderen Tutorien, wo man vielleicht durch eine Formatierung jedes einzelnen Tags Performanceprobleme hinkriegen könnte ;-)

Ich bin mir aber nicht sicher, ob diese Kriterien mit der
Validierungsproblematik deckungsgleich sind.

Immerhin sind "height" und "width" für Bilder Pflichtangaben in gewissen
HTML-Dialekten - während sie das für Tabelle nicht sind (und auch nicht
sein dürfen). Dies halte ich für eine explizite Performance-Optimierung
des Sprachstandards, der an dieser Stelle die Angabe einer wahrschein-
lich (!) konstanten Information erzwingt, um das Rendering zu beschleu-
nigen - und dabei in Kauf nimmt, daß man nicht mehr per CGI etc. Bilder
dynamischer (Anzeige-)Größe in valide HTML-Seiten einsetzen kann.

Stimmt, hier läuft die Entwicklung der Standards in die richtige Richtung. Die Sache mit den dynamischen Bildern habe ich noch nicht ganz verstanden. Bei der Ausgabe sind sie doch dann schon statisch, wenn man die Tags mitanpasst, oder verstehe ich Dich da falsch?

Viele Grüße
Mathias Bigge