tags:

views:

1157

answers:

8

I know document.write is considered bad practice; and I'm hoping to compile a list of reasons to submit to a 3rd party vendor as to why they shouldn't use document.write in implementations of their analytics code.

Please include your reason for claiming document.write as a bad practice below.

+13  A: 

There's actually nothing wrong with document.write, per se. The problem is that it's really easy to misuse it. Grossly, even.

In terms of vendors supplying analytics code (like Google Analytics) it's actually the easiest way for them to distribute such snippets

  1. It keeps the scripts small
  2. They don't have to worry about overriding already established onload events or including the necessary abstraction to add onload events safely
  3. It's extremely compatible

As long as you don't try to use it after the document has loaded, document.write is not inherently evil, in my humble opinion.

Peter Bailey
document.write does really horrible things to the html parsers, and is only "extremely compatible" in simple cases.
olliej
Like the insertion of an analytics tag? That is, after all, part of the original question.And by extremely compatible, I mean for just raw browser support for the document.write method.
Peter Bailey
+1  A: 

It overwrites content on the page which is the most obvious reason but I wouldn't call it "bad".

It just doesn't have much use unless you're creating an entire document using JavaScript in which case you may start with document.write.

Even so, you aren't really leveraging the DOM when you use document.write--you are just dumping a blob of text into the document so I'd say it's bad form.

aleemb
One clarification: document.write inserts contents on the page, it doesn't overwrite them.
Peter Dolberg
@Peter, it does overwrite the content if you call it after the document is loaded. I'm guessing that's what aleemb means.
Matthew Crumley
+1  A: 

I think the biggest problem is that any elements written via document.write are added to the end of the page's elements. That's rarely the desired effect with modern page layouts and AJAX. (you have to keep in mind that the elements in the DOM are temporal, and when the script runs may affect its behavior).

It's much better to set a placeholder element on the page, and then manipulate it's innerHTML.

BnWasteland
This is not true. document.write does not add the content to the end of the page like it's an append. They are written in place.
Peter Bailey
+1  A: 

Off the top of my head:

(1) document.write needs to be used in the page load or body load. So if you want to use the script in any other time to update your page content document.write is pretty much useless.

(2) Technically document.write will only update HTML pages not XHTML/Xml. IE seems to be pretty forgiving of this fact but other browsers will not be.

http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite

brendan
IE is forgiving because it doesn't support XHTML. If/when they do, document.write will probably stop working (only in XHTML of course).
Matthew Crumley
+9  A: 

A few of the more serious problems:

  • document.write (henceforth DW) does not work in XHTML

  • DW does not directly modify the DOM, preventing further manipulation (trying to find evidence of this, but it's at best situational)

  • DW executed after the page has finished loading will overwrite the page, or write a new page, or not work

  • DW executes where encountered: it cannot inject at a given node point

  • DW is effectively writing serialised text which is not the way the DOM works conceptually, and is an easy way to create bugs (.innerHTML has the same problem)

Far better to use the safe and DOM friendly DOM manipulation methods

annakata
-1, it absolutely modifies the DOM. Everything else is fine. While I understand the urge to depend on structure and methods which can keep you from harm, this may be a case of throwing out the baby with the bathwater.
altCognito
(to see that it modifies the DOM, do a document.write in firebug after this page has loaded and then inspect the DOM, and the result (a now cleared page with the contents of your document.write) will be there plain to see.
altCognito
Dammit I *know* this used to be a problem, but I'm struggling to find a browser or situation where it happens. I'll strike it until I've found evidence. Damn my feeble memory.
annakata
FireBug is not a true representation of the DOM. It is mozilla's attempt to parse HTML into a DOM. You can have totally broken HTML look proper in the Firebug DOM view.
FlySwat
Agreed. Trying to address the effects of DW with something like getElementById is the only bulletproof way to tell.
annakata
The DOM is the data structure used to render the page and as such is the alpha and the omega of what the user sees on the page. You are correct that HTML != DOM, but it's immaterial to the question of whether or NOT the DOM is modified by DW. If DW didn't modify the DOM, you don't see the screen - that's true of all browsers and always will be as long as the DOM is what's used to render the page.
altCognito
As for Firebug in particular, it's a look into the DOM itself, it doesn't parse HTML, or you would have no view into properties on the DOM which aren't parsed. Even firebug-lite works by inspecting the DOM itself, not parsing the original HTML (even more so)
altCognito
it CAN inject at a given node point : http://jsbin.com/inuka
vsync
@vsync - that is not inserting at a given point that is calling at a given point, do you see the distinction?
annakata
+1  A: 

It breaks pages using XML rendering (like XHTML pages).

Best: some browser switch back to HTML rendering and everything works fine.

Probable: some browser disable the document.write() function in XML rendering mode.

Worst: some browser will fire an XML error whenever using the document.write() function.

Vincent Robert
+2  A: 

(plus) it's the easiest way to embed inline content from an external (to your host/domain) script.

(minus) it serializes the rendering engine to pause until said external script is loaded, which could take much longer than an internal script.

(minus) it is usually used in such a way that the script is placed within the content, which is considered bad-form.

(plus) you can overwrite the entire content in a frame/iframe. I used to use this technique a lot for menu/navigation pieces before more modern Ajax techniques were widely available (1998-2002).

Tracker1
+1  A: 

Here's my twopence worth, in general you shouldn't use document.write for heavy lifting, but there is one instance where it is definitely useful:

http://www.quirksmode.org/blog/archives/2005/06/three%5Fjavascrip%5F1.html

I discovered this recently trying to create an AJAX slider gallery. I created two nested divs, and applied width/height and overflow:hidden to the outer div with JS. This was so that in the event that the browser had JS disabled, the div would float to accommodate the images in the gallery - some nice graceful degradation.

Thing is, as with the article above, this JS hijacking of the css didn't kick in until the page had loaded, causing a momentary flash as the div was loaded. So I needed to write a CSS rule, or include a sheet, as the page loaded.

Obviously, this won't work in XHTML, but since XHTML appears to be something of a dead duck (and renders as tag soup in IE) it might be worth re-evaluating your choice of DOCTYPE...

sunwukung