WICG / webcomponents

Web Components specifications
Other
4.36k stars 370 forks source link

Reference Target, level 2 #1068

Open Westbrook opened 1 month ago

Westbrook commented 1 month ago

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 https://github.com/w3c/aria/issues/2303 for use cases.

In that way, we won't see authors asking the question of why this:

<label for="x-checkbox">I'm a checkbox</label>
<x-checkbox id="x-checkbox">
  <template
    shadowrootmode="open"
    shadowrootreferencetarget="real-input"
  >
    <input type="checkbox" id="real-input">
  </template>
</x-checkbox>

Would work differently than this:

<x-checkbox aria-label="I'm a checkbox">
  <template
    shadowrootmode="open"
    shadowrootreferencetarget="real-input"
  >
    <input type="checkbox" id="real-input">
  </template>
</x-checkbox>

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:

<x-meter id="fuel" min="0" max="100" low="33" high="66" optimum="80" value="50">
    at 50/100
    <template
      shadowrootmode="open"
      shadowrootreferencetarget="meter"
    >
      <styles>/* ... */</styles>
      <custom-stuff></custom-stuff>
      <meter" id="meter"><meter>
    </template>
</x-meter>
behowell commented 1 month ago

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.