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 bug refers to the following passage: http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#appropriate-template-contents-owner-document Per the spec, and as implemented in WebKit, Blink, and Gecko, the "appropriate template contents owner document" is the template element's own ownerDocument in any case where that document does not have a browsing context. This allows sub-templates to share an ownerDocument with their enclosing template, but happens to apply in other cases, such as when a template is created from a Document created via document.implementation.createHTMLDocument(). Given that the reason for using a separate document was mostly to avoid loading resources in templates, that was fine. But in the Custom Elements spec, there is now a difference between Documents created via createHTMLDocument and those in <templates>: the former share the custom element registry with the Document they're created from, while <template> documents do not share the registry, thus making custom elements inside templates "inert". The relevant part of Custom Elements is http://w3c.github.io/webcomponents/spec/custom/#creating-and-passing-registries. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=23839#c5 for more details on the interaction between that part of the spec and <template>. All of the above means that a custom element in a template could have different behavior depending on whether that template's ownerDocument was created via createHTMLDocument (in which case custom elements inside will, against the wishes of the Custom Elements spec, "come to life"). The easiest fix to the HTML spec would be to change step 1 of the linked algorithm above to branch on whether |doc| is itself a template contents owner document (which would be some new property of the document).
Some code: document.register('my-element', {prototype: {__proto__: HTMLElement.prototype, createdCallback: function() { console.log('my-element created'); } } }); // logs, as it should document.createElement('my-element'); // does not log, as it shouldn't document.createElement('template').content.ownerDocument.createElement('my-element'); // logs, as it should document.implementation.createHTMLDocument('').createElement('my-element'); // ERROR! logs, but shouldn't document.implementation.createHTMLDocument('').createElement('template').content.ownerDocument.createElement('my-element');
Why do we want elements in otherwise-inert createDocument-style documents to have bindings applied, but not have elements in template contents have bindings applied?
I pushed pretty hard on the same issue. My understanding is two-fold. The practical answer is very tactical: A worry that if custom elements boot-strap inside of template, then the naive implementation of custom elements may be extremely wasteful. The guard against this is to check whether the element has a defaultView, but it's a fairly esoteric concept and even invoking the callbacks has cost. The theoretical answer which ultimately made me comfortable is: We *will* (at some point) allow custom elements to boot up inside of templates (converging on equivalent expressiveness for built-in vs custom elements) However, we can wait to do that until we have clear & compelling use cases. (e.g. add an optional argument to document.register which requests being booted up inside of templates).
So isn't the fix for this as simple as changing the "appropriate template contents owner document" algorithm to just not check if there's a browsing context and simply always use that code path?
(In reply to Ian 'Hixie' Hickson from comment #4) > So isn't the fix for this as simple as changing the "appropriate template > contents owner document" algorithm to just not check if there's a browsing > context and simply always use that code path? The trouble with that approach is that: <template> <template> <template> results in 3 documents. Given that one of the wins of <template> over <script type="text/html"> is nestability, that seems unfortunate. But maybe this is acceptable? I haven't thought hard about the consequences of having lots of documents in cases like this in a long time.
Checked in as WHATWG revision r8351. Check-in comment: Make the template contents of <template> elements in docs created by createDocument() not have live bindings. http://html5.org/tools/web-apps-tracker?from=8350&to=8351
For the record, I've uploaded a pull request that updates the html-templates tests to match the now-specced behavior: https://github.com/w3c/web-platform-tests/pull/624