Warum gilt document.write als „schlechte Praxis“?

Question 1

Ich kenne document.write gilt als schlechte Praxis; und ich hoffe, eine Liste mit Gründen zusammenstellen zu können, die einem Drittanbieter vorgelegt werden sollten, warum sie es nicht verwenden sollten document.write in Implementierungen ihres Analysecodes.

Bitte geben Sie Ihren Anspruchsgrund an document.write als schlechte Praxis unten.

Question 2

Einige der schwerwiegenderen Probleme:

document.write (im Folgenden DW) funktioniert nicht in XHTML
~~DW ändert das DOM nicht direkt, wodurch weitere Manipulationen verhindert werden~~ (Versuch, Beweise dafür zu finden, aber es ist bestenfalls situativ)
DW, das ausgeführt wird, nachdem die Seite vollständig geladen wurde, überschreibt die Seite oder schreibt eine neue Seite oder funktioniert nicht

DW wird dort ausgeführt, wo es angetroffen wird: Es kann nicht an einem bestimmten Knotenpunkt injiziert werden
DW schreibt effektiv serialisierten Text, was nicht der Art und Weise entspricht, wie das DOM konzeptionell funktioniert, und es ist eine einfache Möglichkeit, Fehler zu erstellen (.innerHTML hat das gleiche Problem).

Es ist viel besser, den Safe und DOM-freundlich zu verwenden DOM-Manipulationsmethoden

Question 3

Daran ist eigentlich nichts auszusetzen document.write, an sich. Das Problem ist, dass es sehr einfach ist, es zu missbrauchen. Grob sogar.

Für Anbieter, die Analysecode bereitstellen (wie Google Analytics), ist dies tatsächlich der einfachste Weg, solche Snippets zu verteilen

Es hält die Skripte klein

Sie müssen sich keine Gedanken darüber machen, bereits etablierte Onload-Ereignisse zu überschreiben oder die notwendige Abstraktion einzubeziehen, um Onload-Ereignisse sicher hinzuzufügen
Es ist extrem kompatibel

Solange Sie nicht versuchen, es zu verwenden, nachdem das Dokument geladen wurde, document.write ist meiner bescheidenen Meinung nach nicht von Natur aus böse.

Question 4

Es kann Ihre Seite blockieren

document.write funktioniert nur, während die Seite geladen wird; Wenn Sie es aufrufen, nachdem die Seite geladen wurde, wird die gesamte Seite überschrieben.

Dies bedeutet effektiv, dass Sie es von einem Inline-Skriptblock aufrufen müssen – und das verhindert, dass der Browser Teile der folgenden Seite verarbeitet. Skripte und Bilder werden erst heruntergeladen, wenn der Schreibblock abgeschlossen ist.

Question 5

Eine weitere legitime Verwendung von document.write stammt aus dem HTML5 Boilerplate index.html Beispiel.

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline -->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.3/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/libs/jquery-1.6.3.min.js"><\/script>')</script>

Ich habe auch die gleiche Technik für die Verwendung von gesehen json2.js JSON-Parse/Stringify-Polyfill (benötigt von IE7 und darunter).

<script>window.JSON || document.write('<script src="https://stackoverflow.com/questions/802854/json2.js"><\/script>')</script>

Question 6

Profi:

Dies ist der einfachste Weg, um Inline-Inhalte aus einem externen Skript (zu Ihrem Host/Ihrer Domäne) einzubetten.
Sie können den gesamten Inhalt in einem Frame/Iframe überschreiben. Ich habe diese Technik oft für Menü-/Navigationsstücke verwendet, bevor modernere Ajax-Techniken weit verbreitet waren (1998-2002).

Nachteil:

Es serialisiert die Rendering-Engine so, dass sie anhält, bis das externe Skript geladen ist, was viel länger dauern könnte als ein internes Skript.
Es wird normalerweise so verwendet, dass das Skript innerhalb des Inhalts platziert wird, was als schlechte Form angesehen wird.

Question 7

Hier ist mein Zwei-Pence-Wert, den Sie im Allgemeinen nicht verwenden sollten document.write für schweres Heben, aber es gibt einen Fall, in dem es definitiv nützlich ist:

http://www.quirksmode.org/blog/archives/2005/06/three_javascrip_1.html

Ich habe dies kürzlich entdeckt, als ich versuchte, eine AJAX-Slider-Galerie zu erstellen. Ich habe zwei verschachtelte Divs erstellt und angewendet width/height und overflow: hidden nach außen <div> mit JS. Dies war so, dass für den Fall, dass der Browser JS deaktiviert hatte, das div schweben würde, um die Bilder in der Galerie aufzunehmen – eine nette, anmutige Verschlechterung.

Die Sache ist, wie beim obigen Artikel, dass diese JS-Hijacking des CSS nicht einsetzte, bis die Seite geladen war, was einen kurzen Blitz verursachte, als das div geladen wurde. Also musste ich beim Laden der Seite eine CSS-Regel schreiben oder ein Blatt einfügen.

Offensichtlich funktioniert dies nicht in XHTML, aber da XHTML so etwas wie eine tote Ente zu sein scheint (und als Tag-Suppe im IE gerendert wird), könnte es sich lohnen, Ihre Wahl von DOCTYPE neu zu bewerten …

Question 8

Es überschreibt Inhalte auf der Seite, was der offensichtlichste Grund ist, aber ich würde es nicht als “schlecht” bezeichnen.

Es hat einfach nicht viel Nutzen, es sei denn, Sie erstellen ein ganzes Dokument mit JavaScript. In diesem Fall können Sie mit document.write beginnen.

Trotzdem nutzen Sie das DOM nicht wirklich, wenn Sie document.write verwenden – Sie werfen nur einen Textklumpen in das Dokument, also würde ich sagen, dass es eine schlechte Form ist.