Who should be CC-ed?

Just landed the change
https://dvcs.w3.org/hg/webcomponents/rev/6a2f6ee56195
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/imports/index.html

@esprehn, @mrbkap, @wchen: I'd like to hear your opinion.

So what's the global object scripts in the imported resource are executed against? If that's the global object of the master document, you can still access that synchronously and that can access the imported resource so you'll have all the problems you tried to remove.

I don't think the current specification works.

Thinking further about this with James Graham et al we cannot really see a reasonable way this would actually work.

(In reply to Anne from comment #4)
> Thinking further about this with James Graham et al we cannot really see a
> reasonable way this would actually work.

One way to see how it would work is to try it in Chrome. Enable HTML Imports flag and Enable experimental Web Platform features flag in chrome://flags. Please poke at it and find problems :)

(In reply to Anne from comment #3)
> So what's the global object scripts in the imported resource are executed
> against? If that's the global object of the master document, you can still
> access that synchronously and that can access the imported resource so
> you'll have all the problems you tried to remove.

Can you be a touch more specific? Which problems?

The fact that you can get at the import synchronously simply means that if you do, all your hope of asynchronous optimization is ruined. If you don't, you're in good shape.

Let's do this on the list for now: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0094.html

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.

Comment 0 raises three points. Base URLs we could do something about. E.g. "let imported be a new DocumentFragment whose node document is ... and whose base URL is ...". We should not (re)introduce xml:base, see bug 20976, but something mostly static is fine. We can always provide more control later. (Also, not having to support <base> and a bunch of other baggage documents come with seems like a feature.)

Concurrent parsing is an issue either way it seems, given how we try to adjust document.write() now.

In comment 8 you raise the point documents might have too much APIs, but comment 0 is concerned about the lack of certain APIs. Do we have an idea what is missing?

As for defining parsing, I assume we would use the same rules as innerHTML. See http://domparsing.spec.whatwg.org/#concept-parse-fragment

(In reply to Dimitri Glazkov from comment #8)
> morrita@, adamk@, esprehn@ and myself chatted a while yesterday on whether
> imports should return to being document fragments.

I think imports are just a new concept, neither document fragment nor actual document. For me it feels more closer to document right now because of it's capabilities. But the real question is then what are the capabilities we certainly want to support? If they can execute scripts and have their own parser and load their own resources, then I think we shouldn't try to stretch the concept of document fragment (which is designed to be minimalistic), but start from the document and limit it in a sane way. 

> 
> 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.

While there are plenty of document API that does not make a lot of sense for imports, I feel like if we don't answer them we just kick that can further down the road.

> 
> 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.
> 

I think it was not my idea. In fact in my mind it's still a tree and that list is just a flattened walk of the tree. And let me explain why I stick to this mental image: script execution order. When you add a new link import to the list it does not end up at the end of the list... So I would be careful with this array approach unless we want to stop caring about script execution order or want to disallow imports to run their own scripts.

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

My two cent is, if we want to alter the current version of spec. drastically like this, first we have to redefine what are our expectations from imports.

Any update on this one? This decision is pretty important to be made. Right now I don't know if I should put more effort into polishing and implementing the current spec, or should I wait for a new one based on DocumentFragments.

I'd like to give some constructive feedback on this question, but I kind of feel like both path is feasible and both will bring up uncomfortable questions to answer (like the ones in Comment 8). It almost feels like a matter of taste to me... Any ETA on when this decision will be made?

(In reply to Gabor Krizsanits from comment #11)
> Any update on this one? This decision is pretty important to be made. Right
> now I don't know if I should put more effort into polishing and implementing
> the current spec, or should I wait for a new one based on DocumentFragments.
> 
> I'd like to give some constructive feedback on this question, but I kind of
> feel like both path is feasible and both will bring up uncomfortable
> questions to answer (like the ones in Comment 8). It almost feels like a
> matter of taste to me... Any ETA on when this decision will be made?

The latest I heard was morrita@ would experiment with the DocumentFragment approach in Blink and see how terrible it would be.

After trying some prototyping in Blink, I found that there would be so many unanswered questions and we would bring another set of magic if we choose DocumentFragment - URL resolution, another tree participation state than in-document and out-document, ownership of the fragment, parsing, etc. I guess we'll find more as we move forward.

So I'd like to stick Document. It has some problems like encoding and quirks mode, but we've learned about that and the level of understanding is much higher than another path. Also we don't hear any complaint about import-as-document. Even though there are some theoretical inconsistency, Document seems fitting well to developer's mental model. 

Caveat: Although I don't see anything bad, theoretically it is possible to find some fundamental flaw of Document-as-import that forces us to switch to DocumentFragment again. That'd be a disaster for all of us. I'll add document.currentImport so that web developer doesn't have to rely on document.currentScript.ownerDocument which unnecessarily assumes that the import is a document.

Closing this for now. Import is going to be Document, as current spec and the bug title says.