mermshaus

Falls der Test hier was taugt, beginnt zumindest der Firefox die Seite (und auch die Tabelle) zu rendern, bevor alle Daten da sind.

__________________
Blog | Buch | Kaloa

Mister Ad

ChrisB

Nein, DOM ist nicht erst für's Scripting relevant.

Bereits vor dem Rendern wird das DOM aufgebaut - aus dem Quelltext, der hierzu geparst wird.
Die Darstellung erfolgt bereits auf Basis des DOM - dieses enthält die „fertige“ Beziehung der Elemente untereinander, und in das Ermitteln dieser Beziehungen ist die Fehlerkorrektur während des Parsens bereits eingeflossen.

Wenn du ein TBODY-Element zu Gesicht bekommst, das nicht explizit im Quellcode steht, oder auch Whitespace zwischen den Elementen in Form von untersuchbaren Textknoten vorliegen hast - das ist bereits DOM.

Rendering ist im HTML/CSS-Umfeld die Visualisierung des DOM.
Dass das DOM anschliessend noch mal verändert wird, ist natürlich nicht ausgeschlossen (innerHTML, appendChild, etc.); dann muss die Rendering Engine erneut ran, erneut das zu diesem Zeitpunkt aktuelle DOM visualisieren, unter Zuhilfenahme aller vorliegenden CSS-Regeln etc.


Recht aufschlussreich bzgl. der einzelnen Vorgänge und (zeitlichen) Abläufe vom Quellcode zur letztendlichen Darstellung auf dem Monitor (oder ggf. anderem Ausgabemedium) ist m.E. der Artikel Rendering: repaint, reflow/relayout, restyle / Stoyan's phpied.com
Die dort vermittelten Informationen sind auch hinsichtlich Performance interessant, wenn wie angesprochen das DOM nachträglich und ggf. wiederholt manipuliert wird.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

Manko10

Ich sehe, wir sind uns einig.

Jap. habe ich auch nicht dementiert. Da wäre ja auch sonst nichts zu rendern. Ich habe nur darüber spekuliert, ab wann das DOM der Scripting-Engine zur Verfügung steht. Und dass DOM etwas anderes ist als Browserscripting, ist wohl uns beiden klar.Auch hier habe ich nichts anderes behauptet.
Ich weiß.

Der Artikel sieht interessant aus. Werde ich mir morgen einmal zu Gemüte führen. Vielen Dank.

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

ChrisB

Generell gilt hier beim Verarbeiten von HTML über den Tag-Soup-Parser: Innerhalb von SCRIPT-Elementen hast du auf alles Zugriff, was „vor“ diesen im Quelltext auftauchte bzw. begonnen wurde.

Bspw. das Setzen eines classNames für BODY, direkt hinter dem Starttag von BODY, ist gängige Praxis, um mit der Anwendung von Stylesheet-Regeln möglichst früh im Rendering-Vorgang darauf reagieren zu können, ob JavaScript aktiviert ist oder nicht (Verfahren dürfte wohl bekannt sein).

Über die ID oder auch sonstige Zugriffsmethoden hast du ebenfalls bereits auf alles Zugriff, was davor kam*. Methoden wie getElementsByTagName liefern zu einem solchen Zeitpunkt auch alle die Elemente (und nur die), die bereits vor dem jeweiligen SCRIPT-Element auftauchten.

Daraus resultiert auch die hinsichtlich Seitenperformance und Ladeverhalten aktuell geltende (Pauschal-)Empfehlung (Google Page Speed, YSlow, weitere), Scripte möglichst nicht im HEAD, sondern direkt vor dem Ende von BODY zu platzieren. Damit blockieren sie einerseits nicht das Laden weiterer externer Ressourcen (bspw. CSS), und haben andererseits auch sofort Zugriff auf das DOM, ohne bspw. wie bei onload auch auf das Fertigladen sämtlicher Bilder warten zu müssen. In dem Zeitraum kann man ja mit DOM-Manipulationen, die sich optisch auswirken, schon mal beginnen - dann braucht nichts „herumzuhüpfen“, wenn die Bilder erst mal fertig geladen sind.
(Wenn im Script auch Zugriff auf die sich aus CSS ergebenden Maße, Position etc. von Elementen von Nöten ist, dann empfiehlt sich allerdings das Warten auf documentReady; wie ich letztens erfahren habe, feuern das so gut wie alle aktuellen Browser wohl erst dann, wenn auch das CSS geladen und angewendet wurde - Ausnahme [noch]: Opera.)


Das alles gilt wohlgemerkt für HTML bzw. die Anwendung eines Tag-Soup-Parsers - bei XML m.W. nicht mehr.


* Vorsicht ist hier im IE geboten: Wenn aus einem SCRIPT-Element heraus das Element, das dieses SCRIPT enthält, manipuliert werden soll, was dessen „Sub-DOM“, also die in ihm liegenden Elemente betrifft (bspw. per innerHTML="..."), quitiert der IE das oft mit dem schwer nachvollziehbaren Fehler „Diese Seite kann nicht angezeigt werden.“

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

Manko10

Das ist mir bewusst. Allerdings bezieht sich dies genau wie bei Bildern auch auf externe inhalte, die a) erst vom Server geladen und dann b) verarbeitet werden müssen. Ich bezog mich jetzt hier direkt auf das DOM, ob dieses auch nach und nach zur Verfügung gestellt wird oder alles auf einmal. Aber wenn ich darüber nachdenke, so komme ich zu dem Schluss, dass auch dieses (bei HTML, nicht bei XML) nach und nach bereitgestellt wird (ich kann schließlich schon auf frühere, aber vor DOMDocumentReady nicht auf spätere Elemente zugreifen.)

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”