Exclusive accordion (<details name="">)

[dbaron]

こんにちは TAG-さん!

I'm requesting a TAG review of exclusive accordions (<details name="">).

This feature adds a name attribute to the HTML details element so that multiple details elements (disclosure widgets) can be linked into an exclusive accordion, i.e., a widget where opening one of the details elements closes the others.

• Explainer¹ (minimally containing user needs and example code): https://open-ui.org/components/accordion.explainer
• Specification URL: https://github.com/whatwg/html/pull/9400 (which contains links to preview the patched HTML spec)
• Tests: https://wpt.fyi/results/html/semantics/interactive-elements/the-details-element/name-attribute.tentative.html
• User research: no experiments, but some documentation of existing usage and categorization of existing design systems
• Security and Privacy self-review²:
  Review inline in this issue, expand for details:

  2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? No new information exposure over existing features. 2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses? Yes. 2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them? No handling of PII. 2.4 How do the features in your specification deal with sensitive information? No handling of sensitive data. 2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions? No. 2.6 Do the features in your specification expose information about the underlying platform to origins? No. 2.7 Does this specification allow an origin to send data to the underlying platform? No. 2.8 Do features in this specification enable access to device sensors? No. 2.9 Do features in this specification enable new script execution/loading mechanisms? No. 2.10 Do features in this specification allow an origin to access other devices? No. 2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI? No; the only effects are on in-page UI. 2.12 What temporary identifiers do the features in this specification create or expose to the web? None. 2.13 How does this specification distinguish between behavior in first-party and third-party contexts? No distinction. 2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode? No differences between modes. 2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections? No. 2.16 Do features in your specification enable origins to downgrade default security protections? No. 2.17 How does your feature handle non-"fully active" documents? No handling. 2.18 What should this questionnaire have asked? No additional questions relevant here.
• GitHub repo: split between https://github.com/openui/open-ui and https://github.com/whatwg/html/pull/9400 (so probably best to reply here unless you have specific comments that belong on the HTML PR)
• Primary contacts (and their relationship to the specification):
  • L. David Baron (@dbaron), Google, author of explainer and PR
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • openui/open-ui#725
  • openui/open-ui#752
  • whatwg/html#9400
  • mozilla/standards-positions#831
  • WebKit/standards-positions#209
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://chromestatus.com/feature/6710427028815872
  • https://bugs.chromium.org/p/chromium/issues/detail?id=1444057

Further details:

• [X] I have reviewed (and was previously involved in editing) the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: none specifically, though as noted in some of the above urls, one of the ideas behind this feature is to avoid some of the problems with CSS Toggles by instead working on small features that can move faster.
• The group where the work on this specification is currently being done: Open UI Community Group and WHATWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
• Major unresolved issues with or opposition to this specification:
  • There are still a few unresolved issues discussed in the HTML PR, though I wouldn't characterise them as major.
  • There are existing issues with the <details> element that I hope to work on in parallel, falling into two categories:
    • Accessibility: There are a number of accessibility issues with the <details> and <summary> elements (really mostly relating to <summary>). While there are a bunch of links in different issues trackers, I'm currently working on a document trying to describe and categorize these problems that I hope to be able to share within a few weeks. I do hope to make some progress on these issues in parallel with this work, although I also don't think it's realistic to promise to "fix everything", but I do think it feels like there's a realistic path towards making significant improvements. These do represent real risk since it's possible this feature could increase usage of <details> and <summary> and thus expose these problems to more users.
    • Styleability: A major reason that <details> and <summary> aren't used as widely as they could be is insufficient styleability. I've started a document on what needs to be improved and how. I also hope to work on this in parallel, though I think it's worth trying to avoid getting these fixes landed too far in advance of the accessibility fixes.
• This work is being funded by: Google

You should also know that the current state of the prototype can be tested in current Chrome Canary or Dev, or in the future in Beta (within a week) or Stable (in a month or so) once they reach version 116, but only if you enable "Experimental Web Platform Features" in chrome://flags .

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify @dbaron

[plinss]

The handling of print here feels a bit awkward, it'd be nice if there was a way to force the details open via a media query. We do note that this also appears to be an issue with plain details elements so don't see this as a blocker.

[atanassov]

Following the links to a11y related issues with selection and Summary element, it's unclear to me if introducing this behavior will increase the problem or help. Please consider further engagement in the related issues.

[hober]

@plinss, @atanassov, and I took a look at this during the TAG's vF2F this week. See their comments above for specific bits of feedback. Overall, we're really happy with the simple, incremental approach you've taken here to add this feature to HTML. It fits right in with the existing use of name="" for radio buttons and checkboxes, and it doesn't require authors to change the existing structure of their documents. Thanks for bringing this to us for review!

[dbaron]

Thanks for the review.

A few (somewhat delayed) repsonses:

• The ability to force a details open (visually, at least, not semantically) in print styles is something that is possible with the current prototype I've been working on for my details styling work, though that's still at an earlier stage. I agree it's largely orthogonal to this particular feature, though.
• I have been trying to continue to engage in the a11y-related issues, and hope to be able to spend a bit more time on that relatively soon.