webcomponents / polyfills

Web Components Polyfills
BSD 3-Clause "New" or "Revised" License
1.13k stars 165 forks source link

[Custom Elements] Support extending elements #102

Open imelnych opened 7 years ago

imelnych commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

The spec tells that you can extends built-in elements

retrocausal commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

justinfagnani commented 7 years ago

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.

joeldenning commented 7 years ago

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 commented 7 years ago

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

snuggs commented 6 years ago

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 https://github.com/webcomponents/custom-elements/issues/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 commented 5 years ago

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

AndyOGo commented 5 years ago

@wanttofly88 It is still an issue.

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

emilio-martinez commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

AndyOGo commented 5 years ago

Thanks for your reply.

Safari is dead-set against it

I know, what a bummer... Anyway regarding a polyfill I would not follow a non-spec-compliant decision made by Safari.

This is not true anymore

Interesting, I only know that WebReflection is sponsored by Google to bake it 🤔

This is a really unacceptable caveat for us.

Here I disagree, it comes with far less problems if any component just relies upon connectedCallback, attributeChangedCallback and disconnectedCallback. If initialisation is needed, it can be very easily added by lazy inits.

The other unacceptable caveat is that it doesn't work with ShadowDOM.

IMHO ShadowDOM itself is a caveat, just because it never can't be 100% polyfilled. You can't stop the CSS cascade...

prushforth commented 5 years ago

@justinfagnani

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

What is your example supposed to do / not do? When I click the autonomous element containing the shadow root containing a built-in button, it seems to work ? Thanks.

image

justinfagnani commented 5 years ago

@prushforth in Safari that doesn't work.

prushforth commented 5 years ago

@justinfagnani right, of course

rowanc1 commented 4 years ago

I am curious if the polyfill here: https://github.com/ungap/custom-elements-builtin could help?

I would love to see this be better supported across the browsers who are behind the W3C spec!!

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.