[whatwg] scripts, defer, document.write and DOMContentLoaded

[Ian Hickson]

On Tue, 21 Jul 2009, Maciej Stachowiak wrote:
> On Jul 20, 2009, at 7:30 PM, Boris Zbarsky wrote:
> > Ian Hickson wrote:
> > > Actually what's going on is more subtle than that. When you set 
> > > innerHTML, it's actually triggering the deferred scripts right 
> > > there, if it has them loaded (e.g. inline scripts or cached 
> > > scripts). If it doesn't have them loaded yet, it drops them on the 
> > > floor and doesn't ever run them. I've specced this, except that the 
> > > spec requires that not-yet-loaded scripts be loaded then run, rather 
> > > than dropped, before innerHTML continues, so there's no race 
> > > conditions.
> > 
> > Er... wait.  So innerHTML has to block on network access?  And 
> > possibly spin the event loop as it does so?
> > 
> > This doesn't seem desirable to me.... Why do we want this behavior?
> 
> innerHTML blocking on network access seems seriously problematic to me. 
> I don't think blocking the UI is preferable to a race condition, when we 
> are talking about a compatibility quirk for content doing something 
> dubious.

I've changed the spec to do external deferred src=""ed scripts at the end 
of document load (blowing away the document as before), and inline 
deferred scripts as soon as innerHTML is set, if it is set, or else along 
with other deferred scripts at the end of document load.


On Tue, 21 Jul 2009, Boris Zbarsky wrote:
> > 
> > I don't really understand what your proposal would actually translate 
> > to, in precise spec terms.
> 
> I haven't internalized your parsing algorithm rules, but my intuition 
> given the one compat requirement I know of here (not blowing away 
> documents in cases where IE doesn't blow them away) is that deferred 
> scripts should be treated as if the <script> tags appeared in the HTML 
> character stream after all the content that is actually there...  That 
> is, immediately before the EOF point.

I don't know how to know that we are before the EOF before we are at the 
EOF, and I am very dubious about tokenising after hitting the EOF. For 
example, document.close() inserts an EOF, and I don't feel comfortable 
saying that after document.close() you can still document.write() to the 
same document.


> > One alternative would be to make the scripts that have "src" 
> > attributes but are deferred be excluded from the innerHTML behaviour, 
> > and just have them do the old behaviour
> 
> I could probably live with that, for what it's worth

That's what I've done now.


> but I'm still wondering why we need this innerHTML behavior at all.  
> innerHTML doesn't even run scripts it directly inserts; why would it run 
> some other random script?

It's what IE does, and you found that we needed to be compatible with IE 
for this case, as far as I can tell. When we want to be compatible with 
IE, we should be compatible, not introduce yet another behaviour, IMHO.


On Tue, 21 Jul 2009, Kristof Zelechovski wrote:
> 
> 	1. What is the script source of inline script[@type='text/xml']?
> The rules are contradictory: source = text because it is text-based and
> source = infoset because it is XML-based.  (An external script is created
> with the source text without any preliminary parsing.)  Does being XML
> override being text?  

I don't understand the question.


> 	2. Why is the special provision for XML needed at all?  Does it
> require invoking an embedded XML parser before the script is created?  Does
> it allow nested script elements?  (That would not be backwards-compatible
> and it would be fatal for HTML error recovery.)  What if the XML is not
> well-formed?  Is the embedded parser allowed to validate the XML?  What if
> validation fails?  Are external DTD allowed? --- forbidden?  Are XHTML
> scripts embedded in the XML code allowed to run in this step?  (they should
> not be!)

I don't understand these questions. I think you may be misreading the 
spec. There is no embedded XML parser or anything like that.


> 	3. Why is the script source for XML-based scripts allowed to be a
> node list?  Internet Explorer supports only well-formed XML documents, i.e.
> single trees, otherwise you get a parse error which is not very useful,
> except for the developer.

As far as I know, IE doesn't support XHTML at all, and has no support for 
XML-based scripting languages (of which I only know one, namely XForms
actions).


> 	4. Is script[@type='text/xml'] allowed to be externally loaded?  (I
> suppose that it is allowed, if supported by the browser, in spite of the
> specification requiring data scripts to be inline.)

If you have an XML-based scripting language, then yes. This has nothing to 
do with "data scripts".


> 	5. Is the browser allowed to expose the embedded XML document using
> a custom DOM property like XMLDocument?  Creating an XML script means
> attaching the infoset to the declaring script element in Internet Explorer.

There is no embedded XML document.


On Mon, 27 Jul 2009, Jonas Sicking wrote:
> 
> Erm, I would really not like to do this. innerHTML is an very popular
> method used by web developers, so adding unexpected (to say the least)
> behavior like this I think will be a great source of developer bugs.

It's apparently worked this way in IE for some time now.


> >> * Always execute elements in the order they are inserted into the 
> >> Document, with exception of async and deferred scripts.
> >
> > I haven't done this, because people use document.appendChild() of 
> > external scripts specifically to have scripts run "ASAP" and not 
> > necessarily in order.
> 
> I'm always wary of adding race conditions, and I think that's exactly 
> what we're adding here. The use case of running scripts ASAP is already 
> supported by using the "async" attribute.

Actually async="" scripts are defined to execute in order. 
appendChild()'ed scripts are the only ones currently that aren't defined 
to run in order. This seems to match current practice, based on my 
admittedly limited experience.


> > In general, I am very wary of changing this part of the spec, as it 
> > was written with extreme care based on all the tests I could run, 
> > primarily on IE, but also on other browsers. The innerHTML thing, 
> > though... I'll admit I really didn't even remotely think that there 
> > could be something to test!
> 
> My experience implementing deferred scripts and shipping support in 
> firefox 3.5 is that IE behavior is not needed here. I'd like to see data 
> showing otherwise before making innerHTML significantly more confusing 
> to developers (or significantly less performant if we do the sync 
> network thing) given how commonly used it is.

I don't know how to collect this data.


> We immediately noticed when document.write in deferred scripts blew away 
> the full document, even before shipping a beta. Once we made it append 
> to the end of the document we have not had a single problem reported. 
> This several weeks after final shipping of firefox 3.5.

I'm no fan of the innerHTML behaviour either, but I'm very wary of adding 
new behaviours to the platform like this. I'm also concerned about the 
problems I describe above with EOF and document.close(). I basically don't 
know how to make scripts run after the parser yet still affect the parser.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'