Bug 182671 - Implementation (or not) of customized builtins (is="" attribute)
Summary: Implementation (or not) of customized builtins (is="" attribute)
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
: 187849 195403 231575 (view as bug list)
Depends on:
Blocks: 154907
  Show dependency treegraph
Reported: 2018-02-10 14:32 PST by Joe Pea
Modified: 2021-10-13 13:47 PDT (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Joe Pea 2018-02-10 14:32:50 PST
Hello, just making this issue to track the possible implementation (or possible desired lack-of-implementation) of customized builtins and the is="" attribute.

Ryosuke mentioned at https://github.com/w3c/webcomponents/issues/509#issuecomment-222860736 that Safari/Webkit would not implement is="". I'm against it.

I'm just opening this issue so that if/when Safari/Webkit decides to change their minds about is="" (I hope not) that we can be notified here.

(if I missed another issue, please link me there.)

P.S., I implemented an idea (in JS), "Element Behaviors", which is an alternative to is="" without some of the problems: https://github.com/w3c/webcomponents/issues/727.
Comment 1 Ryosuke Niwa 2018-08-15 19:20:13 PDT
*** Bug 187849 has been marked as a duplicate of this bug. ***
Comment 2 Ryosuke Niwa 2019-03-09 18:24:45 PST
*** Bug 195403 has been marked as a duplicate of this bug. ***
Comment 3 Andrea Giammarchi 2019-06-27 06:40:44 PDT
As soon as Edge will ship on Chromium everywhere, WebKit will be the only browser not supporting this part of the living standard.

The popularity of the related polyfill is indeed increasing https://www.npmjs.com/package/@ungap/custom-elements-builtin and there are more and more projects directly or indirectly dependent on such polyfill.

The polyfill is 100% based on Custom Elements V1 and other Web standards, and it provides a great experience in WebKit/Safari without penalizing performance in a relevant way.

There are also a variety of posts from Web developers;community where the #1 complain is the "inability to extend builtin elements", which not only is false, since once polyfilled WebKit you cam do that alredy everywhere, but there are also various libraries using Server Side Rendering with builtin extends as a key feature.

AFAIK, the WebKit team has been always quite pragmatic in implementing features everyone uses anyway, so that polyfills won't be forever needed, hence I wonder if there will ever be the possibility to reconsider the WONTFIX, giving the feature has been desired for long time, but never landed natively in WK/Safari.

The inability of this browser to extend builtin is also feature-detectable, meaning it's easy to "penalize" WK/Safari after such feature detection, but in an ideal world, even not so ergonomic/elegant specs should be available cross browser, so that developers get a choice, and such choice comes from the platform.

As summary, please re-consider the current WK/Safari position, and provide a consistent cross-browser implementation of something voiced over and over as desired from Web developers.

Re-iterating on a possible V2 is always an option, but Custom Elements can be fully used already today, so it'd be super nice to have all the features natively available everywhere.

Comment 4 em 2019-12-27 09:06:48 PST
I realize this item is marked as "wont fix". But is there any update on Webkit's position on implementing this? It's been quite a while since the last comment and would love to know if anything has changed. Thanks!
Comment 5 Ryosuke Niwa 2019-12-27 16:24:35 PST
Nothing has changed.
Comment 6 Joe Pea 2019-12-27 18:36:21 PST
Mark, in case it helps, I have an alternative to the is="" attribute at https://github.com/infamous/element-behaviors.

It works almost exactly the same as Custom Elements and the is="" attribute, except it is simpler, does not rely on extending native classes, and any element can have more than one "behavior" applied to it.

If you already have code like `is="awesome-button"`, then it is very easy to port to element-behaviors (and get it working in all browsers without crazy polyfills like are needed for Custom Elements) by converting it simply to `has="awesome-button"`.

The main differences are:

1) An element can have more than one class ("behavior") applied to it, so you can write `has="awesome-button cool-thing other-stuff"`.

2) Instead of `this` referencing the element, the constructor receives the element as a single arg (you can then store it on `this.element` or whatever you prefer).

So here's a simple full example:

class AwesomeButton {
  constructor(element) { this.element = element }

  // the same life cycle methods that you're familiar with:
  connectedCallback() { console.log(this.element.tagName + ' is connected') }
  disconnectedCallback() { console.log(this.element.tagName + ' is disconnected') }
  attributeChangedCallback(attr, oldVal, newVal) { ... }

class CoolThing { /* ... similar ... */ }
class OtherStuff { /* ... similar ... */ }

elementBehaviors.define('awesome-button', AwesomeButton)
elementBehaviors.define('cool-thing', CoolThing)
elementBehaviors.define('other-stuff', OtherStuff)

then in your HTML:

  <tr has="awesome-button cool-thing other-stuff">

This literally let's you do the same thing as with Custom Elements, but without the problems. It is fully compatible with old browsers (through transpilation to ES5 or ES3) without any of the caveats (as you may know already, the polyfills for Custom Elements are very tricky to use, but these problems are all non-existent with element-behaviors).
Comment 7 Joe Pea 2019-12-27 18:39:38 PST
I forgot to show in my previous comment that you need `observedAttributes` defined in order for `attributeChangedCallback` to work, just like with custom elements.

class AwesomeButton {
  // ... same as before, but you also need this:
  static observedAttributes = ['list', 'attributes', 'to', 'observe']
Comment 8 em 2019-12-27 21:01:05 PST
Thanks for providing more context, Joe! I just invested quite a bit of time getting up to speed with WebKit's position on this in https://github.com/w3c/webcomponents/issues/509. Your approach seems more like a mixin and seems much more flexible. Is there any reason why Webkit can't just proposed it as a replacement for is="" in the spec? Based on the comments in that Github issue, I don't think many devs would oppose it. Most of us just want a way to extend builtins and care less about how it's done. Trying to gain consensus on this as a replacement to the spec may be more beneficial to everyone than removing the only way to extend builtins entirely, which is what Webkit's position on the matter suggests.
Comment 9 Joe Pea 2019-12-29 10:53:33 PST
I'd love to have something like "element behaviors" (or whatever it would finally be called) be an actual standard.

So far I've only implemented this as a concept, but I believe for it to gain traction would require a formal proposal to be presented. I'd need to fork and familiarize myself with the proposal template, and learn the official lingo for describing things in the proposal. Maybe I can look into this once I have (if I get) time.

> Is there any reason why Webkit can't just proposed it as a replacement for is="" in the spec?

Basically my element-behaviors concept is something I made, and I'm not affiliated with any browser vendors. I'm so far just an enthusiastic web developer in the web community. This isn't to say browser vendors may not like the idea, but perhaps that a formal proposal would be a way to get formal input from browser vendors, and it would show a willingness (from me, or whoever makes the proposal) to help maintain a spec.

One way that I see proposals being made lately is on GitHub with Markdown. For example: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md

But ultimately I believe that they need to be put into a format like official standards. For example this is what the DOM spec looks like: https://dom.spec.whatwg.org. And the source for it appears to be here: https://github.com/whatwg/dom.

So I believe to make this idea a serious proposal, we'd need to spend some time to propose actual changes to the spec with pull requests in that repo.
Comment 10 Andrea Giammarchi 2020-01-08 07:01:38 PST
So ... basically your elements behaviour would just need some "crazy polyfill" for other 2 years, instead of needing a tiny one for the only browser that doesn't implement custom elements built-in extends, which can be feature detected, right?
Comment 11 Joe Pea 2020-01-22 13:37:47 PST
Hello Andrea, the implementation of element-behaviors, and the implementation of custom-attributes on which it is built upon, are both MUCH simpler than the "tiny" polyfill that you're mentioning. If browser adopted those, they'd work with *pure* ES5 classes, without native class syntax restrictions.
Comment 12 Joe Pea 2020-01-22 13:39:26 PST
I forgot to link to custom-attributes, for reference: https://github.com/matthewp/custom-attributes/

Both are much simpler than any Custom Element polyfills because they require *no* extension of builtin classes.
Comment 13 Andrea Giammarchi 2020-01-23 23:46:39 PST
My point is rather that these proposals will require polyfills too, and kinda heavy ones, due MutationObserver on attributes as well as any other children.

Right now no browser requires polyfill for Custom Elements built-in extends, except Safari/WebKit, and the polyfill is neither complex nor heavy, plus it can be used after feature detection, resulting in zero overhead.

These new proposals also seem to suffer same name-clashing issues CE have already, but in general, keep adding APIs not implemneted by all vendors doesn't seem attractive for developers ... we should've learned this by this time.
Comment 14 Joe Pea 2020-01-24 10:15:42 PST
Of course a polyfill is heavier than a native implementation. These are not heavier than a custom-elements polyfill is.

Another point is, if these became native, then they'd be lighter-weight and easier to use than Custom Elements, without the main problems of Custom Elements (extending builtins, and parser limitations, they would work perfectly fine on SVG elements).

Element-behaviors and custom-attributes would be better and less-restrictive forms of the `is=""` attribute.
Comment 15 Andrea Giammarchi 2020-01-24 10:20:32 PST
> These are not heavier than a custom-elements polyfill is.

You keep talking about crazy polyfills, and this 1K poly https://github.com/ungap/custom-elements-builtin has nothing crazy in it and it's not heavier than any other needed after those proposals ... so I am not really following your arguments.

It's already tested on all Desktop and Mobile WebKit based browsers and it works without "being crazy" or "heavy", so once you reason your arguments with some fact maybe I'll be able to reply.
Comment 16 Sam Sneddon [:gsnedders] 2021-10-13 13:47:04 PDT
*** Bug 231575 has been marked as a duplicate of this bug. ***