This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If imported document has <script>s, they should be executed. The question is, which executio environment/global objecdt/browsing context/etc should be used to the execution. Actually, many more questions will follow.
My strawman here is to use master document as the document of the execution. Specifically, we need to patch HTML so that the created script gets associated documents/browsing context/etc from the master document. * http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#creating-scripts This should work as if it is loaded through XHR and eval()-ed, except that the script is kicked by the HTML parser thus script execution happens during parsing, not after the parsing finished. Also, we shouldn't explicitly execute sub-imports in "import fetching algorithm". Instead, we could modify '4 Link Type "import"' section to ensure that it loads linked import regardless if the document is a master or not. By doing this, the execution order is guaranteed recursively.
(In reply to comment #1) > Also, we shouldn't explicitly execute sub-imports in "import fetching > algorithm". > Instead, we could modify '4 Link Type "import"' section to ensure that > it loads linked import regardless if the document is a master or not. > > By doing this, the execution order is guaranteed recursively. Right. I wondered if we should zap the "processing sub-imports" step altogether, and instead monkeypatch HTML spec to allow running scripts, loading stylesheets and registering element declarations when parsing an imported document.
(In reply to comment #2) > > Right. I wondered if we should zap the "processing sub-imports" step > altogether, and instead monkeypatch HTML spec to allow running scripts, > loading stylesheets and registering element declarations when parsing an > imported document. We surely need a patch for running script. For stylesheet, it look it's just a metadata for HTML and loading it (especially if it doesn't affect rendering at that timing) can taken as just an implementation detail. For element registration, we could patch Custom Element... Or Custom Element could provide some hook for that. I have no clear idea how the hook looks like though.
I wonder if Tony or James have thoughts/opinions on this.
Mark as fixed for now: https://dvcs.w3.org/hg/webcomponents/rev/b51a8826c617 Any feedback is appreciated. I'd like to rather polish it than exploring alternate approach unless the whole direction is wrong.