web-platform-tests / web-platform-tests/interop
Customizable Built-ins, deprecate
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 524
- Forks
- 35
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 10
Description
Description
This might not be the "normal" way to use Interop, but I think this is something that should be actively discussed as we talk about the 2027 focus areas...
https://html.spec.whatwg.org/multipage/custom-elements.html#attr-is has been part of the HTML Spec for more than an decade now. In that time only Chromium and FireFox have put in the work to support the API in their browsers. Even with Chromium being a big proponent of this spec (at various points) it still doesn't have full support for it: https://wpt.fyi/results/custom-elements/htmlconstructor/newtarget-customized-builtins.html?label=master&label=experimental&aligned&q=customized%20builtins In fact, WebKit has actively stood for not shipping the API in their engine since possibly before the spec was even approved. With this in mind, and in lieu of vetoing members of the Interop planning committee keeping implementation of this API off the list for as many years as we've had the Interop program, I propose Interop does the unwelcome work of pushing to deprecate and remove the API from the spec and the browsers that have implemented it.
As a long terms web components devloper, a rabid supporter of spec development in this area, a sometime chairperson of the Web Components Community Group and a past lover of this spec/API, I realize that intelligent minds have decided that they can and will disagree as to whether this spec solves a real need or doesn't. There have been times when I have thought it a requirement of forward movement as far as web components are concerned, but evolving understanding of the myriad downstream APIs that would need to change or be added to make them actually of deep user points me to the idea that if WebKit will never agree to ship this API that it's better to close the door all together so that other APIs may get the sun needed to grow in its place.
I get that often Interop and its work to align functionality across browsers often mean "things to add", but in this case years of cycling on the concept points to the right thing for the Interop team and the HTML spec at large to do here is list this as "things to remove".
Specification
https://html.spec.whatwg.org/multipage/custom-elements.html#attr-is
web-feature
https://web-platform-dx.github.io/web-features-explorer/features/customized-built-in-elements/
Test Links
Additional Signals
WebKit opposition: https://github.com/WebKit/standards-positions/issues/97
Some possible alternatives that could get better support/focus in its place:
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the HTML customized built-in elements specification section, the web-features entry, and the linked WPT results to understand current support. Review WebKit standards-positions issue 97 and the suggested alternatives; done means reaching and documenting a decision about deprecating or removing the API from Interop, the specification, and implemented browsers.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- html
- Domain
- web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100