Summary: Eliminate the Details element, completely. Do not spin it off into another specification, or wrap it in a specification of its own.
The HTML5 specification states:
The Details represents a disclosure widget from which users can obtain additional information or controls.
Two examples of the use of Details are given: one where additional information is hidden; the other, where form elements are hidden within a set of details elements. Whether the details body is shown or not is based on the presence (or absence) of the boolean open attribute. If open is present, the body is displayed; if not, the body is not displayed. User Agents are supposed to respond in some way to a user request to open the details element by setting this boolean attribute, and to respond to a user request to close the details element by removing this attribute.
The purpose for the element, as provided by the editor, Ian Hickson, in the initial bug to remove it1 is:
The <details> element is needed to provide an accessible way of reflecting a common application widget in HTML-based applications without requiring authors to use extensive scripting, ARIA, and platform-specific CSS to get the same effect.
Before I address the Details element, generally, and the editor’s stated purpose for the element, specifically, I want to discuss the state of the art of this type of behavior as it exists today.
This type of behavior is well known and variously labeled a tabbed page, an accordion widget, or a sliding/collapsible menu/form/page section. The existing technology supporting this behavior is very well understood:
- All widgets feature a caption/label and associated section pair, that may, or may not be enclosed within another container element.
- A tabbed page widget typically features a layout where all of the labels are grouped and clicking a label displays its associated page. The first page is displayed, by default.
- An accordion widget typically features a layout where all of the labels displayed next to each other, and clicking a label opens the label’s section either directly beneath it, or to the side of the label.
- An accordion widget also typically only has one section open at a time.
- A collapsible widget, whether used in a menu, sidebar, or form, has a label and a section, and the section is display or collapsed only when the label is clicked. The collapsible widget’s page section is not displayed, by default.
- For all widgets, clicking the caption displays or expands the body element if it is hidden or collapsed.
- For the tabbed page, clicking the label for a new page also hides the previously opened page.
- For the accordion widget, clicking the label to display a new section typically collapses the currently opened section.
- For the collapsible widget, clicking the label when the widget is in the open state, collapses or hides the body section.
- There’s usually a visual element representing the state for an accordion or collapsible widget element—sometimes a triangle reflects the state of the body element, other times, a plus or minus sign is used
- There’s usually a visual element representing the state for a tabbed page widget—the background color of the tabbed page’s label differs from the background color for the other labels. Other visual indicators may also apply.
- For an accordion or collapsible widget, clicking the caption or label may display the body immediately, or it may trigger a timed event, whereby the body element is displayed in smooth incremental steps.
- For an accordion or collapsible widget, when the widget is in a collapsed or hidden state, the body section does not take up page space. When expanded or displayed, content following the expando or accordion section is pushed down (or over, if the element is a vertical widget), making way for the content.
Focusing specifically on the existing widget with behavior closest to the Details, the collapsible section, following is a comparison of control between how this behavior is implemented today, and how it would work with the details element:
- The details element is not accessible— there is no support for the element in any of the screen readers. There is WAI ARIA support for the collapsible section. In fact, ARIA support is currently built into many of the popular UI libraries, such as jQuery UI and the Yahoo YUI ARIA menu plugin, the Google Web Toolkit, and so on.
By continuing the trend that has been established for the last decade when it comes to widget (dynamic application) development, we have a much greater control over every last aspect of how this widget behaves. Moreover, this control does not come at the cost of accessibility. If anything, with recent efforts related to WAI-ARIA, we’re seeing a greater integration of accessibility into dynamic effects.
Another rationale given in support of the details element is in the comment section for the bug that led to this issue: web designers can add collapsible web sections to web pages without having to get help from developers. However, designers can do this now, with any number of packaged libraries, using the same elements and attributes that they would use for a section that isn’t animated. More importantly, the designers can do so now, and still have control over not only the appearance of the collapsible sections, but even aspects of the widget’s behavior–choosing a library that allows the section to expand and collapse slowly, as compared to one that does so all at once.
To summarize, the rationale for removing the details element includes:
- The type of behavior encompassed with details is well understood, and simple to implement with existing technologies.
- Existing implementations of this type of behavior allow for an amazing number of variations in how the behavior is applied, giving web developers far greater control over the behavior.
- There is WAI-ARIA support for this type of functionality, but there is no accessibility support for details
- There are dozens possibly hundreds of widgets, libraries, plug-ins, and so on support this behavior, and can be as simple to implement as adding a class name to an element.
- Many Content Management Systems, such as WordPress and Drupal provide built-in support for these types of widgets
- Introducing declarative animation into HTML also introduces problems with printed pages and other environments where scripting is disabled and the expectation is that such elements would be open, by default.
Based on the March 4th draft of the HTML5 specification, remove Section 4.11.1, which defines the detals element, and all other references to it within the HTML 5 specification. This includes removing Section 10.4.3, containing a description of the details rendering.