[Bug 22305] [imports]: Imports should be represented as Documents, not DocumentFragments.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22305

Dimitri Glazkov <dglazkov@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adamk@chromium.org,
                   |                            |gkrizsanits@mozilla.com

--- Comment #8 from Dimitri Glazkov <dglazkov@chromium.org> ---
morrita@, adamk@, esprehn@ and myself chatted a while yesterday on whether
imports should return to being document fragments.

One of the key issues that we've encountered with pursuing imports as documents
is that we seem to have simply kicked the can of worms down the road. We'll
still have to open it.

Imports as documents make it easy to reason about loading and parsing of
imports, but they bring a whole new level problems, like existence of documents
that have a defaultView but no active browsing context (no browsing context at
all, for that matter!), as well as answering questions like what the DOCTYPE
and charset do in import in relation to master document, and what is the value
of document.currentScript.

Documents also have lots of baggage like APIs for dealing with focus or
fullscreen that aren't even applicable in imports.

Imports as document fragments make it easy to explain things like currentScript
and avoid altogether the problem of defaultView vs. browsing context, but they
force the need to explain how a new parser instance is spun up, and all things
thereabout, not the least of them is how URLs of imports are resolved.

There's a eerily familiar issue with ShadowRoots and baseURI that we also need
to solve, which is what triggered this discussion in the first place. Since we
have to do this for ShadowRoot kind of DocumentFragment, maybe that pushes
Imports as DocumentFragment idea to the more sane side?

Crazy ideas like "maybe Imports are just ShadowRoots on <style>" were brought
out and paraded around.

That last one seemed really tempting (to me), until Elliott/Adam pointed out
that deduping imports will mess terribly with author's understanding of where
import's "host" is.

This led to another interesting conversation about the fact that there's really
one ordered list of imports that is populated when <link rel="import"> is
inserted, and not actually a tree of imports. I believe Gabor mentioned that at
our previous discussion.

Elliott sketched out something like document.imports, which acts like an array.

In the future, we can even turn this into an imperative API for loading
imports:

var import = new Import("url");
import.onload = function() { ... }
// add new import.
document.imports.push(import);
// remove an import.
document.imports.splice(...);

I asked whether we could do the same for stylesheets, because that seemed like
a good thing to do for explaining the platform. Maybe there's one loading
controller that keeps track of all external resources, and loading imports
imperatively is just one of the thing you could do?

This is about it. No conclusions, but lots of new thoughts. Comments,
reactions, ideas, are appreciated.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 13 February 2014 20:51:19 UTC