Browser does not scroll to an item hidden in a collapsed details HTML element

[jvyang]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Prerequisites

• I'm using the latest version of Docusaurus.
• I have tried the npm run clear or yarn clear command.
• I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
• I have tried creating a repro with https://new.docusaurus.io.
• I have read the console error message carefully (if applicable).

Description

Clicking an item from the TOC on the right does not scroll down to the section if the selected item is in a collapsed details HTML element.

It works expected when the details section is expanded.

Reproducible demo

https://codesandbox.io/s/runtime-wood-96c61u?file=/docs/issue.md

Steps to reproduce

1. Navigate to Tutorials
2. Click on issue from the left sidebar
3. Click on Heading 3A - Click here! from the TOC on the right

Expected behavior

Once the item from the TOC is clicked, the details section will expand automatically and browser will scroll to the header.

Actual behavior

Browser does not scroll to the item selected.

Your environment

• Public source code: https://github.com/jvyang/docusaurus-details-bug
• Public site URL:
• Docusaurus version used: 2.0.0-beta.18
• Environment name and version (e.g. Chrome 89, Node.js 16.4): Chrome 100.0.4896.75, Node.js v16.14.2
• Operating system and version (e.g. Ubuntu 20.04.2 LTS): Ubuntu 20.04.4 LTS (WSL2 on Windows 10)

Self-service

• I'd be willing to fix this bug myself.

[Josh-Cena]

Hi, you can put the following into something like test.html:

<details>
<summary>Content inside</summary>
<h2 id="heading">A heading</h2>
</details>

And navigate to file:///path/to/test.html#heading in your browser. You'll see that the detail doesn't open by default. Well, it's not supposed to.

The same happens for tabs. See #5343

In general, an element doesn't know precisely what's inside it as that would be a very costly and hacky check (a tree traversal that's potentially very deep), so the details element won't know that (a) the page is now focused to an anchor (b) that anchor represents an element (c) that element is contained within me. There simply isn't enough information for it to make that decision.

If you think that UX is important, you can swizzle Details and implement the logic yourself, but it seems non-trivial to me.

Note that having headings within details itself is bad web design. You should NOT have structural content within collapsible/hideable areas as that could confuse people using visual aid tools. Only put supplementary, brief text within details, but not full sections.

[JoshuaKGoldberg]

Note that having headings within details itself is bad web design. You should NOT have structural content within collapsible/hideable areas as that could confuse people using visual aid tools. Only put supplementary, brief text within details, but not full sections.

@Josh-Cena do you have a source for this recommendation? It makes sense but I haven't seen it stated elsewhere. Other accessibility/docs sites might need to be updated.

[Josh-Cena]

I can't remember where I read it, sorry🤦‍♂️ It's also complicated because certain hideable elements (e.g. <details>) are server-rendered and less of a problem, while others (<Tabs>) are lazy-rendered and may not even appear in the initial markup. I just tried with VoiceOver—I can't speak for someone who actually relies on it, but the fact that a heading gets announced sometimes and gets ignored other times was confusing to me. See #5343 for another relevant discussion