Ein Leser hat mich kürzlich gefragt, was das DOM sei. Er sagte, er habe es erwähnt und angedeutet gehört, sei sich aber nicht sicher, ob er es wirklich verstehe.
Das können wir ändern.

Aber das HTML, das Sie schreiben, wird vom Browser geparst und in das DOM umgewandelt.

Quelltext anzeigen zeigt Ihnen nur das HTML, aus dem diese Seite besteht. Es ist wahrscheinlich genau das HTML, das Sie geschrieben haben.
Es könnte wie ein anderer Code aussehen, wenn Sie zum Beispiel in Vorlagendateien einer Backend-Sprache arbeiten und die kompilierte HTML-Ausgabe nicht oft betrachten. Oder es gibt einen „Build-Prozess“, der stattfindet, nachdem Sie Ihr HTML geschrieben haben und der Code auf der Live-Website veröffentlicht wird. Vielleicht ist dieses HTML komprimiert oder anderweitig verändert.
Quelltext anzeigen ist eigentlich ein bisschen seltsam. Die einzigen Leute, die sich diesen Code ansehen würden, sind Entwickler, und alle großen Browser haben mittlerweile integrierte Entwicklertools. Es hat wahrscheinlich seinen Nutzen überschritten.

Wenn Sie im Panel der von Ihnen verwendeten DevTools die Dinge betrachten, die wie HTML aussehen, ist das eine visuelle Darstellung des DOM! Wir haben es gemacht!

Nun, ja, das tut es. Es wurde direkt aus Ihrem HTML erstellt, erinnern Sie sich. In den meisten einfachen Fällen sieht die visuelle Darstellung des DOM genauso aus wie Ihr einfaches HTML.
Aber es ist oft nicht dasselbe…
Wann unterscheidet sich das DOM vom HTML?
Hier ist eine Möglichkeit: Es gibt Fehler in Ihrem HTML, und der Browser hat sie für Sie behoben. Nehmen wir an, Sie haben ein <table>-Element in Ihrem HTML und lassen das erforderliche <tbody>-Element weg. Der Browser fügt einfach dieses <tbody> für Sie ein. Es wird im DOM vorhanden sein, sodass Sie es mit JavaScript finden und mit CSS gestalten können, auch wenn es nicht in Ihrem HTML vorhanden ist.
Der wahrscheinlichste Fall ist jedoch…
JavaScript kann das DOM manipulieren
Stellen Sie sich vor, Sie haben ein leeres Element wie dieses in Ihrem HTML
<div id="container"></div>
Später in Ihrem HTML gibt es ein kleines Stück JavaScript
<script>
var container = document.getElementById("container");
container.innerHTML = "New Content!";
</script>
Selbst wenn Sie kein JavaScript kennen, können Sie dieses Stück Code nachvollziehen. Auf dem Bildschirm sehen Sie Neuer Inhalt! statt nichts, denn dieser leere div wurde mit etwas, nun ja, neuem Inhalt gefüllt.
Wenn Sie DevTools verwenden, um die visuelle Darstellung des DOM zu überprüfen, sehen Sie
<div id="container">New Content!</div>
Was sich von Ihrem ursprünglichen HTML oder dem unterscheidet, was Sie in Quelltext anzeigen sehen würden.
Ajax und Templating
Lassen Sie uns hier nicht zu sehr ins Detail gehen, aber ich wette, Sie können sich vorstellen, dass, wenn Sie Ajax verwenden würden, um Inhalte von anderswo zu holen und auf die Seite zu bringen, das DOM ganz anders sein wird als Ihr ursprüngliches HTML. Dasselbe gilt für das Laden von Daten einer Art und die Verwendung von Client-Side-Templating.
Versuchen Sie, Gmail aufzurufen und den Quelltext anzuzeigen. Es ist nur ein Haufen Skripte und Daten vom ursprünglichen Seitenaufruf. Kaum wiedererkennbar im Vergleich zu dem, was Sie auf dem Bildschirm sehen.
JavaScript vs. das DOM
JavaScript ist eine Sprache, die der Browser liest und mit der er Dinge tut. Aber das DOM ist der Ort, an dem diese Dinge geschehen. Tatsächlich ist vieles von dem, was Sie vielleicht als „JavaScript-Ding“ bezeichnen würden, genauer gesagt eine „DOM-API“.
Zum Beispiel können wir JavaScript schreiben, das auf ein mouseenter-Ereignis auf einem Element wartet. Aber dieses „Element“ ist wirklich ein DOM-Knoten. Wir hängen diesen Listener über eine DOM-Eigenschaft an diesem DOM-Knoten an. Wenn dieses Ereignis eintritt, ist es der DOM-Knoten, der dieses Ereignis auslöst.

Entschuldigung, wenn ich mich bei einigen dieser Dinge falsch ausgedrückt habe. Aber Sie verstehen den Punkt hoffentlich. Das DOM ist hier die Lebensader. Es ist der Ort, an dem alles im Browser geschieht. JavaScript ist nur die Syntax, die Sprache. Es kann völlig außerhalb des Browsers ohne DOM-APIs verwendet werden (siehe Node.js).
Dieser Artikel ist nicht annähernd nerdig und tiefgründig genug für mich.
Nun, das DOM steht für „Document Object Model“ bla bla bla. Diesen Artikel wollte ich nicht schreiben (und bin nicht qualifiziert). Hier sind einige ausführlichere Artikel
- W3C: Was ist das Document Object Model?
- MDN: Einführung – Document Object Model
- Wikipedia: Document Object Model
Praktisches Tutorial! Steht auf einer Stufe mit „es ist keine Webseite, wenn sie keinen Doctyp hat“ (seid nicht schüchtern, wir alle machen diese Gesichtsmimik gelegentlich).
Dem widerspreche ich. Für mich ist es immer noch essentiell.
Zur Klarstellung
Ich denke, die Fähigkeit, Quelltext anzuzeigen, ist von entscheidender Bedeutung und sollte einfach sein. Ich denke nur, der Befehl dazu sollte das Dokument im Quellen-Panel der DevTools öffnen, anstatt dieser speziellen, einzigartigen Ansicht, die isoliert in ihrer eigenen kleinen Welt existiert.
Quelltext anzeigen ist immer noch sehr nützlich, für Situationen, in denen man tatsächlich die ursprünglich ausgelieferte Markup-Struktur sehen möchte. Vielleicht reparieren Sie die Website eines anderen, oder Sie haben eine dynamisch generierte Seite und müssen wissen, was tatsächlich ausgegeben wird.
Die Möglichkeit, das generierte DOM zu betrachten, ist unbestreitbar nützlich, aber zu wissen, woraus es aufgebaut wurde, kann bei der Problemlösung sehr hilfreich sein.
Eigentlich, aus dem Artikel, hat ::Chris:: oben angegeben, dass Quelltext anzeigen nach der Einführung der Inspektionstools einige seiner Verwendungszwecke verloren hat!
Aber es hat immer noch seine Bedeutung, wenn wir einfach die Quelle in einem separaten Fenster öffnen wollen, anstatt die Webkonsole zu öffnen und den relevanten Tab zum Anzeigen der Quelle zu öffnen.
Auch wenn es nicht viel Energie kostet, es verbessert die Frustrationszeit, in Zeiten hohen Drucks (Scherz!)
Quelltext anzeigen ist immer noch sehr nützlich, wenn Sie Code beheben, den Sie möglicherweise nicht selbst berührt haben. Außerdem sind Quelltext anzeigen und DOM völlig unterschiedlich. Manchmal möchten Sie den Zustand des Browsers vor der DOM-Manipulation sehen. Entwicklertools erledigen meist alles aus der Sicht von Quelltext anzeigen, aber es ist immer noch schnell, einfach Quelltext anzeigen und sehen, was vor sich geht.
Ich glaube, Chris meinte nicht, dass es völlig irrelevant ist, als er das sagte. In den meisten Fällen sehen wir als Frontend-Entwickler den Quelltext an, um zu sehen, was für die Anwesenheit eines Objekts im DOM verantwortlich sein könnte. Um Spezifität und Klarheit zu gewährleisten, gibt uns das Untersuchen-Element genau das. Quelltext anzeigen mag nützlich sein, aber wirklich, wenn ich die Quelle eines HTML-Dokuments benötige, werde ich die Website einfach spiegeln und in meinem Texteditor öffnen, da sie so übersichtlicher zu lesen ist.
Einfach, aber von grundlegender Bedeutung.
Schöner Artikel! Ich schätze, mir war der Unterschied zwischen DOM und Quellcode nicht bewusst. Man kann sehen, wie er leicht missverstanden werden kann.
Wirklich interessanter Artikel, Chris. Ich muss sagen, obwohl ich wusste, dass das von Ihnen geschriebene HTML und das DOM unterschiedliche Dinge sind, habe ich sie visuell als eins betrachtet. Jetzt hat dieser Artikel mir geholfen, sie weiter zu trennen. Danke dafür.
Nächster Artikel… Shadow DOM??
Das ist ein großartiger Artikel zu all dem: https://css-tricks.de/modular-future-web-components/
Am einfachsten ausgedrückt, denke ich, kann man sagen, dass das DOM das geparste HTML ist.
Darf ich es versuchen?
HTML-Code kommt an
Der Browser interpretiert das HTML und erstellt ein DOM für die Seite
Der Browser erlaubt JavaScript, das DOM zu verändern
Der Browser zeigt den aktuellen Zustand des DOM, immer das DOM.
Ein HTML-Dokument ist nur ein Rezept, eine Reihe von Anweisungen, wie der Browser das DOM für die gegebene Seite aufbauen soll. Was wir am Ende sehen, ist, wie der Browser diese Anweisungen interpretiert hat.
DOM – eine Schicht zwischen dem HTML-Code und der angezeigten Seite – wurde vielleicht eingeführt (ich bin Anfänger, Annahme hier), um es zu ermöglichen, Teile davon auf der Client-Seite zu verschieben, bevor sie auf dem Bildschirm angezeigt werden. Jetzt ist es da und scheinbar führt der einzige Weg zum Bildschirm hindurch.
Ich stimme dem entschieden zu. Was die Dev-Tools anzeigen, ist auch der aktuelle Zustand des DOM, die interpretierte Version Ihres HTML.
„Quelltext anzeigen“ ist ein Lebensretter, der es Ihnen ermöglicht, Ihren tatsächlichen HTML-Code anzusehen. Wenn Sie dynamisch zusammengestellte Webseiten erstellen, ist „Quelltext anzeigen“ der praktischste Ort, um zu überprüfen, was Ihr Code im ersten Schritt den Browser gebeten hat zu tun. (Überprüfung auf fehlerhafte/ungeschlossene HTML-Tags usw. (das Zusammenstellen von HTML-Snippets durch benutzerdefinierte PHP-Skripte funktioniert möglicherweise nicht auf Anhieb fehlerfrei)).
Natürlich kann der W3C-Validator hier den ultimativen Service bieten (vorausgesetzt, Sie können Ihre Seiten online stellen, aber das ist nicht immer der Fall).
Außerdem können Sie vielleicht das ursprüngliche HTML auch in den Dev-Tools ausgraben, aber es scheint viele Klicks entfernt zu sein, und seine Darstellung wirkt auch viel umständlicher als die einfache, praktische Vollbild-Quelltextansicht.
Schöne Ausarbeitung. Es ist lustig, wie jeder von dem DOM gehört hat – aber wenn man darüber nachdenkt, denken die meisten Anfänger und einige fortgeschrittene Webentwickler vielleicht, es sei eine Art Black Box.
Ich denke, der entscheidende Unterschied zwischen den Ideen von DOM und Code ist, dass das DOM nur zur Laufzeit, innerhalb des Browsers existieren kann. Für 99% der Anwendungsfälle macht es keinen wirklichen Unterschied, aber ich glaube fest daran, dass bei der Vermittlung von Front-End-Autorenschaft jeglicher Art einige Schlüsselkonzepte gelehrt oder zumindest wiederholt werden müssen.
Als Autor von HTML schreiben Sie Dinge, die von Menschen über einen Browser gesehen werden.
Daher schreiben Sie für den Browser.
Der Browser baut ein Verständnis Ihres Codes auf, wenn er ihn liest; dieses Verständnis wird DOM genannt und existiert innerhalb des Browsers.
Tags (kleine Textstücke, die mit < beginnen und mit > enden) stellen Anweisungen für den Browser dar, wie das DOM aufgebaut werden soll und was die verschiedenen Teile des DOM sind.
Wenn das die erste Lektion beim Schreiben von HTML ist, und die gesamte zukünftige Entwicklung Sinn ergibt, ohne sie werden viele Studenten versuchen herauszufinden, was Tags wirklich sind, warum sie wichtig sind und andere potenziell verwirrende Elemente von Markup-Sprachen. Mit einem soliden Verständnis der Beziehung zwischen Text, Tags und dem DOM, fließt dann alles andere reibungslos bis hin zu CSS und JavaScript.
wichtiger Beitrag
Das DOM kann vom ursprünglichen HTML abweichen, wenn Sie optionale Tags wie <html>, <head> und <body> weglassen.
Wenn Ihr HTML so aussieht
Dann füllen moderne Browser dies mit den optionalen Tags aus, bevor das DOM zusammengestellt wird.
![result.png][http://i.imgur.com/kjvPdki.png]
Das ist richtig. Ich habe versucht, ein HTML-Dokument ohne schließenden Tag zu schreiben. Im „Quelltext anzeigen“-Modus
wird mir der fehlende Tag nicht angezeigt. Aber als ich versuchte, die Seite mit FireBug zu inspizieren, zeigte es mir den fehlenden Tag. Er wurde automatisch hinzugefügt!
Danke für den Artikel dazu!
Ich arbeite seit 12 Jahren mit HTML und hätte mich dumm gefühlt, wenn jemand vom DOM gesprochen hätte, weil ich mich nie wirklich mit der formellen Bedeutung beschäftigt hatte.
Super einfache Erklärung. Danke Chris!
Das DOM ist eine programmatische, objektorientierte API-Definition für den Zugriff auf HTML- und XML-Dokumente. Diese API wird in der DOM-Spezifikation mit einer sprachneutralen Semantik namens IDL definiert. Im strengsten Sinne ist also Folgendes wahr: Das DOM wird nicht geändert, es sei denn, das W3C ändert die API-Spezifikation. Wenn Sie
document.getElementById("firstheading")betrachten, ist Folgendes wahr:Also, wie bereits teilweise erwähnt, ist das DOM eine API-Spezifikation. Wenn Sie also in den Entwicklertools wie oben gezeigt schauen, sehen Sie HTML- oder XML-Markup (d. h. Dokumente), die von Browsern, Templating oder Skripten geändert wurden, und Sie sehen JavaScript. Das JavaScript kann gesehen werden, wie es auf die DOM-API zugreift, aber das Markup ist nur ein Dokument und JavaScript ist eine Sprache, die auf eine API zugreifen kann, die der DOM-Spezifikation entspricht. Wenn Sie „das DOM sehen“ möchten, klicken Sie auf den Link am Ende des Blog-Eintrags oben, um die W3C DOM-Spezifikation zu lesen. Die Dev-Tools zeigen stattdessen eine Sprache, JavaScript, die die DOM-API verwendet, um Daten und Objekte zu übergeben, die einem HTML- oder XML-Dokument entsprechen.
Danke Chris, großartiger und nützlicher Artikel
Toller Artikel mit erstaunlichen erklärenden Grafiken. Jemand, besonders Anfänger, kann daraus etwas lernen. Wenn nichts anderes, ist Chris ein meisterhafter Artikelautor und Lehrer. Deshalb abonnieren wir alle. Wir wissen, dass wir von diesem Mann etwas lernen können.
Danke für den kurzen und prägnanten Artikel, ich habe heute versucht, ihn mir selbst zu erklären, und das hilft, ihn zu klären :D
Danke für den Artikel, Chris! War immer eines dieser Akronyme, die für mich neblig waren. In Bezug auf Quelltext anzeigen, ich benutze es ziemlich oft, wenn ich mich potenziellen Kunden nähere. Es gibt mir ein schnelles Verständnis dafür, wie ihre Website funktioniert (wenn sie eine hat) und was ich anbieten kann, um Ziele zu fördern, die sie möglicherweise haben.
Es ist seltsam, in den letzten Tagen schien es, als ob überall Informationen über das DOM aufploppten.
Dann heute Morgen stieß ich auf das hier auf failblog http://cheezburger.com/7974345216, ich fand es urkomisch. Ich glaube, sie wurde „DOMED“ :P
Gute Arbeit, Chris! Die einzige Anpassung, die ich machen würde, ist die Aussage, dass das DOM „Fehler“ im HTML korrigiert. Obwohl das sicherlich passieren kann, wäre es genauer zu sagen, dass das DOM HTML „aufpoliert“; zum Beispiel sind schließende Listenelement-Tags in HTML5 nicht erforderlich, und es ist völlig gültig, sie aus Ihrem Code wegzulassen, aber das DOM wird sie beim Parsen der Seite einfügen. Dasselbe gilt für Anführungszeichen um Attributwerte. Das sind per se keine „Fehler“, solange der Entwickler sie bewusst einfügt. (Ich weiß, dass Sie davon abraten, aber ich betrachte das als stilistischen Unterschied, nicht als Schlachtfeld für „richtig oder falsch“).
Früher habe ich das HTML und das DOM im Sinne von Kognition kontrastiert: HTML ist das gespeicherte „Langzeitgedächtnis“ der Seite, während das DOM das „Kurzzeitgedächtnis“ ist: momentane, ephemere Änderungen und Eindrücke.
Ich habe eine Kurzversion: Das DOM ist die Summe dessen, was Ihr Browser „im Kopf hat“, wenn er Ihnen eine Webseite anzeigt.
Die Quelle, die Skripte, das CSS, die Bilder, die APIs usw. tragen alle dazu bei.
Großartige Erklärung. Danke Chris.
Ich bin mir nicht sicher, wie ich das jemandem ohne Informatikstudium erklären soll, aber ich werde mein Bestes geben: Das DOM ist das, was abstrakt als „Datenstruktur“ bekannt ist, genauer gesagt eine „Baumdatenstruktur“. [tree data-structure](https://en.wikipedia.org/wiki/Tree_(data_structure)).
Wenn Sie besser verstehen wollen, wie das DOM aktualisiert wird, sollten Sie sich vielleicht einige Beispiele für den Umgang mit Baumdatenstrukturen im Allgemeinen ansehen. Beginnen Sie mit dem Erlernen von Rekursionen, dann schreiben Sie Ihre eigene verkettete Liste und gehen Sie dann zu Bäumen über. Und als Herausforderung versuchen Sie, den von Ihnen konstruierten Baum zu modifizieren, z. B. Knoten erstellen, löschen und aktualisieren. Vielleicht, um sich wirklich herauszufordern, wandeln Sie einen Baum in eine flache Liste um. Dies erfordert das, was als „Traversal“ bezeichnet wird.
Ich wünschte, ich hätte das gefunden, als ich nach einer prägnanten/praktischen Erklärung des DOM suchte, exzellent!
Ich habe inzwischen das hier als sehr nützlich empfunden: http://domenlightenment.com/
Beste Grüße
Ed
Ausgezeichneter Beitrag & Link..!
Danke Ed
Übernommen. ;-) Tatsächlich hast du das, schätze ich
In HTML 4 ist das tbody-Element erforderlich, aber die Start- und End-Tags nicht. Das bedeutet, dass das tbody-Element immer in einer Tabelle vorhanden ist, egal ob Sie seine Start- und End-Tags im Code haben oder nicht.
Sie können das tbody-Element nicht weglassen. Sie könnten die Tags weglassen, da beide optional sind (die Os in der DTD-Zeile
<!ELEMENT TBODY O O (TR)+ -- table body -->).Das bedeutet, dass tr-Elemente niemals Kinder von Tabelle-Elementen sind, sondern deren Enkelkinder, auch wenn sich kein anderes Tag zwischen
<table>und<tr>im Code befindet.Eine andere Geschichte in XHTML 1, wo es keine optionalen Tags gibt. Um mit HTML 4 kompatibel zu sein, mussten die Coder die Wahl haben, tbody-Tags einzufügen oder wegzulassen. Daher sind tr-Elemente als Kinder von Tabellen-Elementen erlaubt, das tbody-Element ist nicht erforderlich.
Ein XHTML 1-Dokument ohne tbody-Tags, das als XML (
application/xhtml+xmloder ähnlicher Medientyp) verarbeitet wird, generiert ein DOM, in dem tr-Elemente Kinder des Tabellen-Elements sind.Während bei der Verarbeitung als HTML (
text/html) die HTML 4-Regeln gelten. Das bedeutet, dass das DOM, das aus derselben XHTML 1-Quelle generiert wird, je nach Medientyp unterschiedlich ist. Das ist eher problematisch als erwünscht. Best Practice ist, in XHTML 1 immer tbody-Tags zu verwenden.In HTML5 enthält das Inhaltsmodell des Tabellen-Elements „entweder null oder mehr tbody-Elemente oder ein oder mehrere tr-Elemente“, d. h. das tbody-Element ist in der HTML5-Sprache nicht erforderlich.
Aber auch ohne tbody-Tags generiert der HTML5-Parser einen tbody-Knoten im DOM, der das gleiche Verhalten wie in HTML 4 nachahmt.
Wichtige Klarstellung. Die Unterscheidung könnte wichtig sein, wenn Sie CSS-Direktkind-Regeln zum Stylen verwenden würden; je nachdem, welcher Parser die Materialien interpretiert, werden die Regeln möglicherweise nicht angewendet. Seien Sie am besten auf der gleichen Seite und verwenden Sie immer generische Nachfahrenregeln, wenn Sie über Tabellen sprechen...
Guter Artikel, Chris, und schön, die verschiedenen Antworten zu sehen und zu lesen. Ich besuche Ihre Website gelegentlich und finde viel Inspiration und für mich eine verdammt gute Ressource.
Mach weiter so mit der guten Arbeit.
Könnten wir einen Link zu dieser Eulen-Demo bekommen?
http://codepen.io/m3uc/pen/EyJGv
Die Antwort auf diese Frage hat sich mir erst letzte Woche wirklich erschlossen, als ich versuchte herauszufinden, „warum Modernizr nicht funktionierte“. Zu diesem Zeitpunkt funktionierte es – aber die Klassen, die es hinzufügt, erscheinen nicht in „Quelltext anzeigen“, sondern nur im Inspektor des Browsers. DANN wurde mir klar. Da liegt der ganze Unterschied.
Es ist lustig, wie lange ich schon mit dem Web arbeite und wie ich immer noch kleine Dinge wie diese nicht begriffen habe. Ich schätze, es ist nicht ungewöhnlich; viele Websites geben Ihnen viele verschiedene Arten von Erklärungen. Danke für die Bilder.
Wenn wir JavaScript schreiben, beschäftigen wir uns meist direkt mit dem DOM, und es ist am ehesten in der Browserquelle oder den Dev-Tools sichtbar. Danke Chris für die detaillierte Erklärung
Ich stimme Jessica oben zu, ich habe nie über kleine Dinge wie diese über das DOM nachgedacht, spiele seit Jahren mit dem DOM herum. Das bringt mich dazu, den nächsten Entwickler, den ich interviewe, eine Frage zum DOM zu stellen :-)
Fantastisch!