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

Everyone, I realized why people want is="" and it is due to very valid reasons.

However, the current is="" attribute had some big flaws that I think can be solved with what I just incisiones here: https://github.com/w3c/webcomponents/issues/658#issuecomment-325592918

What if we repurpose the is="" attribute (or make a new one so people don't confuse it with the current one) where in that attribute we can pass names of defined components?

There's two key differences between the current is="" attribute and the new idea I linked:

1. The attribute is not associated with extension. A defined component can not extend from Node, it must be standalone, and received the element via constructor arg. This eliminates any possible confusion over extension, and we simply augment existing elements with components.
1. Multiple names can be passed into this attribute, so multiple components can be instantiated for a given element.

This would be much more flexible than the current is="" attribute, and far less confusing, and helps to solve problems of associating behaviors with table or input elements and not changing the tagNames which breaks stuff.

It seems like a much better idea.

> An example over every other, is the bloody tr that cannot be wrapped around a custom-tr element because it will break and table are still the best, semantic, accessible way to display tabular data.

```js
components.define('foo', class {
  constructor(el) {
    // do something with el
  }
  disconnectedCallback() {}
  // Or similar life cycle methods
})
```
```html
<table><tr is="foo lorem">...</tr></table>
```

where `lorem` is defined somewhere else. Two components are instantiated with the `tr` element being passed into the constructor.

I hope this may lead to more ideas.

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