- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 06 Jun 2012 20:32:29 -0400
- To: whatwg@lists.whatwg.org
On 6/6/12 7:47 PM, Ian Hickson wrote:
> On Fri, 27 Jan 2012, Boris Zbarsky wrote:
>> On 1/27/12 1:30 AM, Ian Hickson wrote:
>>> On Wed, 5 Oct 2011, Henri Sivonen wrote:
>>>> On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarsky<bzbarsky@mit.edu> wrote:
>>>>> What Firefox does do is block execution of<script> tags (but not
>>>>> timeouts, callbacks, etc!) if there are pending non-altenate
>>>>> parser-inserted stylesheet loads. This is necessary to make sure
>>>>> that scripts getting layout properties see the effect of those
>>>>> stylesheets. A side-effect is that a<script> coming after a<link>
>>>>> will never see the link in an unloaded state... unless there's a
>>>>> network error for the<link> or whatever.
>>>>
>>>> One exception: If an inline script comes from document.write(), it
>>>> doesn't block on pending sheets. It runs right away. If it blocked
>>>> on pending sheets, the point at which document.write() returns would
>>>> depend on network performance, which I think would be worse than
>>>> having document.written inline scripts that poke at styles fail
>>>> depending on network performance.
>>>
>>> Note that this is not conforming. The spec does not currently define
>>> any such behaviour.
>>
>> Which part is not conforming? The exception for alternate sheets, the
>> inline script inside document.write thing, or something else?
>
> 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...
-Boris
Received on Thursday, 7 June 2012 00:33:00 UTC