Re: [w3ctag/design-reviews] Reference Target (Issue #961)

When discussing this at length with the AOM Working Group, the WCCG, and implementors, a primary shortcoming for an attribute marker being applied to an element within the shadow DOM is that in order for the API to scale over time to support mapping more than one attribute to more than one element you needed to inform the shadow root that it would be delegating a value and to which element the value would be delegated. If the [delegation](https://github.com/leobalter/cross-root-aria-delegation/blob/main/explainer.md)/[reflection](https://github.com/Westbrook/cross-root-aria-reflection/blob/main/cross-root-aria-reflection.md) APIs were to stop at a one to one pass through, so no support for something like `referenceTargetMap`, which is a powerful part of this API (or the Level 2 of this API?), then it _might_ make sense to have such a marker hold all the values applied from outside of the shadow root. However, many implementors were dissatisfied with API that could not scale in some way to support more complex situations, in fact a number of seemingly promising proposals in this area have been overrule for lack of this ability. This become more and more apropos as `referenceTarget` has expanded to properly support non-aria attributes like the [Popover API](https://developer.mozilla.org/en-US/docs/Web/API/Popover_API), [Invoker Commands](https://open-ui.org/components/invokers.explainer/), and other more recent attribute bound interactions which are even less likely to receive a "batch" handoff of attribute values.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/961#issuecomment-2412651339
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/961/2412651339@github.com>