Re: [w3c/webcomponents] A new attribute similar to is="", but would allow multiple behaviors to be attached to a given element. (#662)

> And here's what getting those components from an element and calling a method looks like:

The following feels very [🚂 🚋 🚋 🚋  wreck](http://wiki.c2.com/?TrainWreck) pattern IMHO.
```javascript
anyElement.behaviors.foo.someMethod()
```

```javascript
class Foo { ... }
elementBehaviors.define('foo', Foo, {limit: [HTMLMapElement, WebMap]})
```
This pattern feels very 🇨🇭 Army Knife™ to me. Usually API confusion leads to footguns. Best to keep `.define` semantics as ergonomically friendly as possible. If i'm not mistaken a _"small"_ change like this could increase the complexity of the upgrade routine. Not sure if the value is worth it IMHO.

> I think it'd be beneficial to have one simple clean new idea without mixing it with the confusing and limited existing functionality. @trusktr 

I concur 💯 however in the "simple and clean" category these examples leave much to be desired.

I do like the concept of "enhanced" elements re: @wiredearp 

```html
<table is=custom-element>
```

And the ability to not have to extend from HTMLElement is a nice thought as well. But certainly feel this can be implemented at the library level with ease.  Perhaps conventions for `:undefined` "enhanced" elements can be made around `is=`. For instance since there would be no need to `.define ()` an upgrade for the element. The lifecycle callbacks are trivial to `.call` as well. 

This even leaves room for `is=foo` but but this could be potential bike shedding.

Gut instinct says a couple of nice conventions could arise from this at the library level. However, we should be cautious of breaking [Ockham's Razor](https://simple.wikipedia.org/wiki/Occam%27s_razor) at the spec level.

My 2 Satoshi

P.S. @trusktr, skating since late 90's #rad :metal:


-- 
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/662#issuecomment-328293311