Reference Target naming

[alice]

There has been a reasonable amount of feedback that the name referenceTarget is difficult to understand.

I think it's a reasonable name (ID references to the host should instead go to the designated target), but it might be good to see if we can come up with some alternatives.

One thing we should keep in mind is that if we choose to use separate attributes for each attribute for Phase 2, it would be nice to have a noun which can be used in combination with existing attributes (e.g. "shadowrootariaactivedescendanttarget").

[alice]

One comparison that gets made a lot is between referenceTarget and delegatesFocus.

"Delegates" is a verb in delegatesFocus, and delegatesFocus is a boolean, so there's no close mapping possible, but we could potentially align with the related spec concept of of focus delegate with something like referenceDelegate.

In fact, that was the name originally proposed: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md#alternative-names-for-the-feature-reference-target

[rniwa]

hm... how about idForwarding or idTarget?

[Westbrook]

hm... how about idForwarding or idTarget?

Feels like anything specifically revolving around “id” flies in the face of W3C TAG wanting to find a path away from needing to rely on IDs to reference things across the DOM. 🤷🏼‍♂️

As a component author, I’ve no problems with referenceTarget, particularly in that I don’t need to read from it almost ever and expect to write to it only slightly more frequently. Naming only feels like it would be of issue here if (when?) the suggestion away from a micro DSL for maps in Level 2 is enforced.

Not to make a specific vote for it, but if a rename is required… in a world where commandFor is becoming a thing would expanding on “for” in some way be appropriate? e.g. delegatesFor or targetFor…

[alice]

To me commandFor is part of a sentence: "button foo is a[n open] commandFor popover bar" -> <button id="foo" commandfor="bar">. I can't quite see how to map that on to what referenceTarget is doing - what did you have in mind?

I agree that id seems like it might be a bit too specific in the event that we do develop another way to target elements for references. forwarding definitely does match my mental model of what the attribute is doing, though, although to me "forwarding" implies a boolean state, rather than a transitive verb ("forward to") or noun ("delegate").

One more pitch for delegate: there is a related problem which we deliberately (and correctly) scoped out here, but which we might want to revisit eventually, and that is that we might want to allow authors to "move" applicable attributes on the host, like role, to a designated element within the shadow root. If we did eventually investigate a parallel API for that capability, I think delegate would be a natural fit there.

I do agree that "delegate" does fail the "straightforward English" test, though. It's also easily confused with the verb "deleGATE".

[Westbrook]

In the case that we could "move" role (or similar) via a roleDelegate (or so), it does open the door for next level passing as I've discussed the desire for in #1068. It's almost like we would be drifting towards an attributeDelegate at some point. That's CLEARLY not what the API is at this time, however...

While, I was not quite sure how to turn commandFor into a usable property/attribute, I was noticing that we start with <label for="..."> references, a couple others, and now <button commandfor="..."> references, it seemed there might be something there. If we were "doing more 😞" then it might make sense to see a property/attribute like attributesfor. But, I realize that would likely derail much of the work we've done to date, which I am quite remiss to do.

I can definitely get behind a value like referenceDelegate! It's much like referenceTarget, which I'd be fine with, too, but seems like others might not be? However, language not withstanding, there would be so much gravity for the to become delegatesReference if only for the way it would rhyme with existing API.

[sorvell]

There has been a reasonable amount of w3ctag/design-reviews#961 that the name referenceTarget is difficult to understand.

I addition to being hard to understand, there has also been feedback that it's too long.

Suggestions

name	understandability	size
to	not confusable but similar to for need docs to understand	2
refsto	more explicit than to and the term ref is generally used	6
refdelegate	similar to referencedelegate	11
delegate	generic like to but longer	8
delegatesto	clear verb (similar to aria-flowto)	11

[alice]

I quite like ref or refs as a general direction.

I'll also note some potential prior art in Microsoft's Fluent UI system (React-based) which uses the term "primary slot" for the equivalent of the phase 1 API (plus the "Level 2" ideas Westbrook described): https://github.com/microsoft/fluentui/blob/511c32a4cd38fe82ade4677245b2424b323407fa/rfcs/convergence/native-element-props.md#introduce-the-concept-of-a-primary-slot