web-platform-tests / web-platform-tests/interop

Customizable Built-ins, deprecate

Open
#1,342 1 comment 20 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

focus-area-proposal
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

https://wpt.fyi/results/custom-elements?label=master&label=experimental&aligned&q=customized%20builtins

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.