Re: [WICG/webcomponents] Proposal: Custom attributes for all elements, enhancements for more complex use cases (Issue #1029)

@EisenbergEffect 
> need to think more about registration. That's the biggest open question for me. I think having registries on the individual types is interesting. I hadn't thought about doing it that way. I wonder how that will work with custom element registries, particularly WRT scoped registries. So, I wonder whether attribute registration should just be another API on the existing custom elements registry, so we can inherit all the work on scoping for attributes as well.

@sorvell 
> Experience with customElements and the scoped registries proposal suggests that scoping is a must and to avoid the pain custom elements has gone through, this feature shouldn't ship without it.

Hm. I need to understand the use cases more where scoping comes into play with attributes.

Attribute registries are scoped to element classes already. Is the use case having different attributes for the same element class if registered differently, in different registries? Is the use case adding an attribute to a built-in only when used within a WC's Shadow DOM, without affecting the built-in outside that?

FWIW making scoping part of the custom elements registry is also problematic: First because registration is often decoupled from the custom element definition, so that consumers can do the registration. If now consumers *also* have to register all the element's attributes, that is too much work on the consumer side, for little benefit, plus it would break DOM methods to read/write attributes.
Second, because one of the primary driving use cases is adding custom attributes to built-ins, which are not registered on any `CustomElementRegistry`. 

------

@sorvell 
> Custom Element attribute reflection is indeed annoying, but it's not clear if this feature would be directly applicable.

How so? It's *designed* with that as a primary use case.

> Perhaps instead, there's a lower level seralization/deserialization primitive that could be used here and also with `observedAttributes`.

If there is, even better! Though I suspect use cases for `observedAttributes` would drop very significantly once this is available.

> This suggests that basic version should support property setting.

It …already does? In fact, it entirely automates it 🙂
Perhaps you mean properties that *don't* correspond to attributes (akin to LitElement's `attribute: false`)? I can definitely see use cases for that, the reason that wasn't included was that this is not that difficult already.

------

@bahrus 

> One concern:
> 
> ```
> // This also works:
> MyInput.attributeRegistry.define("ac-list", ListAttribute, {
>  propertyName: "autocompleteList" // if we want to override the default acList
> });
> ```
> 
> This means that in order to register the attribute, then we need to wait for the MyInput class to be downloaded. But if we use whatever we call this thing-of-a-jiggy for doing cross cutting things (like binding during template instantiation, for example), I think that could be an issue.

Not necessarily, that's what `customElements.whenDefined()` is for.
Also, I think adding custom attributes to *other* custom elements, while important, is probably one of the least prominent use cases (compared to adding them to built-ins, and adding them to your own components). 

> I'm curious if you could provide insights on this question: When I look at this [documentation](https://mavo.io/docs/plugins), it seems that by default the "hooks" can apply to all elements by default. Likewise when I look at [Vue](https://vuejs.org/guide/reusability/custom-directives.html#directive-hooks) and others (knockout.js) etc. My proposal was heavily influenced by what I see in industry (as that seems like a proven model?)
> 
> It seems that by default your proposal is deeply curtailing the developer's "reach" and I'm puzzled as to why? Is it parsing constraints?
> 
> I agree we want the developer to be able to curtail their own reach, but I'm a bit surprised that that is the direction this is taking?


I …don't understand what you're asking here _at all_.  🤷🏽‍♀️ What's the relevance of Mavo hooks and Vue plugins? What is curtailing what developer reach? 🤔 



-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1029#issuecomment-1719530126
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1029/1719530126@github.com>