- From: <bugzilla@jessica.w3.org>
- Date: Wed, 29 Sep 2010 08:27:26 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9843
--- Comment #5 from Henri Sivonen <hsivonen@iki.fi> 2010-09-29 08:27:25 UTC ---
(In reply to comment #4)
> Well it's not great, sure, but in practice what's the worst that could happen?
When the document's parser is not script-created, the DOM after
document.write("<link rel=stylesheet href=...><script>...</script>..."); would
be different in HTML5-compliant browsers and in existing Presto, WebKit and
Trident (and Gecko 2.0 if Gecko 2.0 if Gecko 2.0 ships in its current state).
When the document's parser is script-created and the script doing the writing
pauses between writing a <link> and writing an inline <script>, the DOM after
the second write would be network timing-dependent.
> It's not like the style sheet is going to completely load before the event loop
> spins anyway, right? I could make this explicit if you like.
That's a good point for the case where the document's parser is not
script-created. It's not such a good point when the document's parser is
script-created, but I should test that case in IE before saying more.
You are assuming that data: URLs and cached http: URLs don't go to a loaded
state synchronously, though.
> Making things depend on where the "<" came from or some such seems like adding
> yet more hacks to an already particularly large pile of hacks.
ITYM ">". :-)
In Gecko, there's already infrastructure for this. Also, it's already needed in
order to ignore document.written charset metas. Presumably, IE has
infrastructure, too, since IE varies the blocking behavior for document.write
vs. not.
> Given that
> there's no interop here, I'd really rather just do the minimum required to be
> compatible with legacy content and have the design be somewhat sane.
Actually, currently none of the top 4 engines blocks document.written scripts
on sheets, so in that sense, there is interop (although Gecko and Trident
special-case document.written scripts while WebKit and Presto never block
anyway).
--
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, 29 September 2010 08:27:30 UTC