customElements.define() should take a template as an argument

[hayatoito]

Title: document.registerElement should take a template as an argument (bugzilla: 28546)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28546

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28546#c0
Ryosuke Niwa wrote on 2015-04-22 23:53:24 +0000.

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:

Hi! <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.

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28546#c1
Hayato Ito wrote on 2015-04-23 00:18:27 +0000.

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?

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28546#c2
Ryosuke Niwa wrote on 2015-04-23 00:25:04 +0000.

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');
}

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28546#c3
Hayato Ito wrote on 2015-04-23 00:47:41 +0000.

(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. :)

---

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28546#c4
Ryosuke Niwa wrote on 2015-04-23 01:05:48 +0000.

(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.

[annevk]

@rniwa is this idea still something you want to do for v2?

[rniwa]

Yes.

[annevk]

There is implementer interest, but only as part of a larger effort to do declarative custom elements. So we'll keep this issue open, but we'll need the other parts before it'll move forward.