Generic proposal (Potentially expand beyond aria?)

[Garbee]

There are more things than just aria attributes that could benefit from delegation. While it is the most important matter to get working, the same method could be used to help with other situations where references need to be given between shadow boundaries.

One use-case in mind is, datalist for an input. If a developer wants to build an input component that is encapsulated but still allow a list of options to pick from, the datalist if provided in a slot needs to be cloned into the shadow boundary to get referenced. Duplicating the list in memory and just being complex since it'll need to also get watched for changes. With delegation support the list can exist external to the shadow boundary (or just as a child of the component) and the ID reference could work as normal.

Example structure:

    this.attachShadow({ mode: "open", delegatesList: true, });

<x-input list="ice-cream-flavors">
  <!-- Shadow Root -->
  <label for="ice-cream-choice">Choose a flavor:</label>
  <input autolist id="ice-cream-choice" name="ice-cream-choice" />
</x-input>

<datalist id="ice-cream-flavors">
    <option value="Chocolate">
    <option value="Coconut">
    <option value="Mint">
    <option value="Strawberry">
    <option value="Vanilla">
</datalist>

[Westbrook]

Agree on this one! I think there's actually a good number of aria-centric concepts that are not on the AriaMixin particularly in that no ID referenced content is included in that mixin. @leobalter is the use of the AriaMixin as the basis for this version of the spec something that came from browser implementors or something that we could have some flexibility with if addressed early?

A quickly devised list might wonder by aria-labelledby, aria-controls, aria-activedecendent, possibly even role in some cases, amongst others wouldn't be included. Don't mind how those attributes start to constructs a Combobox...nothing to see here 😉

[nolanlawson]

A really interesting case was brought up recently about elementtiming. It seems like cross-root ARIA delegation could potentially solve this problem as well: w3c/element-timing#3

[mrego]

More examples about this are included in the new explainer.

[nolanlawson]

Looking through the list in the explainer, it seems pretty straightforward to expand to include IDref attributes like for, list, and popovertoggletarget (né popuptoggletarget).

SVG <use> seems a bit trickier since it's technically not an IDref attribute: <use href='#foo'>.

As for @font-face, this looks like a straight-up browser bug, at least for referencing within the same shadow tree. It works in WebKit, but not in Chromium or in Firefox. That said, even if those bugs were fixed, maybe there is a use case for this? But like SVG <use>, it's not an IDref, so it may need a different API shape.

[nolanlawson]

Conclusion from today's cross-root ARIA F2F: we may be interested in this long-term, but we don't want to over-extend ourselves such that the spec grows too broadly in scope.

Something like for may be the most promising in the medium term, but shouldn't be considered a blocker for this spec.

We could also consider how FACE could interact with this.