[w3ctag/design-reviews] Exclusive accordion (<details name="">) (Issue #866)

こんにちは 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](https://open-ui.org/components/accordion.explainer/#developer-demand-for-exclusive-accordion) and [categorization of existing design systems](https://open-ui.org/components/accordion.research)
  - Security and Privacy self-review²: <details><summary>Review inline in this issue, expand for details:</summary>
    [2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?](https://www.w3.org/TR/security-privacy-questionnaire/#purpose) 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?](https://www.w3.org/TR/security-privacy-questionnaire/#minimum-data) Yes.
    [2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?](https://www.w3.org/TR/security-privacy-questionnaire/#personal-data) No handling of PII.
    [2.4 How do the features in your specification deal with sensitive information?](https://www.w3.org/TR/security-privacy-questionnaire/#sensitive-data) No handling of sensitive data.
    [2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions?](https://www.w3.org/TR/security-privacy-questionnaire/#persistent-origin-specific-state) No.
    [2.6 Do the features in your specification expose information about the underlying platform to origins?](https://www.w3.org/TR/security-privacy-questionnaire/#underlying-platform-data) No.
    [2.7 Does this specification allow an origin to send data to the underlying platform?](https://www.w3.org/TR/security-privacy-questionnaire/#send-to-platform) No.
    [2.8 Do features in this specification enable access to device sensors?](https://www.w3.org/TR/security-privacy-questionnaire/#sensor-data) No.
    [2.9 Do features in this specification enable new script execution/loading mechanisms?](https://www.w3.org/TR/security-privacy-questionnaire/#string-to-script) No.
    [2.10 Do features in this specification allow an origin to access other devices?](https://www.w3.org/TR/security-privacy-questionnaire/#remote-device) No.
    [2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?](https://www.w3.org/TR/security-privacy-questionnaire/#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?](https://www.w3.org/TR/security-privacy-questionnaire/#temporary-id) None.
    [2.13 How does this specification distinguish between behavior in first-party and third-party contexts?](https://www.w3.org/TR/security-privacy-questionnaire/#first-third-party) No distinction.
    [2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?](https://www.w3.org/TR/security-privacy-questionnaire/#private-browsing) No differences between modes.
    [2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?](https://www.w3.org/TR/security-privacy-questionnaire/#considerations) No.
    [2.16 Do features in your specification enable origins to downgrade default security protections?](https://www.w3.org/TR/security-privacy-questionnaire/#relaxed-sop) No.
    [2.17 How does your feature handle non-"fully active" documents?](https://www.w3.org/TR/security-privacy-questionnaire/#non-fully-active) No handling.
    [2.18 What should this questionnaire have asked?](https://www.w3.org/TR/security-privacy-questionnaire/#missing-questions) No additional questions relevant here.
    </details>
  - 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](https://www.w3.org/TR/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](https://docs.google.com/document/d/10JxXgeDAJ5zerOdxoWM9ZU9d5iMOdzGJt0EhlhkOkxM/edit) 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](https://open-ui.org/) and [WHATWG](https://whatwg.org/)
  - The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): [WHATWG](https://whatwg.org/)
  - 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](https://github.com/dbaron/details-styling) 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

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/866
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/866@github.com>