This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
HTML Imports patches "the end" [1] section of the parser algorithm so that the parser waits until all script-blocking imports are loaded[2] It would be great if HTML exposes some extension point to add another criteria for DOMContentLoaded event emission without monkey patches. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end [2] http://localhost:8000/spec/imports/#additions-to-tree-construction-algorithm
[2] is http://w3c.github.io/webcomponents/spec/imports/#additions-to-tree-construction-algorithm
(In reply to Anne from comment #1) > [2] is > http://w3c.github.io/webcomponents/spec/imports/#additions-to-tree- > construction-algorithm *facepalm* Thanks for the catch.
Isn't import something we just want to merge into HTML in due course, like we did for <template>?
(In reply to Ian 'Hixie' Hickson from comment #3) > Isn't import something we just want to merge into HTML in due course, like > we did for <template>? We're thinking about this but not decided yet. If the Imports spec stays small in coming iterations, it'd be better to merge it into HTML. We need a bit more polish before that point though. @dglazkov might have better idea.
(In reply to Morrita Hajime from comment #4) > (In reply to Ian 'Hixie' Hickson from comment #3) > > Isn't import something we just want to merge into HTML in due course, like > > we did for <template>? > > We're thinking about this but not decided yet. If the Imports spec stays > small in coming iterations, it'd be better to merge it into HTML. We need a > bit more polish before that point though. > > @dglazkov might have better idea. Yes. We should totally merge it into HTML spec in due course. Imports are designed at HTML layer.
If we're going to merge anyway, let's not worry about hooks (just patch it for now). Do we have an ETA for when this should get merged? (Do we have multiple vendors on board?)