[Webkit-unassigned] [Bug 182671] Implementation (or not) of customized builtins (is="" attribute)

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Mar 22 23:04:52 PDT 2022


https://bugs.webkit.org/show_bug.cgi?id=182671

--- Comment #18 from Stephen Belovarich <steveblue at gmail.com> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220323/6839d4fb/attachment.htm>


More information about the webkit-unassigned mailing list