HTML Template's creates the precedent that elements without a defaultView are "inert" (this is colloquial, not specified).

I wonder if it's more useful separation of concerns that 

HTML Imports: are for importing remote resources (which likely do some registration)

HTML Templates: are for defining fragments of DOM which may be used later.

An an import wishes to declare fragments for later use, it should wrap those fragments in <template>s.

What about stylesheets, images, videos, and other assets? We need to understand what happens to them. Removing a browsing context for import documents is a nice switch that we happened to use here.

Note, that documents created with implementation.createHTMLDocument also don't have defaultView (aka browsing context). There's nothing special about it being absent in HTML templates.

The prior behavior of documents without a defaultView (e.g. created via createHTMLDocument) was the primary motivation for using this as the mechanism of "inertness". The two are very much related.

Put it this way: If imports have a default view, then all semantics are possible (any element can either be active or inert, depending on what the developer needs). If HTML imports lack a default view, then we're in the situation of needing to predict what developers will probably want.

We will have to think about the various ramifications of this change, but my knee-jerk reaction is that this might be a great simplifier.

To restrict the notion of `inertness` (aka: no defaultView)to templates could clarify several ancillary issues.

> What about stylesheets, images, videos, and other assets

Polymer team wants stylesheets to be 'live' as if they were in the main document, would having a proper defaultView in the import make this easier?

As for those other elements, seems like they can do whatever they normally would do. If you don't want them to do work you should put them in a template.

E.g. this might be a nice way to preload images: shove a bunch of image tags in an import.

*** Bug 21229 has been marked as a duplicate of this bug. ***

*** Bug 22864 has been marked as a duplicate of this bug. ***

Let me confirm my understanding of current consensus:
We're going to make imports behave like display:none-ed subtree,
which means:

- scripts are loaded and executed
- stylesheets are loaded and become a source of style resolution.
- images are loaded
- nothing is rendered
- it shares document.defaultView with main document

Is this correct?

(In reply to Morrita Hajime from comment #8)
> Let me confirm my understanding of current consensus:
> We're going to make imports behave like display:none-ed subtree,
> which means:
> 
> - scripts are loaded and executed
> - stylesheets are loaded and become a source of style resolution.
> - images are loaded
> - nothing is rendered
> - it shares document.defaultView with main document
> 
> Is this correct?

That's how I understand it.

sgtm =-)

Thanks! I'll reshape the spec in this way.

Thinking a bit more about the implication of this change:

 * 1. Forms become submittable
 * 2. Frames will be loaded
 * 3. Media (audio, video) and plugins are also loaded.

One tricky thing is form submission. It might create another attack vector.
I have no clear idea though. 

Frame could be another complication.
It's not clear how frame tree should look like for example.

Moving to future consideration items.

I think what we need here is a way to define the "capacity" of imported document, kind of like CSP.
 
The current import provides fixed set of capacity that allows scripts and stylesheets so far. It is possible to provide a knob to tune this.

(In reply to Morrita Hajime from comment #12)
> Thinking a bit more about the implication of this change:
> 
>  * 1. Forms become submittable
>  * 2. Frames will be loaded
>  * 3. Media (audio, video) and plugins are also loaded.

None of these are defined in terms of defaultView.

Forms are submittable if their Document has a browsing context. A browsing context can only have one active document at a time, that's the one that's being rendered. It's the one you get from Window.document.

If we change this and let Windows have multiple "child" Documents, then things are going to get really weird really quickly. For example, window.onload will fire when any of the child Documents finish loading. The Window object's supported property names would presumably come from all of its child documents, which would lead to all kinds of weird conflicts (e.g. what if two documents have elements with id="thetop"?). Things like window.location would return... what? The number of things in the platform that assume a 1:1 mapping of Window:Document is high. Just the weirdness around document.open Document reuse and about:blank Window reuse is confusing enough...

(In reply to Ian 'Hixie' Hickson from comment #14)
> 
> If we change this and let Windows have multiple "child" Documents, then
> things are going to get really weird really quickly.
>
Agreed. This was an attempt to explain how imports work by extending existing
vocabulary of the platform. However it apparently failed.
Another attempt that looks better is to explain it in terms of loading system.

This is orthogonal topic, but we need a way to tell import-loaded document aprt from other inert documents like XHR response. There are no signal other than defaultView so far.

Removed the description about defaultView.
https://github.com/w3c/webcomponents/commit/421daec2f6d0735db309ab10fa07fb10d623ea79

Although might want to some signal to decide whether a document is an import eventually, defaultView isn't good fit for that.