This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0794.html Given that many important/natural use cases of custom elements involve shadow DOM, can we add a flag to auto-create shadow DOM for custom elements? In particular, can we add "template" as the third argument to document.register so that when a custom element is "instantiated", the specified template is automatically closed and inserted into a shadow DOM of the custom element. e.g. using ES6 class syntax: <template id=myButtonTemplate> <button>Hi!</button> </template> <script> class MyButton extends HTMLElement { ... } document.registerElement('my-button', MyButton, myButtonTemplate); </script> Given that the shadow DOM specification is relatively stable if we constrain ourselves to only custom elements (i.e. ignoring all builtin elements), adding this mechanism will allow us to move the custom elements and shadow DOM specifications forward without risking to expose the general API for attaching shadow DOM to the Web.
I'm okay to have this API, given that this is very common pattern. At the same time, I'm wondering where we should draw the line between low-level APIs and high-level APIs, because Web Components tries to provide the minimum set of APIs, I think. In addition to that, I have a concern that consuming third parameter only for this purpose is really worth doing or not. If we were to support it, I prefer an optional dictionary such as: document.registerElement('my-button', MyButton, {'template': myButtonTemplate, 'useShadowDOM': true (== default)}); WDTY?
An optional dictionary might be okay. Alternatively, if ES7 adds support for static variables, we might even consider using that e.g. (with a hypothetical syntax for static variables): class MyButton extends HTMLElement { static template = document.getElementById('my-button-template'); }
(In reply to Ryosuke Niwa from comment #2) > An optional dictionary might be okay. Alternatively, if ES7 adds support for > static variables, we might even consider using that e.g. (with a > hypothetical syntax for static variables): > > class MyButton extends HTMLElement { > static template = document.getElementById('my-button-template'); > } This looks a good use case for static variables. Although I don't have a strong opinion either, I prefer this static variable usage since it looks more declarative. BTW, does it mean we can update *template* later after document.registerElement() is called by just reassigning another template to MyButton.template static variable. Cool. :)
(In reply to Hayato Ito from comment #3) > > BTW, does it mean we can update *template* later after > document.registerElement() is called by just reassigning another template to > MyButton.template static variable. Cool. :) I guess that'll be an extra benefit of keying off of the class object. I forgot to mention but we can certainly define a static variable on a class object today by manually adding a property as follows: class MyButton extends HTMLElement { ... } MyButton.template = document.getElementById('my-button-template'); so we don't have to block on ES7 to do this.
Moved to https://github.com/w3c/webcomponents/issues/135