Working Group Decision on ISSUE-93 details

Semantics

The details element is advocated based on the argument that it carries semantics. Proponents argue that the <details element provides useful semantics—that of optional content that could be skipped. And it is posited that semantics should be expressed at the semantic layer (HTML), not the presentational or accessibility layers; otherwise tools have to guess from CSS.

There doesn't seem to be much dispute about the benefits of semantic elements. It is not disputed that expressing semantics with a built-in element or attribute is more likely to be media independent, and more likely to afford universal access.

However, some dispute whether the element is truly semantic in nature. They argue that behavior is not semantics, that the specific proposed collapsible behavior doesn't change meaning, and that the idea of a collapsible section is a purely presentational construct. Some would go so far as to say that having elements with built-in behavior is a layering violation.

But this line of argument proves too much. Many elements have default behavior which is deeply tied to their semantics. This is clearly true of form controls, but arguably this also applies to the <a> element. HTML is by nature a hyperlinked medium, so it is natural that some semantic concepts are closely tied to a particular behavior.

Thus, the argument that <details> is semantic is stronger than the counter-arguments.

A Common Pattern

It is not disputed that the details element captures a common idiom in Web user interfaces. Some specific examples of this idiom include optional parts of forms, or the convention of spoiler warnings on discussion forums. In addition to the Web, the type of control represented by the details element is also common in a number of user interface toolkits.

Many viewed it as important to serve common interface idioms with built-in language functionality. Others conceded that this pattern was common, but that JavaScript-based implementations would be sufficient. In addition, it has been claimed that the benefits of adding built-in elements may exceed the costs.

To determine whether this particular common pattern should be served with a built-in element, it is necessary to investigate the feasibility of JavaScript-based implementations, and the costs and benefits of native implementations.

JavaScript-based Implementations

Advocates of removing the details element argue that implementing collapsible behavior is comparatively easy, and can be done with script libraries. However, it is disputed whether this alone is sufficient to omit a feature from HTML5 itself. For a semantic markup language, the availability of imperative alternatives should not preclude adding a declarative construct.

In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.

While the downsides of JavaScript-based implementations are not grave, there appear to be some genuine disadvantages. So the ability to achieve the functionality of details in JavaScript is not a strong argument for removing details.

Deployment Costs

Opponents of the details element argue that the costs of implementing <details> across the whole ecosystem (html editors, authoring tools, validators, browsers, educational (materials) may be high and may exceed the benefits of packaging common behavior.

However, there seems to be some evidence that many of the affected constituencies are willing or even eager to bear the cost.

Implementors of the of the leading browser engines, WebKit, Gecko and Presto, have expressed interest in implementing this element. Microsoft, the vendor of the remaining well-known browser engine, Trident, have not made any specific statements, but have not objected to it, even while citing other aspects of HTML5 as problematic.

There is some evidence that the details element is well-liked among authors. For example, the "HTML5 Super Friends" group of Web standards experts supports the <details> element, demonstrating support in the authoring community. Searching the material available online confirms that the material is largely well received. In addition, of the many authors who have recently written or are currently writing books on HTML5, few if any have complained about the burden of documenting this element.

A final point is HTML editing software. Having any new elements is mentioned as a potential burden for authoring tools. However, others counter that without a new element, editors can't handle details-like functionality in a consistent and reliable way. If this behavior is to come solely from script libraries, then editors would have to recognize a wide range of script libraries and would have to generate output compatible with them, which would be a challenge for interoperability. In any case, there is no indication of any implementors of authoring tools commenting on this matter, and suppositions about how they may be impacted are less persuasive than direct input.

Another concern raised is that <details>, when added to an existing structured document, may result in "double semantics," where content already has an existing semantic relation which may be stronger than the summary/details relation. While that is certainly possible, a number of examples and use cases have been presented where <details> clearly works well.

Overall, while it is true that any new element has deployment costs, in this case, many of the affected communities seem willing to bear the costs. Thus, deployment costs are not a compelling reason to remove the details element.

Slippery Slope

Some argue that including <details> may lead to a slippery slope which leads to too many new elements. Slippery slope arguments are not always invalid. But in this case, no specific arguments were given for how this would happen. Furthermore, there does not seem to be a flood of new elements in the spec in practice, and indeed many features are being removed in preparation for Last Call.

The slippery slope argument, in the absence of supporting evidence, is not a compelling reason to remove the details element.

Dynamic behavior without scripting

The argument has been made that many users expect that, when JavaScript is disabled, there will be no dynamic or interactive effects on a page, and that collapsible sections will all appear expanded. It is further noted that this technique may be used as an aid to printing.

However, many declarative techniques exist which cause dynamic styling without script. For example, the use of :hover in CSS to build dynamic menus is commonplace. And indeed XForms and SMIL provide declarative dynamic behavior.

It could even be argued that having a control which retains behavior even with script disabled is a positive benefit. Users who disable JavaScript for security, stability or performance could still benefit from an improved user experience.

Because this argument cuts both ways, it does not constitute a strong objection to the details element.

Custom style

Yet another objection to details is that it will not have sufficiently customizable style. This would indeed be unfortunate if true. However, while multiple WG participants made this argument, no concrete evidence was presented. Browser implementors have expressed an interest in providing extremely flexible styling for all newly added controls. There is no evidence on the table that they would fail in this case.

Since there is an expressed interest among implementors in providing customizable styling, and since there is no evidence that it will not be provided, this argument is not a strong objection to the details element.

Accessibility

Many of the arguments in favor of details and against removing it were based on accessibility. Several WG participants cited expert opinion. It was pointed out that the use of semantically rich elements in general is an expressed desire of the W3C Accessibility (WAI) community. And in particular, the HTML WG's Accessibility Task Force opposes the removal of the details element.

In addition to citations of expert opinion, concrete arguments were made for improved accessibility. In particular, many pointed out that authors are much more likely to create accessible markup when the elements they would wish to use naturally provide for accessibility, rather than having to use additional markup or specific libraries to tend to accessibility. Content authors have limited time, thus it is important to make accessibility as easy as possible, it was argued.

Others countered that details may have unknown accessibility problems, either as designed or as it will be implemented, and there has not been sufficient investigation to show that there aren't problems. While it is true that there may be undiscovered problems, this is less concrete than the argument for benefits. In addition, the need for further review is not an argument for dropping a feature at this stage of the process. Last Call is one of the primary tools that Working Groups use to seek broader community review.

Overall, the preponderance of the evidence is in favor of accessibility benefits.

Benefits of Native Implementations

A number of specific benefits were claimed for a native element to support the functionality of details, as opposed to a script-driven implementation.

First, the potential for consistency with the OS-native look was cited. While some did not consider this a worthwhile tradeoff, it seems like it would provide value to at least some Web developers. Second, some pointed out that built-in markup is more likely to survive syndication or other contexts where whitelisting is likely, as compared to purely JavaScript-based implementations. Third, some mentioned that the <details> element reduces overall code size; while next to negligible at the individual page level, this could be a measurable difference over millions of page views.

Others cited broader benefits. It was argued that when a particular semantic, presentation, default behavior and accessibility presentation all go together, it's more convenient for authors to have a single construct to take care of all aspects. Doing so, the argument goes, avoids needless complexity. The case was made that having the details element would reduce incidence of media-dependent, buggy author attempts to emulate such functionality using JavaScript and CSS.

Some downplayed the value of these benefits, but they were not rebutted. Thus it is clear that a native implementation of details would provide some genuine benefits.

Maturity

Some argued against details on the basis of maturity, for example that it is a good idea but "half-baked" and could be improved. The proper way to address flaws in the details element is to provide specific comments identifying those flaws. A general statement of half-bakedness is not a strong objection.

It was claimed that <details> lacks a transition plan, however it is clear that the strategies described under Degrade Gracefully in the old design principles draft apply.

Other arguments were based on lack of native browser-hosted implementations, or presumed future lack of adoption, or the lack of "unambiguous support". These are fair points. However, in the W3C processes, it is not expected that all features will be implemented prior to Last Call. Indeed, it is only after Last Call that a formal Call for Implementations is issued. It is during the Candidate Recommendation stage that we should prune features that seem promising, but do not gain a critical mass of implementation support and author adoption.

Overall, maturity considerations would argue in favor of removing the <details> element. Maturity must, of course, be balanced against other factors, and considered in light of the fact that it is not critical for removal to occur at this time.

Conclusions

A number of arguments were made in favor of retaining the details element. A good case was made that <details> captures useful semantics. This case was stronger than the counter-arguments. The details element is agreed by all to capture a common idiom. Accessibility was cited by many as a benefit of the new element, and indeed a good case was made that accessibility would be improved overall. Other concrete benefits of a native details element were identified, including consistency with an OS-native look, greater likelihood of surviving syndication, reduction in code size, and reduction of authoring complexity. These benefits were not successfully rebutted and argue in favor of keeping the details element.

There were also arguments made against the details element. It was argued that JavaScript-based implementations of details-like functionality are good enough, and therefore no element is needed for this admittedly common pattern. However, some specific downsides to JavaScript-based implementations were identified. Deployment costs were cited as a reason to remove the details element. However, many of the affected communities seem to believe they would benefit overall, and are willing to bear the costs. A slippery slope argument was presented, arguing that retaining details would lead to too many new elements, but there is no evidence of this phenomenon taking place. Likewise, lack of custom styling was perceived as a risk, but no concrete evidence was presented. The presence of dynamic behavior even when script is disabled was also cited as a downside, but others argued that it was a benefit, and the evidence was not compelling in either direction. Overall, these arguments for removing the details element did not constitute strong objections.

One argument for removing details had more force—the maturity argument. The Working Group has in the past chosen to remove features from the draft for reasons of maturity. However, this factor was not decisive in itself, at least at this time, since the W3C Process allows further opportunities for review, implementation and feedback.

Overall, the arguments in favor of keeping details were stronger than the arguments for removing it. Only the maturity argument provided a strong reason for removal, and it is outweighed by the arguments in favor of keeping it. The details element is the type of element we should have in the spec at this point.