HTML5 Quick Feature: Summary and Details

Last week, the WebKit team added support for the HTML5 details and summary elements. This might leave some of you wondering: “ok, but what are the details and summary elements?”

Fair enough. Unlike the sexy article and section, or the utilitarian new input types, there are quite a few new features in HTML5 that most developers are unaware of. So let’s take a look at the latest of these to attain some—very modest—level of browser support: summary and details.

Expandable Boxes

A common feature of many web sites and apps is an expandable info box. Imagine a list of titles, that when clicked on will expand a little box containing more info about the topic. In the past, this could have been marked up any number of ways, perhaps using hx elements and divs. You’d then use JavaScript to handle the expanding and collapsing.

Take this example, from the WordPress post editing page:

WordPress uses a series of divs to pull this off:

<div id="commentstatusdiv">
<div title="Click to toggle"><br></div><h3><span>Discussion</span></h3>
<div>
  <input type="hidden" value="1" name="advanced_view">
  <p>
    <label for="comment_status"><input type="checkbox" checked="checked" value="open" id="comment_status" name="comment_status"> Allow comments.</label><br>
    <label for="ping_status"><input type="checkbox" value="open" id="ping_status" name="ping_status"> Allow trackbacks and pingbacks on this page.</label>
  </p>
</div>
</div>
<div id="authordiv">
<div title="Click to toggle"><br></div><h3><span>Author</span></h3>
<div>
  <label for="post_author_override">Author</label>
  <select id="post_author_override" name="post_author_override">
    <option>Aaron Boodman</option>
    ...
    <option>Zak Ruvalcaba</option>
  </select></div>
</div>

Of course, there’s nothing really wrong with this markup. It may not be super-semantic, but each section is clearly delineated with a heading, so it’s plenty usable and accessible.

But this type of info box is a very common behavior of websites and web applications that currently requires JavaScript to implement, so it was an ideal target to be standardized as a browser-based feature in HTML5.

What HTML5 Brings to the Table

The HTML5 specification has added a set of elements for exactly this purpose: details and summary.

From the spec:

The details element represents a disclosure widget from which the user can obtain additional information or controls.

The first summary element child of the element, if any, represents the summary or legend of the details. If there is no child summary element, the user agent should provide its own legend (e.g. “Details”).

So, in HTML5, the above example could be rewritten as follows:

<details>
  <summary>Discussion</summary>
  <p>
    <label for="comment_status"><input type="checkbox" checked="checked" value="open" id="comment_status" name="comment_status"> Allow comments.</label><br>
    <label for="ping_status"><input type="checkbox" value="open" id="ping_status" name="ping_status"> Allow trackbacks and pingbacks on this page.</label>
  </p>
</details>
<details>
  <summary>Author</summary>
  <p>
    <label for="post_author_override">Author</label>
    <select id="post_author_override" name="post_author_override">
      <option>Aaron Boodman</option>
      …
      <option>Zak Ruvalcaba</option>
    </select>
  </p>
</details>

Given this markup, the browser should display only the words “Discussion” and “Author.” When either of those terms is clicked on, the relevant summary should open up and reveal itself.

The summary element has an open attribute used to indicate that the summary is “open,” or expanded. It’s a Boolean attribute, so you can use it like <summary open> or, if you’re wedded to XHTML-style syntax, <summary open="open">. For the above example, if you wanted both boxes to be open by default (as they are in the WordPress interface), you’d just need to add this attribute to both details elements.

As I mentioned at the top, currently only the SVN trunk of WebKit has support for this element. Other browsers will display all the content, irrespective of the open attribute, and don’t allow you to toggle visibility of the details by clicking on the summary.

Polyfilling Support

If only the bleeding-edge SVN version of one rendering engine supports this element, why would anyone want to use it?

For one, support for HTML5 and CSS3 features is being added extremely quickly to most browsers. Once this moves from WebKit into Chrome, Mozilla and Opera won’t be far behind. So benefits will begin to appear soon enough.

But the main reason is that there’s no downside. If you’re using JavaScript to provide this functionality on your site already, you can continue to do so. Except that now, you can use JavaScript only for non-supporting browsers, and rely on the native implementation for your cutting-edge users.

Mathias Bynens has a quick jQuery script to detect support for details, and add support to older browsers. Check out the blog post describing his solution, as well as the accompanying demo. It’s win-win: you provide the functionality to everyone, make things a little better for ultra-modern browsers by relying on faster and more standard native functionality, and avoid cluttering your markup with stuff like class="expandable open".

Wrap Up

Were you already familiar with details and summary, or is this the first you’ve heard of them? Will you be testing them on your sites with Mathias’s polyfilly? Or will you stick to divs for the moment? Let me know in the comments.

Win an Annual Membership to Learnable,

SitePoint's Learning Platform

  • Andrew

    And IE will have none of it just as it has no support for virtually ALL of HTML5 forms. So we still need to write a JS fallback in ANY case.

  • AdamT

    Yes. Are you actually making a point?

  • Stormrider

    The fact that you need a JS fallback is covered in the article. See the second to last section.

  • AKRaven

    I just wish we could go back to the old days with: “This web site best viewed with..”
    and say “..a REAL browser. Please get rid of your IE piece of crap! If you don’t know what a browser is, then LEARN.”

  • Webnet

    AKRaven – you can, it’s just most developers refuse to.

  • RicktheArtist

    Webnet – Right, developers refuse to do it because they want to get paid. Half of the clients out their use IE and they will not pay until their site looks good to them on their own computer.

  • Rudie

    In Chrome 10.0.648.151 (stable!) has a property “open”… Bleeding edge? I also don’t see the desired effects in this Chrome. How to test for it if you can’t spot it?

    • Louis Simoneau

      Yes, unfortunately there are some builds of WebKit that include the element and its properties but don’t actually do anything with them … I didn’t experience this with my build of Chrome (current stable) though, only with some of the WebKit nightly builds (where the new rendering hasn’t been added yet)

  • Ragtime

    Exactly as Rick the Artist says. It’s all very well for code experts to get snippy about IE – and I’ no fan at all – but the fact is it remains the majority browser across the world and even IE6 still has a percentage share of users! We can sneer at it all we like, but in the workplace the user often has no choice. IT departments, especially in industry, often refuse to upgrade office or factory browsers or operating systems (XP is still dominant in many offices) due to cost/time/support – “it aint broke so why fix it?” – issues . So if you’re going to be a successful web developer in many circumstances you have to play to the lowest common denominator, like it or not.

    We can use cutting edge code as long as there is a bulletproof fallback across all browser options (including IE6 and 7), but you also have to justify the time and expense of doing it against the perceived benefits. Cool stuff isn’t always seen to be of value by those who hold the purse strings. That’s just life I’m afraid.

    • Louis Simoneau

      Agreed. However, in this case, my point is that the JavaScript can be exactly the same as what you’d be using for this effect anyway, but you can provide native functionality to the cool kids.

  • FlowerMountain

    Thanks for this article, I didn’t know about Summary and Details. I think it’s great.

  • Stoffb

    Sorry, but I have tried the code, what is it suppose to do? All I see is the full content, no toggle or anything else happening…

    • Louis Simoneau

      As I mentioned, this is currently only supported in the SVN trunk of WebKit. If you’d like to see roughly what it will do, look at Mathias’s demo of his JS polyfill, which works cross-browser.

  • Tarzano

    Can I use this on a mobile site? iphone has html5 right?

  • Tom

    I think it’s another great, if tentative, step into the HTML5-dominated future. With such low browser support I’m tempted to just stick to jQuery for these kinds of things, but then I figure, stuff it – be one of the first to toy around with the new tags, get it happening, be at the cutting edge and all. Even if it means writing buckets of fallback code. We’ll look back on our convoluted CSS3 style sheets and bizarre JS safety nets one day and laugh at how quaint coding was back in ’11.

  • kaf

    If I have to do a JS fail over why would I bother with the html5 way at all? Why would I give myself more work? Just do it in js…

    Honestly I don’t think that html5 or css3 should be doing things like this. Its outside of the scope of what markup is.

    Markup is just a way for us to encapsulate our data in a way that allows us to select it and provide our own styling and functionality.

    What is going to happen to this effect in 15 years when it is no longer popular on the web? Trends are always changing. You’d think that we would have learned from the BLINK tag how what we think is cool now won’t be for very long.

    My prediction: This will eventually go the way of the BLINK tag. We will look back at it and wonder how we could have thought this was cool.

    • Louis Simoneau

      Let me try to respond to both of your points. First of all, “if I have to do a JS failover, why bother with the HTML5 at all? why give myself more work?”.

      The thing is, it’s not more work! If you’re doing JS anyway for this UI device, then attaching that JS to element names instead of arbitrary classes is exactly the same amount of work. And including Modernizr (and Yepnope) and a quick call to check for support should take you about 30 seconds. Why do it the HTML5 way? Your users who are on cutting-edge browsers get to have fast, responsive interfaces without having to download a big chunk of JavaScript.

      Next, about markup being just about presenting data: that’s just not true. We’ve had form elements since the dawn of HTML, I don’t see anyone complaining about those.

      And there’s a difference between markup that is purely presentational (like blink) and markup that defines a mode of behavior or interaction (like details and summary). Did you really mean to say that you think the “collapsible box” UI is going to go the way of the blink tag? It’s a proven UI pattern in use just about everywhere on and off the Web.

  • Nichoal Bisop

    WOW! That Was Great!