Let’s defer scoped custom attributes for later.
source
The customElementRegistry property is a newly available on Document|ShadowRoot|Element and allows authors to scope elements to a given custom element registry (which can also be null). This seems likely to land in all browsers well before custom attributes, so leveraging it here is a potentially pragmatic option.
It makes sense to be careful about coupling custom attributes with custom elements since independent use cases almost certainly exist. However, it might be reasonable to consider scoping custom attributes optionally via a custom element registry. It is natural for a custom element to be interested in encapsulation (e.g. it can choose to use Shadow DOM to isolate its elements). Further authors not interested in custom elements could (harmlessly?) just use a registry to scope attributes, if desired.
This would allow, for example, frameworkA and frameworkB both to have simpler attribute names like bind, and importantly it would prevent intra-framework version issues, e.g. frameworkA 1.0.5's and frameworkA 2.7.8's a-bind attribute.
Here's a sketch of how this might work:
<div id="aRoot" customElementRegistry>
<input bind="foo.bar.baz">
</div>
<div id="bRoot" customElementRegistry>
<input bind="a:b:c">
</div>
<script>
// framework A code...
const aRegistry = new CustomElementRegistry();
HTMLInputElement.customAttributes.define('bind', aBind, aRegistry);
// ...as part of framework rendering...
aRegistry.initialize(aRoot);
// framework B code...
const bRegistry = new CustomElementRegistry();
HTMLInputElement.customAttributes.define('bind', bBind, bRegistry);
// ...as part of framework rendering...
bRegistry.initialize(bRoot);
</script>
source
The
customElementRegistryproperty is a newly available on Document|ShadowRoot|Element and allows authors to scope elements to a given custom element registry (which can also be null). This seems likely to land in all browsers well before custom attributes, so leveraging it here is a potentially pragmatic option.It makes sense to be careful about coupling custom attributes with custom elements since independent use cases almost certainly exist. However, it might be reasonable to consider scoping custom attributes optionally via a custom element registry. It is natural for a custom element to be interested in encapsulation (e.g. it can choose to use Shadow DOM to isolate its elements). Further authors not interested in custom elements could (harmlessly?) just use a registry to scope attributes, if desired.
This would allow, for example, frameworkA and frameworkB both to have simpler attribute names like
bind, and importantly it would prevent intra-framework version issues, e.g. frameworkA 1.0.5's and frameworkA 2.7.8'sa-bindattribute.Here's a sketch of how this might work: