Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Reference Target Explainer to add support for nesting inside labels #210

Merged
merged 1 commit into from
Jun 14, 2024

Conversation

behowell
Copy link
Collaborator

@behowell behowell commented May 29, 2024

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

@@ -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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

Igalia/webengineshackfest#38

Also, if you can make it, any suggestions for further topics to discuss would be welcome on that issue!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How was the session last week @alice?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, and we created a Matrix channel: https://matrix.to/#/#wicg-aom:matrix.org

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@behowell behowell merged commit 83e5908 into WICG:gh-pages Jun 14, 2024
1 check passed
@behowell behowell deleted the reference-target-nested-label branch June 14, 2024 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Reference Target feedback: nesting inside <label> and other implicit relationships
4 participants