Html: ElementInternals should work with customized built-in elements

Created on 18 Dec 2019  路  3Comments  路  Source: whatwg/html

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().

  1. 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.

additioproposal custom elements

Most helpful comment

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.

All 3 comments

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.

Was this page helpful?
0 / 5 - 0 ratings