Stencil: Can I define extended build-in elements?

[AndyOGo]

Stencil version:

 @stencil/core@<version>

I'm submitting a:

[x] bug report
[ ] feature request
[ ] support request => Please do not submit support requests here, use one of these channels: https://stencil-worldwide.herokuapp.com/ or https://forum.ionicframework.com/

Current behavior:

I couldn't find a clear statement about whether only <autonomous-custom-element> and/or <div is="extended-built-in-element"> are supported.

Expected behavior:

Should cleary state support for:

• [ ] <autonomous-custom-element>
• [ ] <div is="extended-built-in-element">

Steps to reproduce:

Nothing here https://stenciljs.com/docs/decorators nor here https://stenciljs.com/docs/browser-support

[arjunyel]

You can't and won't be able to, Safari said they will never support is="" so unfortunately it's dead in the water

[AndyOGo]

What a bummer, extending built-ins is a key feature.

I created a bug ticket at webkits issue tracker:
https://bugs.webkit.org/show_bug.cgi?id=195403

And here is a built-in polyfill by @WebReflection:
https://github.com/WebReflection/built-in-element

[arjunyel]

Unfortunately that bug will be closed :( https://github.com/w3c/webcomponents/issues/509#issuecomment-222860736

And even with a Polyfill I dont think stencil will support it because Stencil tries to stick to the web platform as close as possible. I would recommend not using is="" unless you dont need to support Safari

[AndyOGo]

Ohhh, how can they do that. EXTENDED BUILTINS are living standard😲

Thanks for your feedback anyway

[WebReflection]

FYI the right polyfill is this one.

StencilJS used to be based on document-register-element which supported already custom elements builtins.

However, Firefox and Chrome ships already CE with built-in extends, WebKit is just playing the push back but it's polyfilled with the link I've posted.

Regards

[FRSgit]

@arjunyel considering whole discussion under w3c/webcomponents#509 (especially that comment) I must say that conclusion even with a Polyfill I dont think stencil will support it because Stencil tries to stick to the web platform as close as possible is pretty suprising to me.

Extending native components is a living standard already and there is no reason to oppose it.

IMO benefits coming with using <element-name is="..."> notation (accessibility, SEO, etc) outweight any problems it can bring for stencil developers.
From my company's perspective not having this feature (at least in future plans) can be a killer for using stenciljs at all :<
Do we know what's the stencil-team official position on this?

[WebReflection]

@FRSgit don't forget with MS Edge now being based on Chromium, Webkit based browsers will be the only not shipping custom elements built-in extends.

The Apple/Webkit team is very opinionated (and for reasons), but they are also quite pragmatic: when they see ther's no reason to not support something widely available elsewhere, they just go for it, even if they initially never agreed on that.

The reason they are pushing back is, in my speculative opinion, that legacy is tough to touch, and what's in HTML already should stay there where nobody needs to change a single thing.

Regardless, they are one of the best devs out there, so I think it'd be safe for Stencil to simply adopt this poly and, in the worst case scenario, be slightly slower on the already fastest platform out there: Apple hardware.

All other browsers will work out of the box.

[FRSgit]

After some talks with @manucorporat (unfortunately some of my questions were left unanswered :<) I've got an info that stencil won't support this at all.
There will be one possibility to overcome that limitation with stencil one - that, new version will allow to output vanillaJS custom elements which one could of course register as extending natives. Problem is that these components would loose some of Stencil's functionalities, so probably this feature won't be so helpful in prod cases, but well, that's at least something..

[johnstrickler]

I'd like to stop re-implementing basic functionality that native elements provide but there's only two ways that I know of building off of native elements:

• Extending native elements
• Passing all props/attributes to a single wrapped child

I know the first isn't possible with Stencil but it'd be nice to hear the technical explanation of why it's not a priority. Is it technically not feasible? Overly complex?

Is the second option doable? Or would I have to explicitly list out every native property then pass it to the native child element?

What are other Stencil users doing? Is everyone else implementing native functionality over again?

[WebReflection]

@johnstrickler

I know the first isn't possible with Stencil but it'd be nice to hear the technical explanation of why it's not a priority. Is it technically not feasible? Overly complex?

It's already solved, you need one single script upfront and you can forget about custom elements built-in issues: https://github.com/ungap/custom-elements-builtin#all-possible-features-detections

Is everyone else implementing native functionality over again?

Not me, and I've created a project that is basically fully based on custom elements built-in extends, and it offers SSR out of the box. It's called _heresy_, ping me on twitter to know more 👋

[johnstrickler]

@WebReflection Thanks for the info. Great looking library :)

I was asking those questions in the context of Stencil though. Will Stencil ever be capable of re-using native elements? Frankly, it's huge waste of time, and very bug prone, to reimplement functionality that you get for free from native elements.

[AndyOGo]

@adamdbradley @manucorporat @jthoms1 I'm sure your feedback regarding support of extended built-in elements and the is="my-element" syntax within Stencil is very welcome.
I would appreciate it a lot if you find some free time to discuss this?

[kneyugn]

Coming from accessibility stand point, I think having this feature in Stencil will reduce a lot of time wasted reimplementing native elements and making them accessible again, as @johnstrickler said, very bug prone. Already, we see this in Ionic's core components. A lot of aria usage could be reduced. Ex: There's some of work involved in making sure the buttons have same parity with native buttons in forms. Could built-in elements have helped with this?

edit: My main concern is, is an IE11 polyfill possible? The example does not seem to work in IE11.
update: it does :) https://ungap.github.io/custom-elements-builtin/test/es5/

[WebReflection]

@kneyugn it doesn't work on IE11 only, it works down to IE9 and, with some extra poly and caution, even IE8, plus every older mobile browser.

There are two polyfills involved here, the one for browsers that don't support customElements at all, provided by the long-time battle-tested document-register-element polyfills, which lands on legacy via a single top level script:

<script>this.customElements||document.write('<script src="https://unpkg.com/document-register-element"><\x2fscript>');</script>

This polyfill has fueled Google AMP, Mozilla AFrame, and even StencilJS, for years, providing customElements with built-in extend capabilities without major issues (issues count is zero) and for long time.

However, that poly doesn't even try to bring ShadowDOM (unpolyfillable in a reliable way), which is why I believe StencilJS ditched it, but the good thing is that there are work arounds for that too (either polyfills or basic implementations that use iframes instead), and yet every modern browser that supports customElements natively, won't need any Shadow DOM polyfill, and only WebKit/Safari can use the dedicated script that can also be implemented after feature detection, making the top level script more like:

<script>
if(this.customElements)
  try{customElements.define('built-in',document.createElement('p').constructor,{'extends':'p'})}
  catch(s){document.write('<script src="//unpkg.com/@ungap/custom-elements-builtin"><\x2fscript>')}
else
  document.write('<script src="//unpkg.com/document-register-element"><\x2fscript>');
</script>

... wait, wasn't document.write bad?

To start with, that's a legacy feature that won't go anywhere any time soon, because it would break otherwise the Web if removed from the platform.

document.write is an essential mechanism to grant execution of a script before other scripts, and even if it's blocking, like any other top level script on the page that doesn't use deferred or async, it's used only by legacy browsers, so that every modern browser won't ever reach that part of the code: it's basically unreachable death code for ~90% of the real-world surfers.

In WebKit/Safari case thought, it's necessary to grant next script, whatever that is, can already define Custom Elements built-in extends, and still it's only for WebKit/Safari, but the poly is around 1K, so it shouldn't penalize anyone out there, specially if hosted via CDN, and specially 'cause such polyfill hasn't really changed much for months (years?) 'cause it "_just works_" within its constructor caveats, something any library can circumvent in a way or another.

TL;DR there is a polyfill that is not obtrusive and vaporware for the majority of the Web surfers, so that arguments against it, when dozen of other polyfills are landed here and there via Babel or polyfill .io service, are always, imho, weak.

[mfranzke]

This ticket died (got closed) very silently. Is it because everything has been said (even though not discussed to an end/finding a consens) and/or the frameworks creators opinion has even already been reflected?

[chris-dura]

Perhaps I've missed it in the thread, but currently, I'm under the impression that we can't even use the polyfill(s) with StencilJS?

So, I currently believe that if I want to extend native elements, I _cannot_ use StencilJS for my component library ...

if that's incorrect, and we _can_ use the polyfill as a workaround with StencilJS, someone please correct me!
(and I might ask for an example 🤣)

[RS-Sautter]

@manucorporat @adamdbradley Could you please reopen & comment on this? I think this is a important issue for many users.