This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The HTML parser should continue tree building inside an import even if blocked on an external resource. As a result document.write() should also throw when the currentScript is inside an import since the location of the write is arbitrary. The result of this is that given: <link rel="import" href="1.html"> <script src="slow.js"></script> <link rel="import" href="2.html"> <link rel="import" href="3.html"> <x-foo></x-foo> <script> console.log(1); </script> While slow.js is being downloaded the entire import tree (1.html, 2.html and 3.html) can be processed and constructed into DOM trees. When it finishes loading the scripts that were queued while tree building these nested imports and the top level import with the console.log should be executed in order. This is conceptually similar to defer@ or async@ on <script>.
It's not just document.write, is it? When slow.js runs, can it tell whether 2.html has been loaded? If so, it'll see a somewhat non-deterministic view of the DOM... I guess @async scripts have some of that behavior too, though.
(In reply to Boris Zbarsky from comment #1) > It's not just document.write, is it? > > When slow.js runs, can it tell whether 2.html has been loaded? If so, it'll > see a somewhat non-deterministic view of the DOM... > > I guess @async scripts have some of that behavior too, though. Yes, @async already has this behavior. You will always have a non-deterministic view of the main document from an import since it doesn't block the parser as we treat imports like stylesheets not script when parsing. We're extending that behavior to the entire import tree. The reason to throw in document.write() is that it prevents depending on the tokens being inserted in any particular place. I'm not sure why <script async> doesn't throw when you document.write(), we probably should have made it do so.
> I'm not sure why <script async> doesn't throw when you document.write() It just silently does nothing instead, presumably because that's less likely to totally break preexisting scripts that someone asyncfiies. Which is also what document.write() does on a random document that's not being shown, actually. The only case right now in which document.write() throws is if the document is XML.
(In reply to Boris Zbarsky from comment #3) > > I'm not sure why <script async> doesn't throw when you document.write() > > It just silently does nothing instead, presumably because that's less likely > to totally break preexisting scripts that someone asyncfiies. > I'm fine if we make this a no-op in imports to match that.
Renaming the subject to reflect the discussion, and land the fix. https://github.com/w3c/webcomponents/commit/3a2ac114606bb80df5aa5aae047ae3342cc06339
Please file bugs https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWG&component=HTML to make sure this gets properly integrated and reviewed by the editor of the HTML specification. Monkey patching without actually involving Ian is not the right way to go about this.
Also, your fix seems wrong. What if I had changed currentScript to throw on getting?
(In reply to Anne from comment #6) > Please file bugs > https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWG&component=HTML > to make sure this gets properly integrated and reviewed by the editor of the > HTML specification. Monkey patching without actually involving Ian is not > the right way to go about this. (In reply to Anne from comment #7) > Also, your fix seems wrong. What if I had changed currentScript to throw on > getting? Thanks for the catch. Will file a bug. The discussion will lead the right way to spec this. Would you mind to drop some link to the bug which asks this kind of thing? I'd like to learn how to discuss monkey patch in HTML land.
I see you filed the bug yourself, thanks! In general we should avoid monkey patching. 1) A specification may not be aware of the patches being applied and invalidate them. 2) Readers of a specification may not be aware of the patches being applied and write code that turns out to be wrong due to patches. 3) If patches start getting applied from multiple sources the mental model quickly becomes too hard and mistakes start creeping in all over.
(In reply to Anne from comment #9) > In general we should avoid monkey patching. 1) A specification may not be > aware of the patches being applied and invalidate them. 2) Readers of a > specification may not be aware of the patches being applied and write code > that turns out to be wrong due to patches. 3) If patches start getting > applied from multiple sources the mental model quickly becomes too hard and > mistakes start creeping in all over. Agreed. We have some more monkey patches in the import spec. I filed Bug 24632 to track these. Although I'm not sure if we can completely get rid of them, it will be good idea to make these glitches visible.
http://www.whatwg.org/specs/web-apps/current-work/#execute-the-script-block step 2.3 seems like the thing that needs to be fixed (the ignore-destructive-writes-counter needs to be incremented for imported scripts).
Recovering the original summary line. Will file new one for document.write() thing.
Moving this to future considerations. The source of incompatibility risk (Bug 24808) is killed, so it's safe to postpone this.
Moved to https://github.com/w3c/webcomponents/issues/221