Working Group Decision on ISSUE-93 details
Question before the Working Group
Currently, the HTML5 Draft includes the <details> element, an element that "represents a disclosure widget from which the user can obtain additional information or controls". Some Working Group members have questioned whether this element merits inclusion in the HTML5 specification, and have proposed its removal.
Regarding this matter, some HTML Working Members raised ISSUE-93 details. The Chairs solicited Change Proposals and Counter-Proposals, and two concrete proposals have been submitted:
- Change Proposal: Remove the details element
- Change Proposal: Retain several newly-introduced semantic elements, attributes, and controls
The question before the Working Group is which of these Change Proposals to adopt with respect to the details element, based on which will draw the weaker objections. In other words, should we keep the details element, or remove it from the draft.
Short Summary of Arguments
It seems that the details element serves a valid, broad use case. It has interest from implementors and authors.
A number of arguments were made in favor of retaining the details element. It was argued that <details> captures useful semantics. Many cited the accessibility benefits of built-in elements, including details. A number of other concrete benefits were cited, such as OS-native look and likelihood of surviving syndication. These positive arguments were in general stronger than the counter-arguments, and provided strong reasons to keep details.
The maturity argument against details had more weight. 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.
Decision of the Working Group
Therefore, the HTML Working Group hereby adopts the Change Proposal to keep the details element. Of the two Change Proposals before us, this one has drawn the weaker objections.
Per this decision and the decision policy, bug 8379 has been closed and marked WGDecision.
Since the prevailing Change Proposal does not call for a spec change, no further actions are required.
Appealing this Decision
If anyone feels they have not received due process, or that their concerns have not being duly considered in the course of reaching this decision, they may make their concerns known to the Team Contact (Mike Smith) who will notify the Director.
If anyone strongly disagrees with the content of the decision and would like to raise a Formal Objection, they may do so at this time. Formal Objections are reviewed by the Director in consultation with the Team. Ordinarily, Formal Objections are only reviewed as part of a transition request. In the case of this issue, the Chairs have agreed to forward Formal Objections right away for expedited processing.
Anyone who would like to take either of these steps should first read the Review of Arguments Presented, below.
Revisiting this Issue
This issue can be reopened if new information come up. Examples of possible relevant new information include:
- Information about specific accessibility problems with the details spec.
- Information gained from implementation experience that would cast a negative light on this element.
- Information gained from authoring experience, once native implementations are available, that would cast a negative light on this element.
Review of Arguments Presented
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.
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.
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.
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
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.
Because this argument cuts both ways, it does not constitute a strong objection to the details element.
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.
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.
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.
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.
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.
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.