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.

Sign up for GitHub

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

Jump to bottom

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

Merged
merged 1 commit into from
Jun 14, 2024
Merged

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 6 additions & 11 deletions reference-target-explainer.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -250,7 +250,9 @@ A [form-associated custom element](https://html.spec.whatwg.org/dev/custom-eleme

#### Nesting inside `<label>`

There is no special support for an element nested inside a label. The label must use the `for` attribute to work with `referenceTarget`. It is still ok to nest the custom element inside the label, but it must also use `for`.
Reference Target allows for labels to be implicitly associated with the target element when the host is nested inside a `<label>` element. The shadow tree's reference target will be associated with the label that contains the element. If the shadow tree is using `referenceTargetMap`, this uses the `for` attribute from the map.

In the following example, the label of the `<input id="real-input">` is "Fancy input".

```html
<script>
Expand All @@ -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.

// this.shadowRoot_.referenceTargetMap.htmlFor = "real-input";
}
}
);
</script>

<!-- ❌ This label isn't associated with anything because it doesn't use `for`,
and fancy-input is not form-associated. -->
<label>
Fancy Input
Fancy input
<fancy-input></fancy-input>
</label>

<!-- ✅ This label is applied to the inner `<input id="real-input" />`, which is
fancy-input's referenceTarget. -->
<label for="fancy-input">
Fancy Input
<fancy-input id="fancy-input"></fancy-input>
</label>
```

#### Nesting inside `<form>`
Expand Down