This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I understand the interest in having this element. Rather than having to use JS to collapse or expand a section, the functionality can be built into the user agent. However, the use of JavaScript for the purpose of expanding or collapsing a section is both well-defined and common among web applications. More importantly, following the concept of progressive enhancement, these types of expanding sections are expanded by default if script is turned off. To have a section that is dynamic but not controlled by script is going to cause confusion, particularly among people who turn scripting off and are assuming that there are no "expando" sections in the web page. In fact, I don't see how this element will make developing web applications that much simpler. This type of functionality is trivial with JS. And has been noted by the HTML5 editor, there are already too many new elements in HTML5. I agree, and removal of Details would be a start to simplifying HTML5.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Given the concerns raised, I've taken it out of this version of HTML.
Checked in as WHATWG revision r4549. Check-in comment: Remove <details> from the HTML _5_ Core and Vocabulary working draft. http://html5.org/tools/web-apps-tracker?from=4548&to=4549
I disagree with the removal of this element. Although there were other difficulties (what element should be used instead of the original legend proposal, for example) the element itself is highly useful. An expanding/ collapsing area on the page is a very common requirement. I've seen sites pull in a whole JavaScript library just to accomplish this (presumably as the developer was unfamiliar with JS), which bloats the pagesize for the user. I've seen pages where the "details" information is set to display:none by default, and the user cannot expand the information without JS, thereby making the contents inaccessible if JS is not present. Reinstating this element would be advantageous to developers, who wouldn't need to learn JS to accomplish a common task; advantageous to users who would get an accessibility bonus from having this behaviour natively in the browser.
TrackerIssue
I have created a new tracker issue for this bug: http://www.w3.org/html/wg/tracker/issues/93
Shelley, that's a violation of the process. The bug was reopened, meaning the next step in the process is 5.c, not 5.d. Before we escalate this to a working group issue, I would like to request that you (Shelley and Bruce) see if you can come to some sort of compromise. Is there some solution that wouldsatisfy you both? For example, Bruce, is it critical for you that <details> be in this version of HTML, or would you be ok with it being in the next version of HTML (with <device>)?
(In reply to comment #6) > Shelley, that's a violation of the process. The bug was reopened, meaning the > next step in the process is 5.c, not 5.d. > > Before we escalate this to a working group issue, I would like to request that > you (Shelley and Bruce) see if you can come to some sort of compromise. Is > there some solution that wouldsatisfy you both? For example, Bruce, is it > critical for you that <details> be in this version of HTML, or would you be ok > with it being in the next version of HTML (with <device>)? > Whatever you do, do not specify a solution as "can it be in the next version of HTML". I will never agree to something like that. Sorry, but I think that is the worst approach we can take. I filed the original bug to remove the section. I'm not going to change my mind, and I feel my arguments were valid.
I also did not comment previously, but I would like to see this put back. The WebKit community is very interested in implementing this element. We feel it adds a lot of value for authors - collapsible areas of extra controls are a very useful design pattern, particularly in forms. And it's helpful to give it a polished standard implementation. Right now the main thing we're waiting on for our implementation is resolution of the dt/dd issue (which is partially rendered moot by removing <details>).
Checked in as WHATWG revision r4552. Check-in comment: Put back <details> into the W3C copy of the spec. http://html5.org/tools/web-apps-tracker?from=4551&to=4552
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected (original request) Change Description: no spec change Rationale: Based on the volume of objection to this change, I've put the <details> element back. I've left the TrackerIssue keyword since I assume Shelley is going to raise an issue on this.
How about if we use details/legend, but also allow an intermediate form until browsers catch up: the first child of details with the role of "legend" could be used instead of legend as well. Another, less desirable, solution could be an attribute in details that selects the element that acts as "legend" the way form elements have a form attribute. Examples of solution 1: <details> <span role="legend">Summary</span> <p>Long story</p> </details> <details> <p role="legend">The Legend...</p> <p>of HTML 5.</p> </details> <details> <legend><span role="legend">Details</span></legend> <p>Fall back is partially possible with this method</p> </details> Examples of solution 2: <h2 id="details_legend1">Details</h2> <details legend="#details_legend1"> <p>The gory details</p> </details> <details legend="#legend2"> <span id="legend2">Dislike</span> <p>I dislike the second solution because of its complexity, but it would be okay if there was no other way.</p> </details>
Since people have asked me what the rationale for having <details> in the spec in the first place was (as opposed to the rationale for having it in or out of a particular version of the spec, which I think is an editorial issue): 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. HTH.
Per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html, the HTML A11Y TF does not plan to formally work on this issue at this time. This does not mean the TF has no interest in it, but does not have immediate plans to work on it. The TF may review the issue in the future.
The Working Group has made a decision on the issue arising from this bug: http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html The WONTFIX resolution is confirmed. Closing and tagging WGDecision.