[whatwg] What should document.write() do when called from setTimeout or event handlers?

Tue Aug 1 06:37:17 PDT 2006

Ian Hickson <ian at hixie.ch> wrote:

> 
> I'm trying to spec document.write() and I've run into a difficult edge 
> case.
> 
> Imagine the server sees this:
> 
>    <!DOCTYPE HTML>
>    <html>
>     <head>
>      function test() {
>        document.write('TEST');
>      }
>      setTimeout(test, 1000);
>     </head>
>     <body>
>      <p><img src="test.png" alt="" onload="test()"></p>
> 
> ...and then time passes. The image loads, the timeout fires.
> 
> Then once the image has loaded and the timer has fired:
> 
>     </body>
>    </html>
> 
> ...and the connection is closed.
> 
> What should happen?

> 
> IE seems to make those calls to document.write() simply blow away the 
> document, as if the document was closed. Opera seems to do the same.

In other words, they treat it like being in an event handler context where
document.write is for replacing the entire document.  That seems entirely
reasonable to me.

Calling document.write() directly whilst in an event handler context must
blow the document away too, well, once you do document.close() that is.

> Mozilla seems to make the document.write() calls insert text into the 
> parser, as if they'd been called inline, with the result that the inserted

> text could appear pretty much anywhere. (It's actually a bit more complex 
> than that -- it avoids inserting into tokens -- but that's a detail.)

I think we can do without Heisenberg-like effects from Mozilla :-)

> I couldn't work out what Safari and MacIE do; they seem to delay the 
> timeout somehow and then print to the end of the page.

Possibly they are preventing setTimeout/setInterval timeouts from firing
until the document is loaded?  It's the same sort of problem faced by
constructs like <META HTTP-EQUIV=refresh CONTENT=0>  (is it CONTENT?
whatever).

Finding a suitable definition for "until the document is loaded" remains
problematic.  I have yet to find any satisfactory documentation for events
like "load", for example.  The key sticking point for me is whether or not a
browser should wait until it's formatted the page before issuing the event.
Script authors seem to believe that computed style will be available as soon
as the load event has been fired, which would imply that not only do you
have to wait until all the resources are downloaded, but processed too - and
what about images whose size is unknown and thus cause the document to be
reflowed.  The data is available (so technically the conditions for a "load"
event are fulfilled), but it hasn't been decoded yet - should the "load"
event be deferred until after it is?

> Any preferences? I'm particularly interested in feedback from browser 
> developers here as to whether there is anything I should know about how 
> easy/hard it is to do one thing or the other.

Easiest to disallow it like Safari/MacIE or behave like IE/Opera.  I prefer
the Safari way (it's what I've implemented, anyway :-)  Of course, if you
implement the Safari way, the Opera/IE behaviour is moot because the
situation never arises.

-- 
Stewart Brodie
Software Engineer
ANT Software Limited