<div dir="ltr"><div>I don't think the customized built-in element is the right option. If I understand the spec correctly you'd just be replacing all the lifecycle events of the underlying element anyway.</div><div><br></div><div>Do you know how often do we switch between bindings like this? I'd lean towards just using different tag names, seems likely we could script a rewrite in most cases. Switching at runtime is a problem (in any case I'd imagine).<br></div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 12, 2018 at 4:00 PM Brian Grinstead <<a href="mailto:bgrinstead@mozilla.com">bgrinstead@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been thinking about how we can deal with situation where a single tag name gets multiple bindings attached based on a selector. For instance [0]: <br>
<br>
* `textbox` gets the `textbox` binding<br>
* `textbox[type="number"]` gets the `numberbox` binding<br>
* `textbox[type="search"]` gets the `search-textbox` binding<br>
* etc<br>
<br>
With Custom Elements, there are two approaches I've thought of:<br>
1) Make either 3 different tags (`textbox`, `textbox-number`, `textbox-search`)<br>
2) Fatten up the base binding to also keep track of if we are a number box, searchbox, etc.<br>
<br>
Both could work, but neither seems great - the former means we need to duplicate CSS selectors and modify any JS / C++ that’s looking for the tag name, and the latter could get hard to maintain with the number of widgets we have (including page-specific ones that override the main toolkit ones). Any other ideas on how to deal with this?<br>
<br>
One thing I noticed is that the spec is that there's a concept of 'customized builtin elements’ [1] where you can have things like:<br>
```<br>
class PlasticButton extends HTMLButtonElement { }<br>
customElements.define("plastic-button", PlasticButton, { extends: "button" });<br>
<br>
<button is="plastic-button">Click Me!</button><br>
```<br>
<br>
Which seems like it could map well onto our XBL inheritance if we could do:<br>
```<br>
class Textbox extends XULElement { }<br>
customElements.define(“textbox", Textbox);<br>
<br>
class SearchTextbox extends Textbox { }<br>
customElements.define("search-textbox", SearchTextbox, { extends: "textbox" });<br>
<br>
<textbox /><br>
<textbox is="search-textbox" /><br>
```<br>
<br>
However, that is not allowed as per 'If extends is a valid custom element name, then throw a "NotSupportedError" DOMException’ [2]. Is there a technical reason why we couldn't expose the `is` semantics used by customized builtins for extending other Custom Elements?<br>
<br>
Thanks,<br>
Brian<br>
<br>
[0]: <a href="https://bgrins.github.io/xbl-analysis/tree/#textbox" rel="noreferrer" target="_blank">https://bgrins.github.io/xbl-analysis/tree/#textbox</a><br>
[1]: <a href="https://www.w3.org/TR/custom-elements/#custom-elements-customized-builtin-example" rel="noreferrer" target="_blank">https://www.w3.org/TR/custom-elements/#custom-elements-customized-builtin-example</a><br>
[2]: <a href="https://searchfox.org/mozilla-central/rev/4114ad2cfcbc511705c7865a4a34741812f9a2a9/dom/base/CustomElementRegistry.cpp#731" rel="noreferrer" target="_blank">https://searchfox.org/mozilla-central/rev/4114ad2cfcbc511705c7865a4a34741812f9a2a9/dom/base/CustomElementRegistry.cpp#731</a><br>
<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</blockquote></div></div></div>