Summary
Summary: Eliminate the Details element, completely. Do not spin it off into another specification, or wrap it in a specification of its own.
Rationale
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.
- Control of the behavior for all three types of widgets is implemented with a combination of JavaScript and CSS.
- 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.
- Best practices dictate that when JavaScript is turned off, all tabbed pages for a tabbed widget are displayed by default, and the labels either hidden by default, or aligned with the tabbed pages as headers.
- Best practices dictate that when JavaScript is turned off, all accordion sections are displayed by default; the section labels may, or may not, be hidden by default.
- Best practices dictate that when JavaScript is turned off, a collapsible widget’s body section is displayed by default; the collapsible widget’s label may, or may not, be hidden by default.
As you can see, the tabbed page, accordion, and collapsible widgets are more complex and richer than one would assume from reading something such as the Details element. That’s because in the current state-of-the-art for these types of widget, where such behavior is implemented with CSS and JavaScript, we have a higher degree of control over every aspect of the widget.
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 visual indicator representing the state of the widget can be modified using the JavaScript/CSS approach. At this time, the visual indicator for the Details element is controlled by the User Agent.
- Expanding the collapsed portion of the widget can be implemented incrementally with the JavaScript/CSS approach. Tthe expansion of the collapsed portion of Details has two states: fully open, fully closed. There are no JavaScript controls to incrementally implement the state.
- The expansion and collapse of a JavaScript/CSS collapsible section is totally under the control of the web page developer and whatever scripting libraries used. The details element is under the control of both the browser and potentially the web developer, though there is no way to cancel the details element’s default behavior.
- By default a well designed web page expands all hidden page sections if JavaScript is turned off; users have come to expect this encouraged behavior. By allowing an expandable section to exist regardless of scripting, we’re introducing a new and possibly unwelcome web state. Moreover one, unlike Flash, Ads, or JavaScript, or even CSS, the user can’t control.
- By default, a well designed web page expands all hidden page sections if the page is printed (typically by providing a web page where all of the elements are present, as defined in the web page, but the JavaScript files have been removed). There is no way to turn off Details, as well as turn off JavaScript. In fact, we would have to use JavaScript to add the open attribute to the element in order to offset the default behavior for the 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.
So, the details element is not superior to the current state-of-the-art for this type of functionality. In addition, implementing a well defined and well understood JavaScript/CSS/ARIA behavior as declarative animation built into the HTML specification introduces the potential for explosive growth in HTML.
Earlier, I listed several forms of web space widgets: tabbed pages, an accordion, and a collapsible section. Only the last option is an equivalent JS/CSS behavior comparable to the Details element. However, it is feasible to list all three because if there’s justification for adding a declarative equivalent for one, there’s equal justification for adding a declarative equivalent for the other two…or for the dozens of other commonly used, packaged JavaScript/CSS behaviors.
Once we’ve opened this declarative element door, it becomes increasingly difficult to justify shutting it, again. This action could lead to a never ending set of behaviors being integrated into the existing and future versions of HTML—incorporating as elements that which was gracefully handled by JavaScript and CSS. Taking this action impacts not only browser makers, but also HTML editors, Content Management Systems, validators, and other tools, which have to increasingly expand and add new items, new objects, new behaviors.
More importantly, there is no graceful way of integrating this new declarative elemental behavior in with existing JavaScript/CSS application development. The existence of a Details element fractures the clean separation between behavior, style, and structure that had existed to this point, and has served us well, as witness the many and sophisticated applications we use today.
We have to return, then, to the question of why are we adding this new element? The HTLM5 editor has stated the reason is because of accessibility, but as I demonstrated, we have applications, tools, libraries, plug-ins, and widgets that already provide accessible collapsible sections. Not only is the details element not complementary to the existing implementations, we’re sending a confusing message about what direction web developers and designers are supposed to follow. Do we encourage people to continue using JavaScript, CSS, and ARIA? Or do we provide hit and miss declarative animations—one element here, another element another time— that tell people that yes, use JavaScript/CSS/ARIA for this, but not for that, and maybe use them today, but not tomorrow? This very inconsistent direction will not only not support accessibility, it could very well generate a great deal of pushback against incorporating accessible solutions.
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.
A third rationale for the details element is that it doesn’t require JavaScript, and so we don’t have to burden our pages with large JavaScript libraries. Well, I’m not sure what folks are expecting but I’ve not found libraries such as jQuery or Prototype to be prohibitively large. In fact, their use is so integrated into today’s web world, that most CMS applications, such as WordPress or Drupal, include these libraries by default. Yes, and provide widgets in order to easily add collapsible menus, sidebar items, footer elements, and so on. All one has to do is typically pick an option from a list.
Another aspect of the existing implementations, too, is that most libraries and widget developers understand well the importance of progressive enhancement. Based on this underlying concept, when script is turned off, and the page is opened, the widget is set to be expanded by default. So the individuals using these widgets never have to touch JavaScript, or modify their page elements based on whether scripting is enabled or not. The widgets just work, right out of the box.
This same cannot be said with Details. Either the web page designer has to define a secondary page for use for a non-scripted, non-interactive environment, such as printing, or the designer is going to have add their own JavaScript to close all Details left as open, by default.
The details element, and other like it, such as progress, are the wrong direction for the W3C to take, and for the HTML WG to pursue. WAI-ARIA is to accessiblity, as behavior is to JavaScript, as CSS is to style, as RDFa/Microformats/Microdata is to semantics, as HTML is to page structure. It works, and by the proliferation of Ajax-like functionality we see today, it works well. I cannot see giving up the direction we’ve been following for the last decade, for the promise of a few elements now, and hundreds of single-purpose elements to come around in HTML 6, 7, 8, 9, and so on.
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.
- Introducing declarative animations as replacements for JavaScript/CSS/ARIA behaviors now, opens the door for a proliferation of such elements in the future, not only adding to the processing burden on browsers, but also adding to the complexity of HTML editors, CMS, WYSIWYG tools, and so on.
Details
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.
Impact
Positive Effects
Removing the details element allows us to continue to progress with our use of JavaScript, CSS, and ARIA to create interesting, diverse, and accessible dynamic behaviors. It also prevents a possible explosion of such declarative animations in the existing and future versions of HTML, which will adversely impact on browsers, HTML editors, tools, and so on.
We’re free to continue using the tools we have now, rather than having to stop and change direction. And since this type of widget/behavior is so well understood and supported, we can do so without having to use JavaScript if we don’t wish to use JavaScript, but still be able to have finite control over the behavior, as well as appearance of the widget. Best of all, because ARIA is being incorporated into these existing tools, we’re adding accessibility to our web applications without having to change one line of code, or one line of markup.
We’re removing the potential conflict that something like the details element introduces. Today users have the ability to turn off Flash and JavaScript, but we don’t have any way to control declarative animations. Taking control away from the users is not a direction I think we want to take in the HTML WG.
Negative Effects
This change will take some of the HTML5 editor’s time to implement. In addition, if we wish to incorporate collapsible sections into our web pages, we will have to use JavaScript.
References
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13
http://test.cita.illinois.edu/aria/tabpanel/tabpanel2.php
http://docs.jquery.com/Plugins/Validation#Example
