[Custom Elements] Support extending elements

[imelnych]

After trying to follow this article and adding a custom button element I found that extend is not currently supported. Am I missing something? Are there any estimates on when it will be?
This seems very important but it's not even mentioned in https://github.com/webcomponents/custom-elements#differences-from-spec.

[retrocausal]

@imelnych do you have a code snippet of what you are trying to do?. Sometimes, just some text doesn't help people understand specifically what you are trying to say

From what I learnt, you can not extend native elements yet. you can only extend the generic HTMLElement.

[frinyvonnick]

The spec tells that you can extends built-in elements

[retrocausal]

but the specs need to be implemented yet. #6

you can follow the specs, only after the browsers support them natively, or when a polyfill is ready to support it. At this point neither are!

[imelnych]

To clarify, the code:

class FancyButton extends HTMLButtonElement {
    constructor() {
        //...

and:

customElements.define('app-drawer', AppDrawer);

My question was about it being supported by the polyfill.
As far as I understand is not yet.

[ebidel]

@justinfagnani when will the v1 polyfill support customized built-ins?

[justinfagnani]

I'm not working on it at the moment. We have to patch all the built-ins to make it work, which might be better as a separate script. PRs definitely accepted.

[jolyndenning]

I may be able to help out with implementing this. If I understand the spec correctly, custom built-in elements (which extend HTMLButtonElement or other native elements) can only be used with an is="my-custom-element" attribute, right?

So implementing this consists of:
(1) patching all the built in elements so they can be extended without throwing errors.
(2) Implementing dom mutation checking for is="..." attribute.

Sounds like work has definitely not started on patching the built in elements, but has work started on the is attribute?

[ChadKillingsworth]

You also have to patch document.createElement so that the 2nd argument can be an options argument with {is: 'foo-element'}.

[snuggs]

You also have to patch document.createElement so that the 2nd argument can be an options argument with {is: 'foo-element'}. - @ChadKillingsworth

TRUE! However, then you do not get the updated v1 custom element reactions that are all mutually exclusive to the v0 custom element reactions. As someone mentioned before this may be a duplicate of webcomponents/custom-elements#6 so preferred would be to close this out and subscribe to that issue. Hope this clears things up on the difficulties. I just dealt with this in a library Slim.js.

[wanttofly88]

Hi guys, Is this still an issue? It's not listed in "Known Bugs and Limitations", so I'm a bit confused.

[AndyOGo]

@wanttofly88
It is still an issue.

I really recommend using those battle tested and feature-complete custom-elements V1 polyfills provided by WebReflection:

• document-register-element, don't be confused by it's name it supports both spec version V1 and V0
• built-in-element

[emilio-martinez]

@AndyOGo people could use those, but I guess the question is—what does that mean for this project?

Patching built-ins could remain an add-on to the baseline custom elements polyfill, but shouldn't the ideal goal be to provide a polyfill path via the webcomponents org?

[AndyOGo]

@emilio-martinez
I can't tell where this project goes.

I just can tell, I used this project before, had this built-in issue and found those polyfills by WebReflection. So I compared these two and can only recommend to use them, they are battle-tested, zero-issues 0, impressive cross browser support, used for Google AMP, and they just work - even in Safari.

Demo: https://ungap.github.io/custom-elements-builtin/test/

The only "caveat", you can't use constructor... but really, who needs it, the DOM is live upon connectedCallback and not any time sooner

[justinfagnani]

We've been hesitant to support customized built-ins only because Safari is dead-set against it and we don't want applications to be stuck with a polyfill on Safari. As Firefox and Edge implement Custom Elements supporting customized built-ins, our calculus changes a bit and we've been considering it more recently, but requiring the polyfill for a very large portion of mobile users is still something to consider carefully.

As for a couple of points specifically:

used for Google AMP

This is not true anymore: https://github.com/ampproject/amphtml/blob/master/src/polyfills/custom-elements.js

The only "caveat", you can't use constructor... but really, who needs it, the DOM is live upon connectedCallback and not any time sooner

This is a really unacceptable caveat for us.

The other unacceptable caveat is that it doesn't work with ShadowDOM. See https://codesandbox.io/s/q292jm2nw