[Webkit-unassigned] [Bug 237900] New: Customized built-in elements

[bugzilla-daemon at webkit.org]

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

            Bug ID: 237900
           Summary: Customized built-in elements
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: All
                OS: All
            Status: NEW
          Severity: Blocker
          Priority: P2
         Component: DOM
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: steveblue at gmail.com

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.

-- 
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/20220315/8c23ef86/attachment.htm>