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

Just to clarify that the only person who would write the potentially verbose and error prone code in question was you, the "polyfill" author, and everybody else could then write the JS and HTML exactly like you suggest. Before you release the library, you would of course move the part of the code into the module `myproposal.js`, so nobody has to see this code. Now we are ready to determine if the suggested syntax:

```html
<table is="datagrid has="sortable clickable editable searchable filterable configurable"/>
```

– is preferable to what the current spec has to offer:

```html
<table is="datagrid" sortable clickable editable searchable filterable configurable/>
```

– or some combination of the two:

```html
<table is="datagrid searchable filterable configurable" has="sortable clickable editable"/>
```

We are also free to explore the concept of shared state and define recovery guidelines for separate entities to act on the same DOM. We can determine the best APIs for behaviors to communicate and assert each others existence. Perhaps some component authors in the end decide that a mixin strategy in pure JS is preferred, because it is easier to release an NPM module than it is to edit one hundred HTML files in one thousand website whenever they need a new behavior "screenreadable", or perhaps a majority of components will simply not use mixins at all.

```html
<table is="datagrid">
```

I can even imagine a movement against a "general mechanism for hooking into the lifecycle of custom elements" except for what the element decides to expose, because it violates some design pattern or justified concern. Or perhaps some other reimplementation of Custom Elements and/or Angular directives catches on, there seems to be no shortage of ideas. I think that however the specification is not the best place to sell an unopened can of worms, because people will be tempted to buy it just for that fact. A low level mechanism would allow them to try before you buy, and the example API I have suggested could by itself be used to extend the behavior of components even without adding new attributes. Perhaps in the end that turns out to be easier to maintain.

```html
<table is="datagrid">
```


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