[TPAC Prep] Customized built-in elements: current status and blockers

[colepeters]

• Spec URL: https://html.spec.whatwg.org/multipage/custom-elements.html#customized-built-in-element
• Spec status:
  • Shipped in Blink and Gecko
  • Blocked in WebKit (see Customized built-in elements WebKit/standards-positions#97 and https://bugs.webkit.org/show_bug.cgi?id=182671)
• Report submitted by:
  • Cole Peters (cole@begin.com)
  • Kristofer Joseph (kj@begin.com)

Summary

This report summarizes the current status of the customized built-in elements spec, its uses cases, and current outlook.

Customized built-in elements (henceforth ‘CBiE’ for brevity) have been available in Chrome since version 67 and in Firefox since version 63, both released in 2018. However, they have not yet been made available in WebKit.

The WebKit team has stated that they will not be implementing CBiEs and have objected to the necessary is attribute — however they did nonetheless agree to keep it in the spec ‘until it gets removed’.

Despite WebKit’s firm position, we believe this issue demands closer scrutiny from the WHATWG, and efforts must be made to determine what can be done to resolve this blocker so that CBiEs may be used across all modern web browsers.

Use cases

Autonomous custom elements provide great flexibility to web authors to create powerful components while adhering to web standards and leveraging the web platform itself.

However, autonomous custom elements lack two critical features which are necessary for a myriad range of use cases which are foundational to HTML:

1. They cannot be used to compose HTML hierarchies within parent elements whose permitted content comprises a limited subset of built-in elements. For example, one cannot build a valid or semantically correct table using autonomous custom elements as table headers, footers, rows, or cells. The same is true for elements such as li, dt, dd, summary, and source, all of which must be written as direct children of their respective parent elements. (As such, note that simply wrapping a built-in element with an autonomous custom element would produce invalid HTML in these instances.)
2. Because autonomous custom elements do not extend from built-in elements, they cannot themselves participate in vital aspects of the DOM, such as:
   • sequential keyboard navigation (distinct from programmatically assigning focus via tabindex with JavaScript)
   • provision of element-based semantics to assistive technologies such as screen readers (which is preferred to the use of ARIA)
   • provision of document structure to the document outline

Due to these constraints and others, the HTML Living Standard itself states:

In general, for any elements with nontrivial behavior and semantics that build on top of existing elements of HTML, customized built-in elements will be easier to develop, maintain, and consume.

As such, we consider CBiEs as table stakes for custom elements as a whole, as without CBiEs being available, authors are blocked from implementing a wide range of foundational, semantic, and accessible interfaces.

The importance of these and other use cases are reflected in the fact of CBiEs having been part of the HTML Living Standard since 2016 and having been implemented in both Blink and Gecko since 2018.

Blockers

In a comment summarizing WebKit’s position on CBiEs and soliciting community feedback, the WebKit team identified a number of use cases for CBiEs and potential alternative solutions which WebKit sees as preferable compared to the CBiE implementation.

However, many of these proposed use cases focus primarily on using CBiEs within web forms, which — as demonstrated in this report and in the linked issue’s many comments — represents only a subset of use cases for CBiEs.

WebKit has also voiced opposition to the is='' attribute specifically, which at present is required for the use of CBiEs in supporting engines.

In lieu of implementing CBiEs and with respect to some of the blockers mentioned above, WebKit member Ryosuke Niwa expressed interest in several alternatives, namely Element Behaviors and Custom Attributes.

However, there are several problems with these suggestions, namely that the discussion on Element Behaviors was closed by WebKit member Anne van Kesteren in 2018 (citing lack of interest) and there appears to be nothing in the way of discussion on the linked Custom Attributes issue. Understandably, there is seemingly no visible support for these solutions from teams at Gecko and Blink, as these use cases are already addressed by CBiEs, which both engines have already shipped.

Ryosuke Niwa has clarified that WebKit’s position is fundamentally based on the fact they ‘don't think there are compelling use cases to justify the existence of this feature’, and that WebKit has not held off on implementing CBiEs due to overwhelming complexity, extant issues in WebKit’s codebase, or issues of resource allocation.

Recommendations

Web developers attempting to deliver truly cross browser compatible web content that leverages CBiEs are currently blocked from doing so. While a polyfill does exist, this is not a viable option for those who prefer not to take on the risk of a third party dependency in order to deliver functionality already covered by the HTML standard.

While WebKit may indeed have valid concerns over CBiEs as specified and currently implemented (and those concerns should be heard out), their response leaves web developers holding the bag at an impasse. There are currently no specs under discussion which would resolve the issues outlined in this report (extending elements within parents with strictly permitted contents, participation in foundational aspects of the DOM), which we believe are fundamental and important use cases.

Furthermore, despite being the sole holdout regarding the CBiE spec, WebKit has neither prioritized any alternatives, nor have they filed a dispute with the WHATWG Steering Group, as it seems would be appropriate per the WHATWG’s Working Mode and FAQ.

We suggest that this issue be given a priority examination by members of the WHATWG in the interest of convergence across browser engines. If indeed there are concerns significant enough to warrant deprecating CBiEs in the Living Standard, then work should be undertaken to do so. If not, it would seem that one of two paths forward should be prioritized:

1. WebKit should implement the CBiE spec as per the Living Standard.
2. The CBiE spec should be updated to satisfy any major concerns WebKit may have.

In either case, priority should be given to unblocking web developers seeking to execute the use cases outlined in this report.

[colepeters]

Looks like this topic will be discussed explicitly at TPAC, which is great: w3c/tpac2023-breakouts#44