Associating any number of behaviors with any number of elements.

[trusktr]

This seems useful for certain things (@treshugart brought it up here).

It's a way to associate simple behaviors based on simple string values across any elements, as the attributes are global (I would also suggest that if you can provide a way to register custom attributes scoped only to a shadow root that would be extremely awesome).

Your idea is in a way similar to the idea in the issue I made where Tre brought it up, in that both ideas allow any number of "behaviors" (using the term loosely) to be applied to any number of elements without regard to what those elements are.

I think I can see great uses for your attribute. However one use case, for example solving the same problem that the not-as-much-liked is="" attribute solves which is that we currently can't replace things like

<table>
  <tr></tr>
</table>

with

<table>
  <my-tr></my-tr>
</table>

because it breaks.

The is="" attribute solves that, but the mechanics of how is="" is confusing and some people don't like it to the extent that Safari team decided not to implement it.

However, the same guy no the Safari team mentioned that the "behaviors" idea makes a lot more sense.

---

Well, anyway, this got me thinking: How do custom attributes play with Custom Element's attributeChangeCallback API?

What do you imagine? For example, if Custom Global Attributes were adopted, would attributeChangedCallback receive the instance of the custom attribute, not just string values? And perhaps logic in there can call APIs on the attribute instance?

---

I can imagine how style="" could be implemented using Custom Global Attributes. Things like that, that work on any element, make sense to implement with an API like this, so I think this does a good job of helping with the Extensible Web Manifesto.

---

The behaviors idea in WICG/webcomponents#662 doesn't help with the web manifesto, but it does add a new feature with a similar API to Custom Elements, but with benefits of for example being able to associate any number of behaviors with any elements, not just one behavior per element like current Custom Elements or is="".

[matthewp]

Hey, sorry I missed this one. I don't know how/if the attributeChangedCallback would change if something like this were standard. I think it would be weird if it did change at all.

I do kind of like those as="", components="", etc. ideas that some people have floated around. I guess the advantage to that approach is that you're creating a new standard attribute rather than letting everyone define their own (causing possible collisions), like this library does. I might explore that sort of idea in a future library.

Thanks for your interest in the project! Going to close as I don't think you're asking for anything to change. Happy to continue talking in the closed thread.

[bedeoverend]

I would also suggest that if you can provide a way to register custom attributes scoped only to a shadow root that would be extremely awesome

@trusktr worth noting this is already happening. Currently custom-attributes is per-document, rather than window, meaning that the attributes registered won't pierce through Shadow Roots, but you can add your own registries for any Shadow Root e.g.

import CustomAttributesRegistry from 'custom-attributes/registry';

const myShadow = document.body.attachShadow({ mode: 'open' });
const customRegistry = new CustomAttributesRegistry(myShadow);

// Scoped to document.body's Shadow DOM
customRegistry.define('my-attribute', ...);

See #3 for more info