You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't think it needs to block initial testing/implementation of Reference Target, by any means, but I would like to see a conversation around non-reference attributes and whether they can be passed via this pattern.
Starting specifically with accessibility attributes, it would seem that things like role, aria-label, and aria-description, et al deserve to be passed to the Reference Target the same way the ID reference based relations are passed. See w3c/aria#2303 for use cases.
In that way, we won't see authors asking the question of why this:
In both cases a label applied outside of the shadow root is pointed to an element with a Reference Target. Both types of labels should likely behave similarly.
This, of course, does beg the harrowing question of "when does it stop?". Many authors wonder how to mirror ALL attributes down into a child. In this way, an author could make a <x-input> and have all of the attributes be passed down to a <input> internal of the shadow root. Is there a way to know what attributes are unique to the target of a reference? aria- attributes seem like a no brainer due to the idea that you've established a Reference Target to begin with. However, could the delta of attributes on the Reference Target that are not on HTMLElement in some way to assumed or triggered to pass as well?
This would make things like <meter>, which has unique attribtues like min, max, low, high, optimum, and value, much easier to customize with a custom elements:
I agree this is definitely something that needs to be solved. But I think it should be its own thing and not tied into reference targets. IMO it's fundamentally different from what reference target is doing.
I wrote down the beginnings of an idea for how this could be done using an attribute binding syntax: https://github.com/behowell/aom/blob/attribute-binding/attribute-binding-explainer.md. It still needs a lot of work to figure out details, but the basic idea is to give a declarative way to make attributes on the host apply to something inside the shadow tree.
I don't think it needs to block initial testing/implementation of Reference Target, by any means, but I would like to see a conversation around non-reference attributes and whether they can be passed via this pattern.
Starting specifically with accessibility attributes, it would seem that things like
role
,aria-label
, andaria-description
, et al deserve to be passed to the Reference Target the same way the ID reference based relations are passed. See w3c/aria#2303 for use cases.In that way, we won't see authors asking the question of why this:
Would work differently than this:
In both cases a label applied outside of the shadow root is pointed to an element with a Reference Target. Both types of labels should likely behave similarly.
This, of course, does beg the harrowing question of "when does it stop?". Many authors wonder how to mirror ALL attributes down into a child. In this way, an author could make a
<x-input>
and have all of the attributes be passed down to a<input>
internal of the shadow root. Is there a way to know what attributes are unique to the target of a reference?aria-
attributes seem like a no brainer due to the idea that you've established a Reference Target to begin with. However, could the delta of attributes on the Reference Target that are not onHTMLElement
in some way to assumed or triggered to pass as well?This would make things like
<meter>
, which has unique attribtues likemin
,max
,low
,high
,optimum
, andvalue
, much easier to customize with a custom elements:The text was updated successfully, but these errors were encountered: