[whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior

Ian Hickson ian at hixie.ch
Mon Aug 27 21:46:41 PDT 2012

On Wed, 6 Jun 2012, Boris Zbarsky wrote:
> > 
> > Unless I'm mistaken, nothing in the HTML spec does anything 
> > differently based on whether a script comes from document.write() or 
> > not. The information about whether a character in the tokeniser came 
> > from the network, document.write() during a network parse, or 
> > document.write() on a completely script-written document, is not 
> > stored along with the character in the tokeniser's input stream.
> Oh, I see.  The problem with that is situations like this script:
>   var x = 0;
>   document.write("<link rel=stylesheet href=something>" +
>                  "<script>x = 1;</" + "script>");
>   alert(x);
> This interoperably alerts "1" in Trident, Gecko, Presto, and WebKit. 
> That means that either the write() call can't return until the sheet is 
> done loading or the script from write() needs to be able to run before 
> the sheet is done loading.
> A bit of further experimentation indicates that in all of the above 
> browsers its the latter: the script that sets x=1 runs before the <link> 
> is loaded.
> If the spec says something different, the spec probably needs to change 
> to match implementations here...

The case above is this one:


...and it could indeed be explained by having document.write()n text have 
magic abilities that cause <script> not to be delayed. However, it's not 
the only way to get that effect. Another way is to just not block _if the 
"prepare a script" algorithm was invoked by a re-entrant parser_.

Here's a test that checks which behaviour is actually going on. A result 
of "0 2 2" is consistent with the hypothesis that document.write() input 
is "coloured" and handled differently. A result of "0 1 2" is consistent 
with just not blocking for style sheets if you are executing from a nested 


Of the browsers I tested, only modern Firefox keeps track of which 
characters were inserted using document.write(), getting "0 2 2". Opera 
and Safari/Chrome both get "0 1 2", as did Firefox 3.6 (which I believe 
predates the recent parser changes). kennyluck tested IE9 for me (thanks!) 
and got "2 1 1", which means that IE is not returning from the inline 
document.write() at all until the whole thing has been parsed. I haven't 
bothered to try to do more detailed tests to work around IE's damage and 
work out what IE's stylesheet-primed script-blocking behaviour for 
reentrant inline scripts really is (I assume it's not what I describe here 
since that contradicts your statement above).

I've updated the spec to not block on style sheets for nested parser's 

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

More information about the whatwg mailing list