ElementInternals should work with customized built-in elements

[tkent-google]

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 ElementInternals: Add a capability to set the default focus behavior #5120
  Ditto?

• Default accessibility semantics for custom elements Allow setting default accessibility semantics for custom elements #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.

[rniwa]

Since Apple's WebKit team's position is that customized builtins shouldn't exist in the first place, we don't support this proposal.

[annevk]

I'm also not really convinced it's worth pursuing because of that.

[WebReflection]

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.

[ITenthusiasm]

The main reason I'd be interested in something like this is so that I can have Web Component form controls that can have their values auto-filled by browsers. But perhaps that's more of a browser problem?

[annevk]

That is already possible with form-associated custom elements.

[ITenthusiasm]

@annevk Really? I know that form-associated elements can have values submitted with the form, but I didn't know they can be autofilled. I couldn't get it to work when I was doing my own testing, but maybe I was doing something wrong. There's nothing special I should have to do for that, right?

[MichaelTheriot]

I just stumbled on this. I want to allow users to edit their file selections in a form and dedupe files automatically. There are UI libraries for this, but these are tied to a specific design. I wanted to create a universal web component others can build off of.

I extended <input> and used DataTransfer and the change event to manage files. But, accessing file buffers is async, so I need a state to indicate when the input is processing and ElementInternals to mark it as invalid during processing. This led me here.

I also found out (afterward) that Apple WebKit does not support extended built-ins. Both of these issues are forcing me to use autonomous custom elements to accomplish my goal here.

In theory that works, but in practice I need to faithfully reimplement/proxy HTMLInputElement.prototype and pray it is never updated forever, otherwise my clone goes out in sync. This feels like a hack; I am just creating a wrapper for one element and the entire purpose of my element is to emulate it. Why? Does ARIA work? Do we make wrappers every time, for each library?

My opinion is that my use case is simple enough that it does not warrant reimplementing/proxying the most amorphous element that exists. I can make a wrapper around an input element, but I need to bubble up all of the element's prototype properties to my wrapper, and some time in the future if any new functionality is added I will have to update my wrapper to support it.

I think this is missing the point of web components; there is nothing reusable about reimplementing an existing element and it is actually less of a maintenance burden into the future if I just do not use web components. This was a fun journey, and I even found a bug in V8 with DataTransfer that I have now reported, but in the end I am just going to invest time building something that is specific to my use case and not universally available like I originally planned. I am hoping in the future proposals like these are implemented so that it is easier for other developers that have similar interests.

[denis-migdal]

Nowadays, it is often possible to put an builtin element into an autonomous custom element with a display: contents. Not ideal, but it will work for some cases.

However, in other cases, e.g. in tables, you are forced to use custom builtin elements.
Then, if you want your custom tr to have a state, you are forced to use classes.

This is a pain as you might have some autonomous custom elements with ElementInternals states, and some custom builtin elements without but using classes. It'd be simpler to have an unique case to handle, instead of 2.
Note: This is the same issue with shadowRoot, as some elements can have children, but can't have a shadowRoot, e.g. tr.