Re: [w3c/webcomponents] Why must the is="" attribute exist? (#509)

> The problem here is that UA internally checks local name e.g. element.localName == aTag to do various things, and all of that code needs to be updated to account for the fact there could be an intense of HTMLAnchorElement whose local name is not a.

I think that relying on element tag names might be a bad idea, especially if we [give users ability to scope elements on a per-shadow-root basis](https://github.com/w3c/webcomponents/issues/488) (now *that's* a good idea!). If we can allow end users of a custom element to assign any name they wish to that custom element used within the user's component (within the user's component's inner shadow tree), then we can avoid the global mess that `window.customElements` will be when an app gets large and when people widely adopt Web Components (wide adoption is one of the goals here).

In React (by contrast) the creator of a component *never* decides what the name of that component will be in the end user's inner tree. The end user has full control over the name of an imported component thanks to ES6 Modules. We can encourage a similar concept by introducing a per-shadow-root custom element registration feature.

If we can map names to classes without collision and without two names assigned to the same class (i.e. without elements like `<q>` and `<blockquote>` sharing the same class), then we should be able to use `instanceof` instead of checking tag names, and element inheritance can be based solely on ES6 class extension, as it should be (rather than having the extra `is=""` feature). The change that would be needed here would be to ensure that the native elements map to separate leaf classes so it's possible to tell a `<q>` element apart from a `<blockquote>` element with `instanceof` and therefore encouraging that sort of checking over tag names.

This API is still v0 in practice, so I think there's room for modification even if v1 is on the verge of coming out.

> Apple objects to extending subclasses of HTMLElement using is=

I think Webkit not implementing `is=""` may be a great thing.

If we continue with globally registered elements, it will be inevitable that some two components in an app will have a name collision, and that the developer of that app will attempt to fix the problem by modifying the source of one custom element (possibly requiring forking of an NPM module, pushing to a new git repo, publishing a new module, etc, time consuming things) just to change the name of that element; it'd be a pain and can introduce unexpected errors if parts of the modified code are relying on the old tag names.

TLDR, if we put more care into the JavaScript aspects of an element (f.e. choosing which class represents an element, which is already happening in v1) then we'll have a more solid Web Component design, and we can drop `is=""`. It will also require fixing things like the `<q>`/`<blockquote>` problem.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/509#issuecomment-224131104