This weekend saw the minting of not one but two new elements. The summary element (not the summary attribute on the table element) goes inside the details element:

<details>
<summary>More information</summary>
<p>Here is the source data that is discussed in the article ... </p>
</details>

This is designed to produce an “expando” box that is closed by default (but can be open by default using the boolean open attribute), only displaying the text specified by the summary as a control. Activating that control opens the whole details element; re-activating closes it again. If no summary text is present, the browser defaults to the rubric “details”. (Added 4 Feb 10:) In browsers that support details, this behaviour does not depend on author scripting, and should work even if JavaScript is disabled or not present.

figcaption lives inside the figure:

<figure>
<img ... > (or video, table etc)
<figcaption>A rabid unicorn goring a fairy.</figcaption>
</figure>

If you want some history, continue reading. Otherwise, bye bye!

Previously, the legend element was specified to do the job of both. Unfortunately, every browser had parsing problems re-using it outside forms. Similar problems were encountered attempting to re-use the caption element outside tables. At Jeremy Keith’s suggestion, the spec then re-used dd and dt, but that breaks too.

Now, two new elements are minted. (I quite fancied one new element – rubric for both, but it’s a pretty esoteric word.)

One of the objections to details, as described by Shelley Powers in her bug to remove it is

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.

My counter-argument was that 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 page size 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.

While I like to think that the irrefutable logic of my argument, coupled with the tear-jerking rhetorical flourishes in my prose captured both the heart and the head of the editor, I suspect what persuaded him was Apple’s Maciej Stachowiak saying that “the webkit community” were interested in implementing details once the spec was nailed down. Implementation wins the day.

Share and Save:

Hello, summary and figcaption elements originally appeared on HTML5 Doctor on February 1, 2010.