Hast du zufällig irgendwie nen PDF oder irgendwie nen Link mit nem Artikel der den vorgang von so ner Browserengine näher beschreibt? Interessiert mich schon etwas detailierter, ich hab nur bis jetzt nie ne gute Beschreibung gefunden.
-
-
Hmm. Nö. Konkret habe ich da nichts. Das war jetzt aus meinem Allgemeinwissen über die Arbeitsweise von Browsern gekramt. Nicht, dass das, was ich gesagt habe, nicht stimmt, aber Quellen kann ich dir jetzt gerade keine nennen. Sollte mir aber was über den Weg laufen, werde ich an dich denken.
Beitrag editiert:
[…] Das Einzige, was ich jetzt auf die Schnelle gefunden habe, ist das hier: http://www.mozilla.org/newlayout/doc...4/master.xhtmlRefining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”Kommentar
-
Mh ok in soweit wars mir auch schon klar, dachte du hast da vielleicht mal was Detailierteres gelesen
Mal sehn ob ich irgendwo nen Buch dazu finde.
Kommentar
-
Woher nimmst du diese Info?Zitat von Manko10 Beitrag anzeigen
Ja, und genau das nennt sich Parsen.Das äußert sich meistens darin, dass tbodys in Tabellen eingefügt werden, nicht geschlossene HTML-Tags geschlossen werden, einzelne <p>-Angaben zu einem vollständigen <p>…</p> vervollständigt werden und eben auch, dass Angaben wie checked zu checked="checked" geändert werden oder genau umgekehrt (kenne aber keine Engine, die das so macht, vielleicht der IE?). Außerdem wird noch der Whitespace angeglichen. Das kannst du vor allem sehen, wenn du im Firefox mal per Firebug den Code ansiehst. Was du da zu sehen bekommst, ist nicht das, was du geschrieben hast, sondern das, was Gecko daraus gemacht hat.
Ein HTML-Dokument wird in einen DOM-Baum überführt. Dabei wird u.a. Fehlerkorrektur durchgeführt. In HTML5 ist diese großteils standardisiert, bei allem davor durfte jeder Browser weitgehend seine eigene Vorstellung davon umsetzen.
Das hat nichts mit irgendeinem Preprocessor zu tun, das ist Parsen.
Das stimmt, das ist mit XML nicht mehr möglich.[...] aber dafür wird bei HTML auch (im Gegensatz zu XML) schon während des Parsevorgangs die sichtbare Seite aufgebaut.
Aus genau dem gleichen Grund entfällt bspw. auch die Möglichkeit, mittels document.write Einfluss auf den Aufbau des Dokumentes zu nehmen.[SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]Kommentar
-
Okay, ich gebe zu, dass Präprozessor vielleicht nicht ganz richtig ist. Sagen wir es so:Das hat nichts mit irgendeinem Preprocessor zu tun, das ist Parsen.
der geschriebene HTML-Code wird in eine für die weiteren Verarbeitungsschichten lesbare Form gebracht (geparst). Dies wird dann an den Renderer weiter gegeben, der mit Hinzunahme der verfügbaren Styles (welche natürlich ebenfalls vorher geparst wurden) in eine Darstellbare Form gebracht. Der erstellte DOM-Baum wird schließlich der weiteren Verarbeitung durch die Scripting-Engine bereitgestellt. Bei diesem Schritt kann ich jedoch nicht genau sagen, wann das passiert, ob vor oder nach dem Eingriff der Rendering-Engine, ich würde sagen danach. Dazu kann ich aber nichts Genaues sagen.Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”Kommentar
-
Falls der Test hier was taugt, beginnt zumindest der Firefox die Seite (und auch die Tabelle) zu rendern, bevor alle Daten da sind.
PHP-Code:<?php header('Content-Type: application/xhtml+xml; charset=utf-8'); ?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >
<head><title></title></head>
<body style="background: green;">
<table>
<tr><th style="background: red;">test</th></tr>
<?php flush(); sleep(3); ?>
<tr><td>blub</td></tr>
<!--</table>-->
</body>
</html>Kommentar
-
Nein, DOM ist nicht erst für's Scripting relevant.Zitat von Manko10 Beitrag anzeigen
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.Bei diesem Schritt kann ich jedoch nicht genau sagen, wann das passiert, ob vor oder nach dem Eingriff der Rendering-Engine, ich würde sagen danach.
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.[SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]Kommentar
-
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.Bereits vor dem Rendern wird das DOM aufgebautAuch hier habe ich nichts anderes behauptet.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.
Ich weiß.Rendering ist im HTML/CSS-Umfeld die Visualisierung des DOM.
Der Artikel sieht interessant aus. Werde ich mir morgen einmal zu Gemüte führen. Vielen Dank.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.comRefining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”Kommentar
-
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.Zitat von Manko10 Beitrag anzeigen
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.“[SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]Kommentar
-
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.)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.Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”Kommentar
Kommentar