Re: [HTML5] DOMContentLoaded fires before CSS resources loaded?

Ian Hickson wrote:
>>> Gecko and WebKit do quite different things here, actually.
>> In the absence of <script> elements created via DOM calls?  What are the 
>> differences?
> 
> Differences based on whether the scripts are internal or external, on 
> whether scripts are inserted dynamically or not, etc.

Interesting...  For the latter, I would absolutely believe it; I 
explicitly mentioned that.  The former confuses me.

>>> I ended up speccing the Gecko behaviour, because it is much simpler 
>>> (block on running any script if a style sheet is pending)
>> That would be running any newly-added <script>, not running script in 
>> general, right?
> 
> Right.

OK.

>> And pending has a somewhat nontrivial definition as well... (a 
>> stylesheet added via parsing a <link> or <style> element that was in the 
>> currently selected stylesheet set at the point when it was added to the 
>> DOM and is either not done loading or has an @import'ed descendant that 
>> is not done loading).
> 
> I just said "applicable style sheets". Right now it's hard to be more 
> detailed since CSSOM isn't stable, so all this stuff isn't well-defined 
> yet.

The key here is that applicable styles sheets that were added via 
explicit DOM manipulation, not via the parser, do NOT block the parser 
in Gecko.  It sounds like they do per your current draft.  Or at least 
that it's not really defined what the behavior should be there.

> http://www.whatwg.org/specs/web-apps/current-work/#executing-a-script-block
> 
> Step 2.

Thanks.  Sounds like "not really defined" to me.  ;)

I'm also not convinced that the "pause" behavior here is reasonable.  In 
particular, it requires the following behavior:

1)  document.write of a <script> while stylesheet loads are pending has
     to block the script that called write() until the stylesheets finish
     loading.
2)  load/error events on various subresources can't fire if a <script>
     is hit while stylesheets are loading, until those stylesheets finish
     loading.  Normally stylesheet loads do not prevent such events from
     firing.
3)  loadstart/progress/loadend/emptied/abort/etc events will not fire on
     media elements in the situation above until the styesheets finish
     loading.
4)  "input" events will not fire on form controls until the stylesheets
     load.
5)  "change" events will not fire on form controls until the stylesheets
     load (this seems weird to me in itself; since when is onchange
     async?).
6)  The "autofocus" attribute will have no effect until the stylesheet
     is loaded.
7)  Some application cache stuff I don't understand won't work.
8)  Clicking on an <a href> that point to a named anchor or id in the
     same document will do absolutely nothing, then suddenly scroll once
     the stylesheets load.

The above are all clealy listed as requiring a task to be queued.  I 
assume that not processing tasks also means the following (per 
<http://www.whatwg.org/specs/web-apps/current-work/#event-loop>):

9)  The parser must be blocked (even if the script was inserted via a
     DOM call, not by the parser itself; normally such scripts do NOT
     block the parser).
10) Images whose data comes in while waiting for the stylesheets must
     not be shown until the stylesheet loads.  Same thing for subframes,
     etc.

For comparison, the Gecko behavior is simply to queue the <script>'s 
execution, block the parser if the <script> was inserted via the parser, 
and continue behaving normally in all other respects.

-Boris

Received on Sunday, 6 September 2009 19:17:08 UTC