nicht angemeldet
Hi Mathias,
Eher so: "Um ein (fehlerhaftes) HTML-Dokument zu interpretieren, muß
ein Parser viel mehr arbeiten und kann das Ergebnis viel später
anzeigen, als um ein (fehlerhaftes) XHTML-Dokument zu interpretieren."
Prinzipiell gebe ich Dir Recht, dass es schneller sein müsste, wenn
_alle_ Websites standardkonform wären. Aber so bin ich mir nicht ganz
sicher, ob es stimmt, denn dann müsste es ja ein eigenes Rendering für
valide Seiten geben.
Genau.
Zunächst einmal ist es ja eine Strategiefrage der Browser-Implementation,
wie man den Parser schreibt - ob der beispielsweise so optimiert ist,
daß er korrekt aufgebaute Dokumente in einem Rutsch parsen und für
fehlerhaft aufgebaute den Parsing-Versuch abbrechen und mit einem
fehlertoleranteren Parser ein zweites Mal von vorne anfangen muß oder
ob von vorn herein der fehlertolerantere, aber langsamere Parser ein-
gesetzt wird, der ggf. mehr Verwaltungsinformationen mitschleppen muß.
Ich kann mir durchaus vorstellen, einen Browser so zu schreiben, daß
er korrekte Dokumente schneller parsen kann als fehlerhafte.
(Ob das in der aktuellen WWW-Umwelt schon eine gute Idee wäre, sei
dahingestellt; es wäre aber eine großartige didaktische Idee, genau
wie die Ausgabe von Fehlermeldungen bei invaliden Dokumenten. Würde
Amaya beispielsweise Frames und JavaScript unterstützen und damit
im vollen Umfang markttauglich sein, dann könnte der W3C auf diese
Weise durchaus Seitenautoren dazu animieren, validen Code zu produ-
zieren; bei Mozilla bezweifele ich die Deckungsgleichheit der Moti-
vation mit derjenigen des W3C.)
Ich vermute aber, dass die Browser bei jeder Seite nicht mit optimaler
Performance vorgehen, sondern mit einem System, dass auch gewisse
Fehler/Ungenauigkeiten auffängt, auch wenn das für eine valide Seite
nicht nötig wäre.
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.
Ein Nebenaspekt ist, dass, vom Selfforum und dergleichen "Bleiwüsten"
mal abgesehen, das Rendering der HTML-Tags der geringste Zeitanteil
beim Darstellen von Websites sein dürfte. Korrigier mich, wenn ich
da falsch liege.
Geschachtelte Tabellen ohne Breitenangabe zu rendern kann ein furcht-
bar teures rekursives Backtracking-Verfahren erzwingen.
Mich wundert gar nicht, daß Netscape 4 an dieser Stelle in die Knie geht
... eher schon, daß die modernen Browser das alle wirklich gut können
(zumal das mit CSS ja nicht unbedingt einfacher geworden ist).
Natürlich gibt es performance-relevante Aspekte im Bereich HTML,
etwa die Größenangabe für Bilder oder dergl.
Eben.
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.
Viele Grüße
Michael