One of my HTML5 change proposals is to remove the details element.
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 used with additional information, and one used with form 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.
Rationales for Keeping the Element
The rationale for keeping the element provided by the editor, Ian Hickson, in the initial bug to remove it 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.
A counter-proposal has been provided to keep the element. The rationale in the counter proposal is:
The notion of “optional” content that can be skipped over when reading the main content is a useful semantic to express.
This semantic is used in many webpages. For example, forms sometimes contain optional sections that are not necessary to successfully submit the form, but allow you to give extra information. Message boards often have a “spoiler” feature for hiding long sections of content that aren’t necessarily useful (such as a long digression proving some point used in an argument) or that readers may want hidden until they choose to view it (such as conversation about a movie or book that concerns important plot details).
The <details> element expresses this semantic, indicating that its contents may be optional or are otherwise suppressed, but may be called up and viewed or interacted with easily. The <summary> element provides a short description of the content within its <details> parent.
In addition, the Accessibility TF discussed the change proposal, and among the benefits discussed were the following:
- Specific behavior associated.
- Makes a control for a behavior that is frequently done in script. what details does is frequently done (badly and inaccessibly) in script.
- Specifically useful for accessibility.
- Authors often roll their own without getting the accessibility right, and it is expensive.
- There are things without elements, like accordions – I’d like to see elements for those too, rather than removing this one…from an interaction design perspective she might have a point that these are similar.
The Accessibility Task Force also provided a general statement regarding this element and others:
RATIONALE: The F2F believes these elements are actually useful for accessibility. We note that features similar to the elements in question are today created using elements with different semantics actuated by style and script, whereas we prefer native elements.
Summarizing the rationales for keeping details:
- This type of behavior occurs frequently
- This type of behavior is semantic
Starting from the top, I agree that this type of behavior occurs frequently. So frequently, in fact, that there are variations on the behaviors, and the concept of a collapsible, hidden page section has been incorporated into higher level accordion, popup menu, and tabbed page applications. This type of behavior has also been in use for many years, and is implemented in most User Interface libraries, such as Yahoo! UI (YUI), jQuery, Dojo, Mootools, and others.
Therefore, I agree with those providing counter-proposals that this type of behavior is common. However, I do not agree with the other rationales/assertions given.
Behavior is not semantics
I disagree with the assertion that this type of packaged behavior is “semantic”. There is nothing semantic about managing web space more efficiently by hiding a page section and only displaying the section based on some event. It is a convenience, a way of simplifying the presentation of the content.
I created four pages, each with collapsible sections. One implements the behavior with a div elements, similar to what we might find given in earlier examples (a “for more details section”); one implements the collapsible section behavior with form elements; another with an unordered list, like we might use with a menu; the last with table rows.
Difficulty of Implementing Collapsed Sections
The amount of code is insignificant, and that’s with me coding the behavior from scratch. This type of collapsible section is implemented in most UI libraries, and typically only requires either a single function call, or that we annotate a couple of page elements with a specialized class value. We’d probably annotate the elements anyway, in order to create the element’s unique style.
Not only is the amount of code needed small, it’s also important to note that the label/content sections of the different examples also make use of elements relevant to the uses. The form example uses form-specific elements (fieldset and legend); the table example, a table element (table rows). Even the use of an unordered list for the menu items is extremely common, as is the use of the div elements for the “more details” implementation.
The User experience and Accessibility
The HTML5 specification says the following about the behavior associated with details:
The user agent should allow the user to request that the details be shown or hidden. To honor a request for the details to be shown, the user agent must set the open attribute on the element to the value open. To honor a request for the details to be hidden, the user agent must remove the open attribute from the element.
There is nothing related to accessibility associated with the element. There’s nothing in the HTML5 specification about what user-initiated action each user agent will associate with the details element. Unlike a link (a), there is no actionable behavior associated with the details element. If, as is likely, the details behavior is only triggered by mouse clicks, we’ll have to attach a tabindex of zero(0) to the element, and add our own code to open and close the item, to make it keyboard accessible—if we can add this functionality, depending on how much control we can exert over details.
The examples I provided responded to both a click event, and a simple ENTER keypress event. Depending on the context of use, I can also add additional events. We don’t know what events we can attach to details, though, or which events we can intercept. We’re not even sure about what happens if we attempt to override the element’s default behavior, by manually assigning the open boolean attribute.
There’s no mapping, either, between the element and whatever accessibility API browsers support. We also have no way to attach existing ARIA roles and states with the element, because we don’t know if doing so could conflict with the default behavior— we just don’t have any input into, or control over this element.
So there is absolutely nothing accessible about the element. There’s not even the promise of accessibility— the element’s behavior is too vaguely defined yet inflexible, to enable even partial accessibility until each and every user agent implements whatever it deems appropriate. Considering the various ways in which we can implement a collapsible section behavior, we’re unlikely to ever have satisfactory accessibility with the element.
We also run into problems with being able to print pages that contain details managed content. According to Ian Hickson, the browser print page functionality is supposed to reflect the state of the page—printing out the details element contents if the element is open, not if it is closed.
Designers and web site owners are also going to have a challenging time integrating the element into a site’s design. As demonstrated with my examples earlier, I can style the label for my collapsible section anyway I want. I can also control the expanding and collapsing behavior: opening and closing the collapsed section slowly, or expand the section horizontally, rather than vertically. Other than some crude manipulation, such as changing background colors, we have no control of the design or behavior associated with the new details element. We don’t even have the option to change whatever icon is used to signal that the item can expand.
Now, some people may be aware of the limitations, but stress that lack of customization is a positive, rather than negative, aspect of details.
Returning to the rationales summarized earlier, the only point where I and those who provide counter-proposals agree is that the collapsible section behavior is used frequently. Is frequency of use of this type of packaged behavior enough to implement the behavior as an element?
First, let’s take a look at the cost of not implementing this element.
The cost to implement this functionality using existing tools has already been incurred. We’ve already paid the bill. Additionally, as my examples hopefully demonstrated, we can use this type of collapsible section behavior with a variety of web elements, for many different purposes, at no extra charge.
Now let’s look at the costs associated with adding the details element. Tools such as lint tools and validation tools have to incorporate functionality to cover the use of the new element—and considering the different ways in which we use collapsible elements, the probable misuse of the element. HTML editing tools have to incorporate support for the element, as well as providing preview functionality (it’s not a simple matter of just defining a new element). WYSIWYG tools have to find some way to not only incorporate an icon for the new element, but also the summary element, and do so in a valid manner. As has been noted elsewhere, the significant number of new elements in HTML5, and the vagueness of their definition, is already a cause for concern for WYSIWYG tool builders. Browsers have to implement support for the new element, which adds to the complexity of the browsers, as well as providing another point of failure. This is especially true since we’re using declarative animation where it has never existed before.
Whether everyone agrees with implementing declarative elements for these higher-level behaviors or not, I believe there is some general agreement among all those who protest my proposal to drop details that a) it’s better to have declarative elements, and b) the costs are primarily to the browser implementors, without significant impact on other communities. The writers of the counter-proposal have stated that the only cost they see to the element is:
Each new element, attribute, and control is extra functionality for browsers to implement, and for HTML educators, including tutorials, to teach.
However, as I hope I’ve demonstrated, there are significant costs associated with each new element and attribute added to the HTML5 specification, and that the impact can be felt by a great number of web communities. The group may decide the cost is worthwhile in the end, but it should, at a minimum, be aware of the costs and impacts on on all of the communities.
The details element is worth the cost if we believe one thing: that web page authors, designers, and developers will use this new element over existing libraries and implementations. Considering the state of the art of this type of functionality today, and how long before this element could be used in the majority of web sites, and how limited we are with both the styling of the element and where and how we can use it, I find it unlikely that the element will achieve widespread use. I’m confident saying it is unlikely the details element will be used enough to justify its cost.
The details element provides too little in the way of new functionality, and what it does provide, it provides too late.