This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was brought up by the Polymer team. In their custom elements, they have to special-case custom element being in a template and short-circuit their "created" callbacks to provide impression of "inertness". Also brought up here: http://techblog.ironfroggy.com/2013/11/5-reasons-web-components-arent-ready.html (see missing item 3). This seems like a common pattern, and it's easily rectified by removing the line in spec where we share the registry with the template document.
The effect of this change would be that the elements are never upgraded or have their callbacks fired while in templates.
Two questions: 1. The link mentions in Comment 1 mentions initializers running in templates; this proposal is to not share a registration context at all and hence not run any callbacks. Is not doing any prototype swizzling/callbacks just the logical consequence of not running the initializer? 2. If the registration context is not shared, does the template document get a blank registration context ('register' will work when used on a template document) or not? ('register' will throw when used on a template document.)
(In reply to Dominic Cooney from comment #2) > Two questions: > > 1. The link mentions in Comment 1 mentions initializers running in > templates; this proposal is to not share a registration context at all and > hence not run any callbacks. Is not doing any prototype swizzling/callbacks > just the logical consequence of not running the initializer? Right. > 2. If the registration context is not shared, does the template document get > a blank registration context ('register' will work when used on a template > document) or not? ('register' will throw when used on a template document.) Just a blank registration context. Technically, it's not blank. When we spec the Registry object API, we'll say that at the time of creating a template document, we pour all of the built-in HTML element definitions into this context (just like with a Document created with XHR). The authors should be able to do the same type of sharing with their elements using that API.
https://github.com/w3c/webcomponents/commit/1d4c8e006a7b07c1f5ad36ed029505b37d41423f
As currently specced in HTML, <template> doesn't always create a new Document for its content fragment; if its ownerDocument lacks a defaultView, it assumes it's fine to re-use that one. This handles the case: <template> <template> ... so that each <template> doesn't cause the creation of a new Document. However, with this spec change, it's now possible to see different Custom Element behavior in a <template> that happens to be in a Document created via document.implementation.createHTMLDocument(), since: doc = document.implementation.createHTMLDocument('title') template = doc.createElement('template') template.ownerDocument === template.content.ownerDocument In such documents, custom elements inside templates will be "alive". The right fix is likely to tighten <template>'s requirements for when it will re-use its ownerDocument, i.e., only re-use ownerDocument if it's actually the content owner document of another <template>. This requires tagging template content documents upon creation. I intend to file the above against the HTML spec, but I wanted to have an explanation written down here, too, since it was this bug report that requires the change to <template>'s behavior.
I think that change might have gone too far, now template documents don't have a registry at all. I think they should have a registry, but it should not be shared with the main document.
(In reply to Dominic Cooney from comment #6) > I think that change might have gone too far, now template documents don't > have a registry at all. I think they should have a registry, but it should > not be shared with the main document. PTAL? https://github.com/dglazkov/webcomponents/pull/1
https://github.com/dglazkov/webcomponents/commit/7476e1ce7d9e711375c7e8c12ece19518d2e958a