defining and instantiating customized built‐in elements as if they were autonomous custom elements

[zamfofex]

I think that a lot of people from #509 (at least @WebReflection, @trusktr, @oleersoy, the 14 people who upvoted the OP at the time of writing, and I) seem to agree that, even if it’s not ultimately bad, the is attribute doesn’t feel very natural, and isn’t very DRY. Even everyone who rejected the @trusktr’s original idea seemed to at least admit that is is not perfect.

There, as a less drastic option, I proposed that customized built‐in elements should be instantiated like autonomous custom elements, and at least @WebReflection thought it was a good idea.

Here I’m proposing that customized built‐in elements should be defined and instantiated like autonomous custom elements.

There are plans to give every native HTML element their own class. Then, the fact that the class used to define the custom element extends a native element’s class should be enough information that the element should be a customized built‐in element, and not an autonomous custom element:

class PlasticButton extends HTMLButtonElement {
  constructor() {
    super();

    this.addEventListener("click", () => {
      // Draw some fancy animation effects!
    });
  }
}

customElements.define("plastic-button", PlasticButton /*, { extends: "button" }*/);

Additionally, the fact that the element has been defined as a customized built‐in element should be enough information that, when created, it should be a customized built‐in element:

let plasticButton = document.createElement("plastic-button");
console.log(plasticButton.localName);          // will output "button"
console.log(plasticButton.getAttribute("is")); // will output "plastic-button"

Cons:

• It might not be clear from the createElement call that plasticButton.localName will be just "button". This issue would practically be inexistent in the real world, though, as development tools allow you to inspect the document tree, allowing you to clearly see the element’s tag name.

[oleersoy]

This definitely feels like the darts are getting closer to the bullseye. With all the bright people looking at this there has to be a solution that satisfies what everyone loves about is yet no one can say that it's confusing, not DRY, violates the Liskov Substituion principle, is vague with respect to element type identification (@trusktr comments), etc.

In other words, instead of introducing a content element for the shadow dom, and then later changing it to slot, lets just find the right solution to start with.

[oleersoy]

Just want to point out a few more things that are indirectly relevant. In the V1 shadom dom spec we have a NOTICE section pointing out:

Why you should never create web components with {mode: 'closed'}:

So why is it in the spec? Why are we all reading about something that we should never really use and that is useless? If we can come up with better solutions, then why did we not just do that in the first place?

Also this HTML Imports document refers to using the <script type="text/html">) element as a CrazyHack. So if we invented HTMLImport to get around the CrazyHacks approach then should not custom elements be THE TOOL for avoiding crazy hacks in the future and maintaining usage symmetry across html web development activities?

[trusktr]

I feel like #509 (comment) is easier to understand, and in that case your example following that pattern would be:

let plasticButton = document.createElement("plastic-button");
console.log(plasticButton.localName);          // will output "plastic-button"
console.log(plasticButton.getAttribute("is")); // will output "button"

It would be great if this pattern would hold for all of customized built-in elements (custom classes that extend from built-in classes), built-in elements, and autonomous custom elements (custom classes that don't extend from built-in classes).

It would also be super if is="" (or extends="") would accept customized built-in element names or autonomous custom element names, not just built-in element names.

[annevk]

I'm going to close this given that "There are plans to give every native HTML element their own class." never happened. That's a rather large-scale effort by itself that would have to be undertaken first and nobody has taken it up thus far even though it's been proposed for at least half a decade or so. If that happens one day perhaps some changes are possible along the lines of the proposal here, but I don't think we need to have a tracking issue for that.