Re: [w3c/webcomponents] The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. (#509)

I don't think the majority of developers understand the issues they are ranting/asking about. The engineers behind the specs took years to think it up and finalize it, it may not be perfect but here's some insight:

**The general pattern of comments state the issue of:**
   1. redundancy
   2. confusion of why "is" attribute is needed on tag.

First the redundancy. I do think this is redundant:
customElements.define("plastic-button", PlasticButton, { extends: "button" });

PlasticButton already extends HTMLButton in class syntax, solution is to modify customElements.define() to lookup the parent constructor/ancestor class of PlasticButton, which would resolve to HTMLButton. define() can then make the redundant (3rd arg) call under the hood.


SOLUTION to "is" attribute:
You have to understand the use-case and context problem to see why "is" is very necessary. Imagine 1 such use-case:

HTML hand-off from a graphics/css developer. He hands you HTML5 markup. You open the html, eith manually in an editor or programmatically using query-selection on DOM, and add "is" to one of the buttons that should be/is Plastic. You address a few things:

1. The semantics is preserved
2. Accessibility is preserved
3. Progressively decorated
4. Smallest possible change


I have done this tons of times before to decorate existing html but have been using a "namespace" attribute, pointing the namespace to a class:

<div namespace="core.ui.PlasticButton"></div>

and during app boot lifecycle, tags with "namespaces" would get decorated in place as PlasticButtons.

Without the "is"/namespace idea, doing this programmatically or even manually would be like chopping and re-declaring fragments all across the src.



-- 
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-448194242