[Bug 9843] Specced behavior for document.write("<link rel=stylesheet href=...><script>...</script>...") matches none of the top 4 engines

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9843





--- Comment #3 from Henri Sivonen <hsivonen@iki.fi>  2010-09-01 08:00:03 ---
First, http://hsivonen.iki.fi/test/moz/sheet-blocking-script-baseline.php shows
that WebKit (incl. Chromium nightly) and Opera don't block even
non-document.written parser-inserted scripts until style sheets have loaded.

This leaves only IE and old Gecko as existing behaviors to consider. Gecko's
old behavior is not OK, because it makes document.write() return or not return
early depending on the loading state of style sheets:
http://hsivonen.iki.fi/test/moz/sheet-blocking-script.html

http://hsivonen.iki.fi/test/moz/sheet-blocking-script3.html shows that
script-written sheet can block scripts in IE.

http://hsivonen.iki.fi/test/moz/sheet-blocking-script2.html shows that
document.written scripts don't wait for style sheets IE even when another
script has already caused document.write to return early. However, these tests
also show that IE and Opera put written scripts in the DOM right away, which is
*really* weird and not something I want to clone and not something I'd want the
spec to say.

My WIP patch for Gecko make Gecko match Chromium nightlies on the number of
script elements in the DOM at a given point but makes Gecko match IE on the
availability of computed style. (I.e. the patch looks at the
document.writtenness of parser-inserted inline scripts instead of checking if
document.write is still on the call stack.)

I could be persuaded that I should check whether document.write is on the call
stack instead, but this is the story I'm going to go with for now.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 1 September 2010 08:00:07 UTC