23170 2013-09-05 20:20:50 +0000 [imports]: Why not have imported documents share their importing document's defaultView? 2014-08-27 17:53:55 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 22864 24616 20683 23278 1 rafaelw dglazkov gkrizsanits ian morrita sjmiles sorvell public-webapps-bugzilla oldest_to_newest 93071 0 rafaelw 2013-09-05 20:20:50 +0000 93072 1 rafaelw 2013-09-05 20:23:14 +0000 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. 93073 2 dglazkov 2013-09-05 20:25:51 +0000 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. 93074 3 rafaelw 2013-09-05 20:29:00 +0000 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. 93075 4 rafaelw 2013-09-05 20:30:31 +0000 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. 93076 5 sjmiles 2013-09-05 20:33:11 +0000 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. 93527 6 dglazkov 2013-09-18 19:47:03 +0000 *** Bug 21229 has been marked as a duplicate of this bug. *** 93532 7 dglazkov 2013-09-18 20:05:16 +0000 *** Bug 22864 has been marked as a duplicate of this bug. *** 94304 8 morrita 2013-10-04 09:37:09 +0000 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? 94311 9 dglazkov 2013-10-04 16:53:52 +0000 (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. 94317 10 rafaelw 2013-10-04 18:26:04 +0000 sgtm =-) 94346 11 morrita 2013-10-04 22:21:24 +0000 Thanks! I'll reshape the spec in this way. 94451 12 morrita 2013-10-08 08:59:30 +0000 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. 103499 13 morrita 2014-04-07 19:54:49 +0000 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. 105921 14 ian 2014-05-13 21:49:09 +0000 (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... 106150 15 morrita 2014-05-16 11:10:46 +0000 (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. 110662 16 morrita 2014-08-27 17:53:55 +0000 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.