Update Reference Target Explainer to add support for nesting inside labels #210
Conversation
| @@ -262,24 +264,17 @@ There is no special support for an element nested inside a label. The label must | |||
| this.shadowRoot_ = this.attachShadow({ mode: "closed" }); | |||
| this.shadowRoot_.innerHTML = `<input id="real-input" />`; | |||
| this.shadowRoot_.referenceTarget = "real-input"; | |||
| // Alternatively, set the referenceTargetMap with the `for` attribute: | |||
There was a problem hiding this comment.
I'm not sure about this. Nested labelable elements don't use for, by definition:
If the for attribute is not specified, but the label element has a labelable element descendant, then the first such descendant in tree order is the label element's labeled control.
Yes, the vibe is very "the for is implicit", but there's no for actually involved - the relationship is purely based on the tree structure.
This is why I was hesitant about including implicit relationships in the scope - I completely agree that it would improve the developer ergonomics to have a way to make these implicit relationships work, but it seems a bit arbitrary to have this work based more or less on vibes, unless I've misunderstood something.
There was a problem hiding this comment.
Are there other based-on-tree-structure relationships that could be captured as part of this, maybe as a "level 2/3" of the spec?
Off the top of my head, I can think of listbox/option, although there isn't a related IDref for that.
There was a problem hiding this comment.
There are a handful of ARIA parent/child requirements that could certainly fit into this in that longer view. All similar to listbox/option; radio group/radio, group/checkbox, etc. Were that parent/child relationship be automatically point through to the Reference Target, that would be quite nice...
There was a problem hiding this comment.
Sorry for the late notice, and I wasn't really sure where to tell folks about this, but there's going to be a session at Web Engines Hackfest where we can discuss this:
Also, if you can make it, any suggestions for further topics to discuss would be welcome on that issue!
There was a problem hiding this comment.
How was the session last week @alice?
There was a problem hiding this comment.
Really productive! You can read through the notes here: https://github.com/Igalia/webengineshackfest/wiki/2024-Reference-Targets-for-Cross-Shadow-Root-IDREF-associations
I think for me the most exciting parts were:
- @lukewarlow noting that we could "explain" this type of relationship as a kind of "missing value default"
- and also, that maybe we need more explicit attributes to be added for things like listbox/option, so that you have the option to specify those relationships either explicitly or implicitly, and we can use the explicit attributes to explain the implicit relationships
- general agreement that having a way to implement implicit relationships going in the other direction (i.e. from shadow to light DOM, such as implicit form participation) would be very useful, but that it doesn't fit in this proposal
- it may well fit with a similar API providing a "source" rather than a "target" inside shadow DOM, which may be worth investigating in the near future
There was a problem hiding this comment.
Oh, and we created a Matrix channel: https://matrix.to/#/#wicg-aom:matrix.org
There was a problem hiding this comment.
Thanks for all the good discussion! It sounds like the consensus from the webengineshackfest was to accept this support for implicit label relationships, right? I'm going to merge this PR now, as I'm going to be moving the explainer to the WICG/webcomponents repo and I'd like to resolve this first. If there's still more to discuss, it could be done in a follow-up issue in WICG/webcomponents.
Update the explainer to allow implicit association of nested labels. This was discussed at the web components F2F (WICG/webcomponents#1050) and deemed to be a worthwhile feature to add.
Fixes #209