LGTM1 Please make sure the PRs land. (and delay shipping if the final round ends up changing the API shape)
On Friday, June 26, 2026 at 1:31:35 AM UTC+2 [email protected] wrote: > I’ve resolved all spec issues raised in prior rounds of review. The PRs > received no more feedback for a couple weeks after the last review round, > so I raised a request in the WHATNOT call today asking for any final > feedback. Anne said he’d take another look so just waiting on that. > > > > In that discussion Olli from Mozilla asked I make sure the test coverage > was complete. I think the existing test coverage is solid but am working on > adding one specific case he asked for in > https://chromium-review.googlesource.com/c/chromium/src/+/8007785. > > > > No other blockers that I know of except what a final review pass might > turn up. > > > > *From:* Chris Harrelson <[email protected]> > *Sent:* Thursday, June 25, 2026 1:16 PM > *To:* Daniel Clark <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [blink-dev] Intent to Ship: Reference Target > > > > Thanks for working on this API, it solves an important a11y and functional > need. > > > > Given Mozilla is positive on this API, is there anything blocking landing > the spec PRs? > > > > On Tue, Jun 23, 2026 at 4:22 PM 'Daniel Clark' via blink-dev < > [email protected]> wrote: > > *Contact emails* > > [email protected], [email protected] > > *Explainer* > > > https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md > > > > *Specification* > > https://github.com/whatwg/html/pull/10995, > https://github.com/whatwg/dom/pull/1353 > > *Summary* > > Reference Target enables ID attributes like <label for>, > 'aria-labelledby', 'popovertarget', and 'commandfor' to be forwarded to > elements inside a component's shadow DOM, while maintaining the shadow's > encapsulation of its internal state. When a shadow host specifies an > element in its shadow tree to act as its reference target, all ID > references pointing to the shadow host are forwarded to the reference > target element instead. > > > > For example, here the <label>’s “my-checkbox” ID reference is forwarded to > the element in the shadow with the ID “real-checkbox": > > > > <label for="my-checkbox">Click me to toggle checkbox</label> > > <custom-checkbox id="my-checkbox"> > > <template shadowrootmode="open" shadowrootreferencetarget="real-checkbox"> > > <input id="real-checkbox" type="checkbox"> > > </template> > > </custom-checkbox> > > > > Reference target can be set declaratively like in the above example, or in > JavaScript with ShadowRoot's 'referenceTarget' property. > > *Blink component* > > Blink>DOM>ShadowDOM > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EDOM%3EShadowDOM%22> > > *Web Feature ID* > > referencetarget <https://webstatus.dev/features/referencetarget> > > *Motivation* > > Shadow DOM presents a problem for accessibility: there is not a way to > establish semantic relationships between elements in different shadow trees > (such as via 'aria-labelledby'). This limits the ability to design web > components in a way that works with accessibility tools such as screen > readers. The ARIAMixin IDL attributes ( > https://w3c.github.io/aria/#ARIAMixin) are a partial solution to the > problem; however, they lack the ability to create a reference "into" a > shadow tree from the outside. Reference Target is a solution to that > missing piece of the problem. > > > > In addition to the issues with accessibility, ID attributes like > 'popovertarget' and 'commandfor' can’t be used to refer to elements inside > a shadow root without reference target. > > *Initial public proposal* > > https://github.com/WICG/aom/pull/207 > > *TAG review* > > https://github.com/w3ctag/design-reviews/issues/961 > > *TAG review status* > > Issues addressed > > *Origin Trial Name* > > Reference Target for Cross-Root ARIA > > *Chromium Trial Name* > > ShadowRootReferenceTarget > > *WebFeature UseCounter name* > > WebDXFeature::kDRAFT_ReferenceTarget > > *Risks* > > > > *Interoperability and Compatibility* > > The interoperability risk is low since engineers from the other browser > engines have been active in spec discussions about the feature. > > > > This feature makes a change to the Toggle, Command, Interest, and Submit > events that presents a small compatibility risk. These events each have a > 'source'/'submitter' property that's set to the element triggering the > event, e.g. the button element clicked to open a popup. With reference > target this element can now be in a parent shadow tree relative to the > event is fired. Per discussion in > https://github.com/WICG/webcomponents/issues/1098 there was a desire to > have the event's dispatch path include the source/submitter's tree. This is > done by setting these events' internal relatedTarget ( > https://dom.spec.whatwg.org/#event-relatedtarget) to > their 'source'/'submitter' > > and making the event composed when that relatedTarget is non-null. When > used with reference target this causes the event path to include a > 'source'/'submitter' in a parent shadow. > > > > When used without reference target, there is no change to these events' > event paths (since the source/submitter can never be in a parent shadow, > therefore the relatedTarget will be in the same tree as the target, > therefore the event won’t dispatch in the parent shadow per the current > event dispatch algorithm). But, the 'composed' property on the event will > be set to true. This has already been changed in the past for Command and > Interest events ( > https://chromium-review.googlesource.com/c/chromium/src/+/6505682, > https://chromium-review.googlesource.com/c/chromium/src/+/7797864), and > there's also history of changing these for Mouse events ( > https://chromium-review.googlesource.com/c/chromium/src/+/4563502), so > I'm optimistic that this won't cause breakage. Most usage on Github ( > https://github.com/search?q=%2Fevent%5C.composed%5B%5EP%5D%2F&type=code) > is either conditional on 'bubbles' also being true, which is false for the > events in question, or is or is specific to mouse events which aren't > affected here. > > *Gecko*: Positive ( > https://github.com/mozilla/standards-positions/issues/1035) > > *WebKit*: No signal ( > https://github.com/WebKit/standards-positions/issues/356) > > *Web developers*: Positive > > - Why we still need reference target > <https://gist.github.com/davatron5000/b6a62cb782f01c69e818cd4585391138> > - > https://github.com/WICG/webcomponents/issues/1120#issuecomment-4156132737 > - Lots of positive reactions on last year's Interop Project proposal > for Reference Target, despite the feature not yet being eligible for the > Interop Project at that time: > https://github.com/web-platform-tests/interop/issues/1011 > > > > We ran an Origin Trial for the feature back in 133-135 but didn’t get much > developer uptake at the time. I attribute this to the difficulty of > poylfilling — see Activation section. We’ve since worked closely with > developers to ensure that the API meets their needs and they’ll be able to > adopt it. > > > > > > *Activation* > > This is a difficult feature to polyfill since ID reference attributes > cannot pierce into shadow roots without it. So there's no way for a > polyfill to enable the capability that reference target enables. My hope is > that this will be mitigated by other browsers shipping the feature. Gecko > is positive, I've been discussing the spec changes with engineers from both > Gecko and WebKit, and Gecko and WebKit both have prototype implementations. > > > > There is already brief MDN documentation: > > > https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/template#shadowrootreferencetarget > > > https://developer.mozilla.org/en-US/docs/Web/API/ShadowRoot#shadowroot.referencetarget > > > > There has sometimes been confusion about what scenarios the feature > unlocks, e.g. some developers assumed it directed ID references *out* of a > shadow root rather than *into* a shadow root. I'll ensure that we have good > documentation available including examples like those in > https://microsoftedge.github.io/Demos/reference-target/. The MDN docs > issue for the feature is still open at > https://github.com/mdn/content/issues/43453. > > *WebView application risks* > > None > > > > *Debuggability* > > No specific DevTools support is expected to be necessary. Existing > DevTools support for features used with reference target will continue to > work. For example, the accessibility tree viewer can be used to check that > an 'aria-labelledby' attribute is applied correctly even when it's used > cross-shadow-DOM with reference target. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > > Yes > > *Is this feature fully tested by **web-platform-tests* > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > *?* > > Yes: https://wpt.fyi/results/shadow-dom/reference-target > > *Flag name on about://flags* > > *No information provided* > > *Finch feature name* > > ShadowRootReferenceTarget > > *Rollout plan* > > Will ship enabled for all users > > *Requires code in //chrome?* > > False > > *Tracking bug* > > https://issues.chromium.org/issues/346835896 > > *Availability expectation* > > I've received positive engagement on the spec PR from WebKit and Gecko > engineers, and the feature is prototyped in both of those engines. So I'm > optimistic that they will follow in supporting this feature, though there > is no official commitment of support. > > *Adoption expectation* > > We are working with a developer partner who plans to adopt the feature > once it's shipped. > > *Non-OSS dependencies* > > None > > *Estimated milestones* > > Shipping on desktop > > 151 > > Origin trial desktop first > > 133 > > Origin trial desktop last > > 135 > > Shipping on Android > > 151 > > Shipping on WebView > > 151 > > > > *Anticipated spec changes* > > No breaking changes are expected. > > *Link to entry on the Chrome Platform Status* > > https://chromestatus.com/feature/5188237101891584?gate=5152828586196992 > > *Links to previous Intent discussions* > > Intent to Prototype: > https://groups.google.com/a/chromium.org/g/blink-dev/c/CEdbbQXPIRk/m/U43spqbKAgAJ > Intent to Experiment: > https://groups.google.com/a/chromium.org/g/blink-dev/c/C3pELgMqzCY/m/Lpb6DkueAQAJ > > > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DS0PR00MB2527DA9DA93A1972F5594156C5EE2%40DS0PR00MB2527.namprd00.prod.outlook.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DS0PR00MB2527DA9DA93A1972F5594156C5EE2%40DS0PR00MB2527.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4083781f-5237-46a3-993e-349ab4071a55n%40chromium.org.
