Bug 182671 – Implementation (or not) of customized builtins (is="" attribute)

• Status: RESOLVED
• Resolution: WONTFIX
• Component: DOM

[Joe Pea]

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.

[Ryosuke Niwa]

*** Bug 187849 has been marked as a duplicate of this bug. ***

[Ryosuke Niwa]

*** Bug 195403 has been marked as a duplicate of this bug. ***

[Andrea Giammarchi]

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.

Thanks.

[em]

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!

[Ryosuke Niwa]

Nothing has changed.

[Joe Pea]

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:

```
<table>
  <tr has="awesome-button cool-thing other-stuff">
    <td></td>
  </tr>
</table>
```

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).

[Joe Pea]

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']
}
```

[em]

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.

[Joe Pea]

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.

[Andrea Giammarchi]

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?

[Joe Pea]

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.

[Joe Pea]

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.

[Andrea Giammarchi]

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.

[Joe Pea]

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.

[Andrea Giammarchi]

> 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.

[Sam Sneddon [:gsnedders]]

*** Bug 231575 has been marked as a duplicate of this bug. ***

[Sam Sneddon [:gsnedders]]

*** Bug 237900 has been marked as a duplicate of this bug. ***

[Stephen Belovarich]

Putting this here because the ticket I submitted was marked duplicate.

Web Components are now a foundational building block for user interface development on the web, although many portions of the set of specifications that comprise Web Components are missing in WebKit. This issue focuses on one of those missing specifications, customized built-in elements.

A ticket was generated here previously about customized built-in elements https://bugs.webkit.org/show_bug.cgi?id=182671 that was marked RESOLVED WONT FIX. Would WebKit please reconsider implementation of this specification?

Customized built-ins have proven invaluable while developing buttons, tables, and forms. While form-associated custom elements (another missing specification in WebKit), provide robust tools for form inputs, a customized built-in could be extended from `HTMLFormElement` to provide custom functionality for handling the form. `HTMLTableElement` and associated table elements provide necessary APIs for tables. Customized built-ins provide a means to extend table elements,  allowing engineers to retain the characteristics of table elements, while providing rich user experiences, like the ability to show and hide form inputs in table cells. Similarly, by extending `HTMLButtonElement`, an engineer is able to retain all the Accessibility characteristics of a button, while layering custom business logic.

The use cases for customized built-ins have proven the specification is useful, however shortly after the specification was introduced, a WebKit representative remarked "I'll note that we've vocally and repeatedly objected to having is=, and in fact, stated publicly that we won't implement this feature, but somehow the WG kept it in the spec. I wouldn't call that a consensus. We extremely reluctantly agreed to keep it in the spec until it gets removed at risk later." (https://github.com/WICG/webcomponents/issues/509)

Critique is always welcome, but never the less the customized built-ins specification has made it into Google Chrome, Mozilla Firefox, Microsoft Edge, but remains absent in Apple Safari. 

This causes engineers to have to load a polyfill for Safari to gain support for customized built-ins. That diminishes the benefit of custom elements, which should be able to be used by software developers sans-framework or library. 

In the same thread about customized built-in elements an engineer recently remarked...

The Hotwired framework depends on the turbo-frame custom element to progressively enhance a webpage. However, using it inside a table fails, for the obvious reason (content model). I figured it could work as a <tbody is="...">. And it does! After abstracting the constructor into an constructor factory, able to extend any built-in as a customized built-in, we found it works great. Except in Safari of course where it doesn't work at all.  (https://github.com/WICG/webcomponents/issues/509#issuecomment-1067516870)


Would WebKit please reconsider the decision not to implement customized built-in elements? By adding customized built-ins into WebKit, engineers can rely on a stable platform for coding Web Components. With customized built-in elements, form-associated custom elements, and Declarative Shadow DOM missing in WebKit, the set of specifications known as Web Components remains fragmented. Web Components are a fundamental building block for UI development on the web. In order for engineers to make interoperable UI components, they need a stable platform to build upon, but as of right now, the platform is broken.

To quote Jen Simmons on the Webkit blog...

"From the very beginning, the web was always intended to work in any browser, on any computer. This is possible through interoperability — when each underlying web technology is implemented in the same way in every browser. To reach interoperability, it takes a commitment from all browser engineers to implement web technology according to web standards — the incredibly detailed specifications where new technology is defined."

So would it be possible for WebKit to reassess the position on customized built-ins and reprioritize the specification's addition to Webkit?

Can we please get a response from the WebKit team?

[Kellen Green]

I too would like to raise my hand in support for shipping something we can all agree on. Whether it be agreeing to disagree and implementing V1 as is or coming up with an improved V2 proposal. If I'm being honest I too think the is="..." attribute is a bit awkward, but having said that I also feel this feature is important enough to reevaluate 4 years removed.

[Jordan]

Very disappointed today when I discovered is="" is not going to work in Safari/WK.

Web developers slogged through two decades of exceptions for IE and thankfully that era is over, but here we are begging a browser to just implement the spec so we can use native platform features without hacks/polyfills/frameworks.

Poor Web Components have had an uphill battle as it is, so please help and just implement is="" already (or put up something better!). Doing nothing hurts everyone.

[Andrea Giammarchi]

Once again, and to whom it might concern, the less than 2K poly can land either feature detected [1] or through exclusion the browser is neither Chrome nor Firefox [2].

All metrics for SEO score 100% and performance are not affected for all browsers but also extremely fast on WebKit based devices.

Move the polyfill from CDN to same site and let's use it instead of keep telling them we need built-in extend, shall we?

It's clear the situation and limitations have been stuck forever and won't change until Web developers understand there's nothing to wait for and things can work out of the box for everyone.

Please note all approaches are based on a feature no ShadowDOM will ever enable, as it is a script tag in the head of an HTML file that's extended to understand if the functionality is available or not ... this is just yet another scenario builtin extend demonstrate their superiority: head elements otherwise impossible to hook into through the regular Custom Element Registry.

Another missing opportunity for the future of the Web.

[1] https://codepen.io/WebReflection/pen/xxWaVKo
[2] https://codepen.io/WebReflection/pen/bGvYdVw

[Mateusz Daniluk]

Is there any chance the webkit will implement this?

What are the arguments against? I would like to collect these arguments in one place.

[Anne van Kesteren]

Mateusz, thank you for that suggestion. We've put up our thinking in this issue: https://github.com/WebKit/standards-positions/issues/97.