Bug 23170 - [imports]: Why not have imported documents share their importing document's defaultView?
Summary: [imports]: Why not have imported documents share their importing document's d...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
: 21229 22864 (view as bug list)
Depends on: 22864 24616
Blocks: 20683 23278
  Show dependency treegraph
 
Reported: 2013-09-05 20:20 UTC by Rafael Weinstein
Modified: 2014-08-27 17:53 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Weinstein 2013-09-05 20:20:50 UTC

    
Comment 1 Rafael Weinstein 2013-09-05 20:23:14 UTC
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.
Comment 2 Dimitri Glazkov 2013-09-05 20:25:51 UTC
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.
Comment 3 Rafael Weinstein 2013-09-05 20:29:00 UTC
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.
Comment 4 Rafael Weinstein 2013-09-05 20:30:31 UTC
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.
Comment 5 Scott Miles 2013-09-05 20:33:11 UTC
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.
Comment 6 Dimitri Glazkov 2013-09-18 19:47:03 UTC
*** Bug 21229 has been marked as a duplicate of this bug. ***
Comment 7 Dimitri Glazkov 2013-09-18 20:05:16 UTC
*** Bug 22864 has been marked as a duplicate of this bug. ***
Comment 8 Morrita Hajime 2013-10-04 09:37:09 UTC
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?
Comment 9 Dimitri Glazkov 2013-10-04 16:53:52 UTC
(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.
Comment 10 Rafael Weinstein 2013-10-04 18:26:04 UTC
sgtm =-)
Comment 11 Morrita Hajime 2013-10-04 22:21:24 UTC
Thanks! I'll reshape the spec in this way.
Comment 12 Morrita Hajime 2013-10-08 08:59:30 UTC
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.
Comment 13 Morrita Hajime 2014-04-07 19:54:49 UTC
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.
Comment 14 Ian 'Hixie' Hickson 2014-05-13 21:49:09 UTC
(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...
Comment 15 Morrita Hajime 2014-05-16 11:10:46 UTC
(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.
Comment 16 Morrita Hajime 2014-08-27 17:53:55 UTC
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.