-
Notifications
You must be signed in to change notification settings - Fork 8
2025 Cross‐shadow root references (referenceTarget)
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/54
- URL: https://meet.jit.si/WEH2025-ARIA
- Slides: https://alice.pages.igalia.com/2025-hackfest-reference-target/
Let's go through the open issues from https://github.com/WICG/webcomponents/issues/1086:
Blocking Phase 1:
- Reference Target: what type should the
referenceTarget
attribute be? #1093 - Reference Target: How should we treat invalid reference targets for relations set via Element IDL attributes? #1089
- Reference Target: Which attributes are in scope? #1091
- Reference Target: How to handle events fired on the reference target by related elements? #1098
- Reference Target naming #1087
If we get time, we can also discuss whether we might want to explore related topics.
Minutes:
-
Alice: implemented in chrome in an origin trail, basics complete in webkit. Started to look at implementation in firefox. Lots of great WPT tests..... (this is all in the slides)
-
Anne: There should be an example in the html spec with a recusrive example -- a nested shadow DOM
-
Alice: So lets go through all the issues then discuss the ones people want to discuss.
-
Mike: The other compelling reason is that the setting allows..... (missed this)
-
Alice: right. would be weird to be inconsitent with the way the IDL attribute settings. My preference is nullable doms string. It is not like an "ID", its like an element attribute, like HTML for, aria-activedescendent, etc. HTML for has a difference between not set, set and an empty string. (this is also in the slides)
-
Luke: Whats the benefit of setting an empty value rather than remove it.
-
Alice: if it was empty, it would be broken, it would refer to nothing, like
for=""
. My intuition is that if I set referencetarget="", that is a broken reference, it refers to nothing. That is how label works. -
Alice: how should unsetting work? either set something to "null" or set something to empty string. Dan agrees with me now.
-
Alice explains the other issues
-
Alice explains the future/reference 2.0. Also explains the problem with aria-describedby has a list of 2 ID, both IDs might be in the same shadow root.
-
Sarah: I have a better explain, a card component where the shadow root is a layout component with a file icon filed by primary text followed by descriptive test. Wrap that in a button. Aria-labelledby is the file, aria-describedby to two seperarate parts "word doc updated yesterday."
-
Keith: A lot of examples come down to how you compose the shadow roots. Can you compose the shadow root in a way to avoid the requirement?
-
Sarah: if this weren't supported, we would find some way to make work.
-
Luke: The listbox example, what I don't quite understand -- aria-activedescendant -- don't you need ot know what is happening in the shadowroot.
-
Keith: these are contrived to demonstrate.. but wouldn't you have opts as slots?
-
Alice: maybe its a recycle view, there might be a reason.
-
?? someone online: we can move things up and down all they want, we can do things because the platform makes us, but our customers should be able to use widgets (??). Seems like we should be able to do this.
-
Keith: One could argue, forgetting the primative, we need to implement a listbox, because you don't have customizable select.
-
Anna: describedby with multiple values, the whole reference target needs to be redesigned. We
-
Sarah: projects an image.
-
Luke: The outer element doesn't need to know that it needs to be described by....... I'm not quite catching this
-
Keith: if aria-describedby, can you point to an element within that is aria-describedby by 2 things
-
Alice: my proposal is not to consider the next steps, lets just resolve the remaining issues for reference target, which solves a specific small thing.
-
Anne: I want to know what v2 looks like first
-
Westbrook: Lack of v1, we don't know what people want. We need v1 to inform v2. With v1 we will be able to already do so much more.
-
Dan: the alternative ideas, none of them are very constrained by reference-target
-
Anne: Olli wants one attribute to solve v1 and v2.
-
Luke: V1 doesn't preclude V2.
-
Luke: I don't think the micro syntax is a great idea, I don't think it should be in only one attribute. We could have a new attribute for each attribute we want to delegate... to big probably.
-
Alice: maybe there is a fear of missing out on the possiblity of an elegant API that solves all problem, but it's very hard ot get consensus, so I want to implement something we can agree on and really learn from the use of.
-
Keith: The attributes with a list of elements are a few aria attributes.. then table headers. (scribe missed something)
-
Anne: can't you enforce being in the same table.
-
Luke: if you have invalid html that is a reasonable situation. if you need to insert somethings
-
Keith: overarching point, we have compelling attributes for aria attributes, I don't think we need all of this stuff with headers, maybe for the v2 issue, it is scoped to ARIA. aria mixin to shadowroot seems like a tenable solution to the v2 problem, suddenly you can't resovle a reference target with headers but does anyone need htat?
-
Alice: what time should the referenceTarget be?
-
Eri: it is an argument with going with V1 rather than v2, how do you null things in microsyntax. But that would be like deleting it, or nulling it.
-
Keith: because in the micro syntax, what is a diffence between empty string and empty attribute.
-
Brian: do you think micro syntax is a good idea?
-
Anne: We actually use this syntax already, it's in the browser/parser, in parts.
-
Alice: I don't want to make decisions about referencetarget based on the possibility of referencetargetmap. It's very difficult to meet and move things forward.
-
Anne: I think there are other ways to meet than here and TPAC.
-
Alice: Can we just focus on these issues as if we aren't going to do referencetargetmap.
-
Anne: In that case I don't want to particpate in the discussion.
-
Luke: There are things we can discuss regardless. Attributes in scope, this is something we can discuss. I think your suggestion is correct. I can't think of a reason why we wouldn't want an attribute to go through this. The shadowroot author can decide whether to forward the attribute.
-
Alice: in the spec, we have to go attribute by attribute. The existing language is the element that matches the ID.
-
Anne: I'm thinking of SVG
-
Alice: SVG doesn't use ID, it uses fragment.
-
Anne: I did go through the entire html spec.
-
Alice: what about events?
-
Keith is jake ok with it?
-
Alice: yes
-
Anne: olli has to look at this. Is this similar to anything that we have today?
-
Keith: effect toggle event?
-
Alice: will effect that, also submit event.
-
Luke: I think it will fix toggle event.
-
Keith: (tries to explain a scenario I didn't catch) popover in a popover in two different nested shadowroots.
-
Luke and Alice say that won't happen....?
-
Luke: command events never escape or escape in this way, if it applies to any it applies to all. Command event should just never escape?
-
Keith: I'll write this up in the issue
-
Luke: if it makes sense for one event it makes sense for all events.
-
Keith: What are the motivating use-cases for firing the event inside of the DOM that is the shadow root of the source?
-
Alice: so you can listen on middle component, if you file the command you should be able to isten to the middle component (in the example on the screen)
-
Keith: So wat is the use-case for hte command because you could listen for the event click, instead?
-
Alice: well then why does comman event exist?
-
Keith: Command exists for two reaons: you're pushing an event to one element and you want to react to the event on that other element. There are other events thattrigger in response to that. Currently, the toggle event is dispatched for anything that has a valid built-in command. And then for custom commands, whoever is developing the custom command will do their own thing. I don't necessarily see what you would do to respond to a command being fired in the same tree that the button is--because I can undersand responding to the same thing that the receiving tree is in. The non-composed, non-composite case. The "click" event still esists on button and all the other events still exist on the other element, so the "command" event is just a way to prevent deault for something that is about to happen that happened in a different tree from the bustton. So I dont know whKeithey you would want the "command" event to be dispatched in the same tree as the button
-
Luke: Maybe we can make it so it's non-composed
-
Keith: re-targeting means that youdon't have access to the original element
-
Brian: We have 4 minutes surely we can pick a name?
-
Dan: Where should we consider the referenceTarget decisions after this? I would certainly not want to wait for TPAC. One-off meetings?
-
Anne: That could work.
-
Dan: even with the current proposal, there are things that we want to solve that might not involve ID.
-
Alice: Reftarget? Reference target?
-
Dan: One of those two remains my favorite
-
Brian: Why do you need to spell out reference.
-
Luke: What's wrong with "referenceTarget"
-
Alice: It's pretty long
-
Luke: I don't think we use the term "ref" anywhere else in the platform
-
Brian: We use "idref"
-
Anne: I think that's from DTT. It's not actually on the platform
-
Keith: I don't like the length of referencetarget, but I don't like the abbreviation of reftarget. I would say "target" but...
-
Alice: Similar to my critique of "delegatesTo"--I would ask what target?
-
Keith: Other names are very ambigious, what is a part. What is a delegate.
-
Dan: None of these names are clarly better; the bikeshedding has not led us any closer to a clear alternative. I'm inclined to side with referenceTarget unless someone can offer a compelling alternative.
-
Luke: I'm thinking of "popovertarget"...
-
Anne: "refFor"
-
Alice: "for" makes no sense in this context
-
Keith: shadowrootreference?
-
Alice: "target" is important--it's telling you what it's doing
-
Anne: If you start with the value, then "this value is the reference for the shadowroot"
-
Alice: Except that's not an accurate statement. The value of the attribute is the target for the references
-
Keith: A thesaurus suggests "source"
-
Valerie: I am in favor of refernceTarget because I feel like it makes intuitive sense with very little explanation. Even "refTarget" because what else could "ref" possibly mean?
-
Keith: "referrer"
-
Anne: Nah, that's HTTP
-
Alice: Resolved!