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

I'll throw in, I think I read enough to get the gist. And, sorry for not reading the participation rules first (if there are any).

For this topic I want to say, I was thrilled to hear about `is`...and it had nothing to do with web-components as they relate to the Shadow DOM, HTML imports, and so on.

I think part of the issue is determining who the heavy in the room is, so to speak. Putting more of the definition in JS makes JS more of the heavy; thereby, tightly coupling markup to JS. (Given where we are, makes sense.)

Having said that, when I built my component libraries for PHP (obviously no JS there), here's where it's at (it looks a bit like React's createElement method, and when we use the factory it feels more like Elm's HTML library).

```php
Component::make(string $element, array $attributes, Component ...$content)

Component::element(content, content, content, ...)->attr()
```

These factory methods return an instance of Component, not a subclass of it, yeah? There's a method you can call to "extend" it...change the HTML output (makes HTML the "heavy") - via the [open to extension not modification principle](https://en.wikipedia.org/wiki/Open/closed_principle). 

So:

```php
Component::my_button()->print()
```

```html
// output
<my-button></my-button>
```

```php
Component::my_button()->extends('button')->print()
```

```html
// output
<button is="my-button"></my-button>
```

>From an OO perspective, it's communicated literally like inheritance, but feels more like dependency injection:

Like my-button saying, "I am my own button (instance), but I depend on your button; so, with me." 

Flipping it around, again via open to extension, it's more like HTML's button saying, "I know you're your own button, but I'll take the lead here."

What I like about `is` as a term and for this use case is I take the definition and modifiers of the element out of `class`...that may seem silly, but I really hate writing:

```html
// Class attribute as element declaration and aesthetic property junk drawer
<button class="my-button--link purple bordered"></button>

// Compared to the desired
<button is="my-button" class="link purple bordered"></button>

// And I can't write this because of the understandable one id per page constraint
<button id="my-button" class="link purple bordered"></button>

// And this is just painful and inaccurate semantically
<button data-is="my-button" class="link purple bordered"></button>
```

Further, `is` solves the problem without complicating the API of an HTML element itself (lots of additional global properties added to the spec), which could happen if we don't establish a way of determining when something outgrows where it can currently live (`class` or `data-*`). (Trying to get HTML to be fully OO in a way with interfaces, inheritance, and traits...might be cool, but might be one of those instances of just because we can). 

For things like `implements` or `has`, I'm thinking `data-*` might be more appropriate?

Why `is` is different for me and I prefer it over doing something like `data-is="my-button"`...`is` does not describe a property or properties the component *has*, it is making a declaration of what the component *is*. That's why, without much emphasis on or consideration for the JS side of this (much love and respect though), what we're trying to do feels less like object inheritance from OO and more like dependency injection...in either direction.

Even if nothing else comes of web components as it relates to custom elements, importable html + JS + CSS, inheritable elements...the concept of an `is` attribute is still viable with today's web technology (I think) and performs well semantically (though, I'd probably frown on "multiple inheritance" being able to add multiple values to `is`, because we already have and use `class` for that and I don't see a gain at least from a primarily HTML + CSS perspective).

- From a purely HTML perspective, I'm finding this to be a very effective way to communicate what's going on in the markup to other developers. (Don't need to know what's happening in CSS or JS. Again, HTML is the heavy in the room.)
- From a CSS/Sass perspective, I'm finding this to be a good way to reduce how much CSS is needed in general. `button` becomes a very generic definition. `my-button` is painless to select using the attribute selector. And class is cleaned out of everything except modifier utility things. It can become more modular like, where there are fewer declarations with multiple defined styles, and more defined styles with multiples declarations if that makes sense.
- From a JS perspective (maybe not virtual DOM), I can instantiate all sorts of variations quickly and then let them die just as quickly (taking a more functional approach). Constant event observation, but not constant in-memory DOM existence. (Might be heresy to say that, unless you're still rocking old-school progressive enhancement.)

Just throwing copper. Thanks.

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