proposal: open <details> when the user navigates to an ID inside it

[prlbr]

Can we make details open automatically when a user navigates to an ID inside it?

Consider the following code on a page https://example.org/:

<details>
<summary>About the author</summary>
<p id="pro">…</p>
<p>…</p>
<p id="family">…</p>
</details>

On another page there’s a link that points to https://example.org/#family. Currently, that link won’t lead a user who clicks on the link to the paragraph with the id="family", although that would be helpful and I can’t imagine – from an author’s or user’s perspective – why it should not.

[domenic]

I think this is probably a good idea. I wonder if we can reuse the event (or perhaps the whole concept??) from searchable invisible DOM, since the issue is not only anchor links, but also tab navigation, find in page, etc. /cc @rakina

[rakina]

Hmm summary & details element are implemented with user agent shadow roots in Blink, and anchor links are not working if it's in a shadow tree in general. But I agree for this case it should work, especially since in the spec for these elements there's nothing saying about shadow roots.

[tabatkins]

Anchors in the shadow tree don't work, but light-tree anchors that get slotted still should, right?

[rakina]

Anchors in the shadow tree don't work, but light-tree anchors that get slotted still should, right?

Oh yeah you're right. Nevermind the comment on shadow things then. This should work, but I don't know whether it's better to have these things as an event so that authors should toggle when necessary or just let the UA do it automatically.

[tigt]

This would be especially helpful for the use-case where each <details> is a section, as the spec specifically goes out of its way to mention that <summary> can contain a single heading element. FAQs in particular, I imagine.

[chrishtr]

We should also open these elements when find-in-page or scroll-to-text fragments target an element within the <details> element. I think the main questions is whether this is web compatible or not; if not we'd need an opt-in attribute.

[domenic]

It's hard to imagine what compat problems would arise, since it's hard to write a test that depends on find-in-page or scroll-to-fragment or scroll-to-text-fragment. It's technically doable, using window.find() or location.hash = ..., but I have a hard time imagining pages setting those to some hidden value/ID and then assuming that the <details> remains closed.

Also, since the user can open/close the <details> at any time, it's hard for code to take a dependency on its current state; most code needs to be reactive to changes. (I guess one implication of this is that we need to be sure to fire the appropriate event, so that code which uses that event to synchronize details.open with its own internal state continues to work.)

So, I'm optimistic for this change.

[chrishtr]

I think the compat problems, if they occur, would be that developers may not like the behavior and not want it to auto-open. If that is true (and I really have no direct data on it either way), we could solve it with an opt-out attribute.

Thinking more, seems good to have the opt-out and ship it by default. Always good to have DOM content be accessible to the UA algorithms by default.

[josepharhar]

seems good to have the opt-out and ship it by default

Any ideas on what this opt-out should look like? I think an attribute would make sense. Does anyone have any other ideas or a name for the attribute? How about searchable=false or notsearchable? Does anyone think that adding an opt-out is a bad idea?

[annevk]

I'd like to know more what motivates an opt-out. In part this seems a UA UI decision and in part I worry that users would be confused why some of these end up opening and others not.

[josepharhar]

I'd like to know more what motivates an opt-out. In part this seems a UA UI decision and in part I worry that users would be confused why some of these end up opening and others not.

After thinking about it more, I agree that there shouldn't be an opt out.

[josepharhar]

I opened a PR for this feature: #6466