no-nested-interactive Rejects Elements in <details> Body
See original GitHub issueThe no-nested-interactive lint check rejects the following structure
<details>
<summary>Click to expand</summary>
If you <button>click here</button> something will happen.
</details>
with a Do not use <button> inside <details> no-nested-interactive
error.
This seems like a perfectly reasonable HTML structure to me. Per MDN on the <details> element:
A disclosure widget is typically presented onscreen using a small triangle which rotates (or twists) to indicate open/closed status, with a label next to the triangle. If the first child of the
<details>
element is a<summary>
, the contents of the<summary>
element are used as the label for the disclosure widget… A<details>
widget can be in one of two states. The default closed state displays only the triangle and the label inside<summary>
(or a user agent-defined default string if no<summary>
)… When the user clicks on the widget, or focuses it then presses the space bar, it “twists” open, revealing its contents.
And it specifies permitted content as “One <summary>
element followed by flow content” without excluding interactive content.
A <details>
element should not appear inside another interactive element and interactive elements shouldn’t appear inside the <summary>
element, but the body of an expanded <details>
is not interactive and interactive elements inside a <details>
behave as they would in a regular <div>
.
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (10 by maintainers)
Top GitHub Comments
I think we need to test this in practice with one or two screen readers to see what they actually do. I still think that I would expect the detail itself to be allowed to have interactive content, so I’d like to see if they do actually break / do a bad thing.
Following up- I’m going to close the issue since the behavior is technically correct-
no-nested-interactive
rule should reject interactive elements inside of a<details>
element.More reading: