Re: [w3c/webcomponents] Element Behaviors, and the has="" attribute. A useful alternative to Custom Elements in many cases! (#727)

@trusktr: Thanks for the invite! This is interesting.

I think it's really starting to try and move us to looking at individual HTML elements as actual class definitions from the OOP world. As such, this response might turn into something a bit longer than expected or requested. :)

> @joshbruce Seems like you like is="" more than has="". I'm curious to know more on that. Mind commenting on that over at #727, where I've published an implementation of element-behaviors and has=""?

For me it's not a question of "more than" - it's a question of language and intent.

`is` in my mind is analogous to object inheritance from class-based language like PHP, Swift, and so on; therefore, the following would be equivalent representations of the same concept (please forget JS for the purposes of this reply):

```
<div is="my-custom-block-element"></div>

class Div {
  // block element definitions and properties
}

class MyCustomBlockElement extends Div {
  // my overrides and extensions
}
```

The `has` proposal seems more like traits (from PHP) or multiple inheritance, which has it's own issues and has been, and I believe continues to be, debated. There's a difference a between something *being* an extension of something else and something *having* the qualities defined somewhere else. (@colinalford - might find this interesting.)

So, the following would also be analogous - using PHP traits - not JS.

```
<div has="bar baz"></div>

trait Bar {}

trait Baz {}

class Div {
  has Bar, Baz;
}
```

I like to write code with that is explicit in its intent; I can figure out what's going one by reading it.

It seems like we are trying to do for `script` what `class` did for `style`. However, CSS doesn't have the crazy inheritance that JS can provide.

So, why not both?

```html
<div is="my-cool-contact-card" has="customHover customClick" class="rounded blue"></div>
```

This is much easier to read and doesn't assume the existence of custom elements support on the client.

```html
<my-cool-content-card has="customHover customClick" class="rounded blue"></div>
```

And, it removes the clutter of literal JS and CSS in the element.

In all honesty, I like `is` from the perspective that it's a valid selector and allows me to have custom named HTML elements today - while the debate and conversation of *how* that looks continues on. Therefore, I can style and make my intent explicit without using `class` as a junk-drawer for selection...since we don't seem to like taking advantage of the `data-*` thing.

I like `has` from the perspective that it could, in JS, grab the prototypes and implements without having to run the selectors and finds...if I'm understanding correctly.

Let's pretend `id`, `class`, and `style` only serve to inform the browser of our aesthetic intent - `id` there is only one in this document, `class` it has *n* number of stylistic traits, and `style` this one specifically has these styles as well (most likely generated using a template engine or JS). 

It's possible that `is`, `has`, and `script` could do the same thing for interactivity (behavior) - `is` I have all the layout characteristics of this other thing, `has` I have these interactive characteristics, and `script` this instance in particular also does these things.

Could be crazy, but that's how my mind is mapping these things - taking on the voice of the element itself for a second:

1. Structure and layout: Am I block or inline?
2. Style and aesthetics: What do you I look like??
3. Interactivity and behavior: How can people play with me??

I've been toying with the notion of HTML as a language being less about the web and more about giving authors the ability to describe their intent - otherwise, we would only need `div` and `span`, because everything else could be accomplished in CSS + JS (or other scripting languages)...`p` is just a `div` with expressed intent kinda thing.

-- 
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/727#issuecomment-364758697

Received on Sunday, 11 February 2018 15:14:13 UTC