Intent to Prototype: Accordion pattern using <details> elements
David Baron
Contact emails
dba...@chromium.orgExplainer
https://open-ui.org/components/accordion.explainerhttps://github.com/dbaron/details-styling
Specification
NoneSummary
This is a set of work to enable better platform support for the accordion widget pattern, and particularly exclusive accordions, using HTML <details> elements. As we see it right now (and this could certainly change) this work appears to consist of three parts: the ability to link multiple details elements together to semantically be an accordion (possibly with some small changes to keyboard behavior and/or accessibility roles, but likely not), improvements to stylability of details elements (particularly around styling/replacing the marker and having more flexibility to lay out the parts), and improvements to the accessibility of <details>/<summary> (particularly related to problems of interactive content inside of the <summary>).
This work is still at an early stage, and the process of working out what specific features will be part of this work is still happening. That process will involve discussions (some already started) in appropriate venues, starting with the Open UI community group.
Blink component
Blink>HTML>DetailsMotivation
Developers regularly use accordions on the Web. Today, that generally means that they build their own widget rather than using a widget provided by the platform, either because there is no widget for exclusive accordions, or because the existing widget for disclosures and non-exclusive accordions does not meet their needs (most likely due to stylability). This proposal is suggesting that we add features for exclusive accordions and better stylability of <details> to the platform. Doing so would help users because it would make (or at least would enable making) the user experience more consistent, and generally better, in a number of areas: * keyboard shortcuts and focus handling, * exposure via ARIA to assistive technology, and * integration with browser features such as find-in-page. Reducing the need for developers to build their own widgets should also reduce the size of pages that use such widgets, which reduces the time and bandwidth needed for users to load those pages.
Initial public proposal
https://github.com/openui/open-ui/issues/725TAG review
TAG review status
Not yet requested. I intend to do so after the ideas are a bit more concrete.Risks
Interoperability and Compatibility
There's some interoperability and compatibility risk around changes to <details> styling. Currently details styling is not interoperable as there are two different approaches, one taken by Gecko and (current) Chromium, and another taken by WebKit (which was previously shared with Chromium). I plan to consider interoperability and compatibility when deciding what approaches to improving <details> styling are viable.
Gecko: No signal. (See "Tag review status" above.)
WebKit: No signal (See "Tag review status" above.)
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
not yet sure, mainly because approach to <details> styling is not yet determined
Debuggability
Too early to tell for sure, though probably mostly similar to existing debugging of CSS. It's possible UI to find the elements in a group would be useful (as it might be for radio inputs).Is this feature fully tested by web-platform-tests?
No, but I intend to add tests as it is developed.Flag name
Requires code in //chrome?
FalseEstimated milestones
No milestones specified