Spec: https://html.spec.whatwg.org/C/#dom-attachinternals
Now ElementInternals doesn't work with customized built-in elements because of the first step of attachInternals().
- If element's is value is not null, then throw a "NotSupportedError" DOMException.
We can't support Custom State Pseudo Class for customized built-in elements because of this restriction.
Proposal: Remove the step 1.
We need to triage all of IDL attributes/operations of ElementInternals.
Attributes/operations for Form-associated custom elements
Add "Throw "NotSupportedError" DOMException if target element's "is" value is not null." to them
Default focus behavior https://github.com/whatwg/html/pull/5120
Ditto?
Default accessibility semantics for custom elements https://github.com/whatwg/html/pull/4658
I'm not sure if the current PR is reasonable for customized built-in elements. @domenic ?
Custom State Pseudo Class
It should work with customized build-in elements. We need to remove 'autonomous' from the specification.
Since Apple's WebKit team's position is that customized builtins shouldn't exist in the first place, we don't support this proposal.
I'm also not really convinced it's worth pursuing because of that.
Since Apple's WebKit team's position is that customized builtins shouldn't exist in the first place, we don't support this proposal.
As there is already a polyfill that can be used after features detection, and as it works well already on every Apple platform/browser, there could be a polyfill to support this too, if not the same polyfill to grant consistent API usage across browsers.
Accordingly, I don't think Safari/WebKit should be a blocker, when Chrome, Firefox, and latest Edge, supports Custom Elements built-ins out of the box, and when polyfills showed already it's possible to have the same mechanism on Apple's WebKit browsers, also without affecting performance too much (Apple HW is one of the best, if not the best, so no side-effects on users devices).
However, I think WHATWG/W3C should either drop built-ins officially, or Apple's WebKit team should be pragmatic, and provide what the community asked already for years: built-in extends.
There are also zero official alternative proposals to enrich built-ins, so I don't honestly understand why this is still being discussed, 'cause this is in specs, and it has shipped already for years.
Best Regards.
Most helpful comment
As there is already a polyfill that can be used after features detection, and as it works well already on every Apple platform/browser, there could be a polyfill to support this too, if not the same polyfill to grant consistent API usage across browsers.
Accordingly, I don't think Safari/WebKit should be a blocker, when Chrome, Firefox, and latest Edge, supports Custom Elements built-ins out of the box, and when polyfills showed already it's possible to have the same mechanism on Apple's WebKit browsers, also without affecting performance too much (Apple HW is one of the best, if not the best, so no side-effects on users devices).
However, I think WHATWG/W3C should either drop built-ins officially, or Apple's WebKit team should be pragmatic, and provide what the community asked already for years: built-in extends.
There are also zero official alternative proposals to enrich built-ins, so I don't honestly understand why this is still being discussed, 'cause this is in specs, and it has shipped already for years.
Best Regards.