The HTML5 <details> element is currently not natively supported in any browser natively supported in Chrome 12 and up. This makes it a little hard to guess how exactly this new element will behave, but reading the spec gives us a pretty good idea. What’s clear is the following:
A
detailselement represents a disclosure widget from which the user can obtain additional information or controls.
This information is hidden by default. It can be made visible by adding the boolean open attribute to the <details> element. After that, the user can toggle the visibility by clicking the <summary>.
The
summaryelement represents a summary, caption, or legend for the rest of the contents of thesummaryelement’s parentdetailselement, if any. If there is no childsummaryelement, the user agent should provide its own legend (e.g. “Details”).
Note that while the spec describes what should happen in case the <summary> element is omitted, it’s still invalid to do so.
It appears to me the summary element should be keyboard accessible as well. You should be able to tab through all different interactive elements (such as links, buttons, form elements), and guess what — summary is one of them. After focusing it with the keyboard, it would be nice to just hit Enter or Space to toggle visibility of the <details> element’s contents. The HTML spec doesn’t say anything about this matter, though.
Note that details got included into HTML5 because it’s such a common behavior for web sites and apps — so common it should be possible to do this without the need for additional scripting to make the whole thing work. However, HTML5 is still a work in progress. The <details> element is not even implemented yet. In the meantime, it’s important to provide a fallback/polyfill when using new features that aren’t (fully) supported cross-browser.
CSS, JavaScript, and jQuery to the rescue
Luckily it’s pretty easy to make <details> work cross-browser using a combination of CSS, (plain) JavaScript, and jQuery.
Detecting native <details> support with JavaScript
First, let’s add class="no-details" to the html element if JavaScript is enabled and the browser does not support <details> natively. This will allow us to write CSS specifically for the occasion our scripts will actually be executed. Adding the class can be done in various ways, but the one I prefer is by placing the following snippet in the <head>:
<script>
// Don’t use this! See note below.
if (!('open' in document.createElement('details'))) {
document.documentElement.className += ' no-details';
}
</script>Update: Chrome 10 recognizes the open attribute for <details> elements, even though it doesn’t support rendering the element correctly yet. This means the above feature detection method has become unreliable. I’ve now created a more robust feature test for <details>/<summary> support:
var isDetailsSupported = (function(doc) {
var el = doc.createElement('details');
var fake;
var root;
var diff;
if (!('open' in el)) {
return false;
}
root = doc.body || (function() {
var de = doc.documentElement;
fake = true;
return de.insertBefore(doc.createElement('body'), de.firstElementChild || de.firstChild);
}());
el.innerHTML = '<summary>a</summary>b';
el.style.display = 'block';
root.appendChild(el);
diff = el.offsetHeight;
el.open = true;
diff = diff != el.offsetHeight;
root.removeChild(el);
if (fake) {
root.parentNode.removeChild(root);
}
return diff;
}(document));So after that, we can just do something like:
<script>
if (!isDetailsSupported) {
document.documentElement.className += ' no-details';
}
</script>Note that Modernizr currently doesn’t detect <details> support. I’m sure it will be included soon. Update: My feature test for <details> is now included in the Modernizr repository.
Adding some basic style
Now we can add some fundamental styling to the details element and its children.
/* Default browser styles for <details> and <summary> */
details { display: block; }
summary { display: list-item; }
/* The following styles will only get applied if JavaScript is enabled and <details> is not natively supported */
/* Add focus styles (for keyboard accessibility) */
.no-details summary:hover, .no-details summary:focus { background: #ddd; }
/* The following styles are not really needed, since the jQuery script takes care of hiding/displaying the elements. */
/* However, we’re still gonna use CSS as well to prevent FOUC in browsers that understand these selectors. */
/* Remember: by default (and probably most of the time), the contents of the <details> element are hidden. */
/* Hide all direct descendants of every <details> element */
/* Note that IE6 doesn’t support the child selector; we’ll work around that using jQuery later */
.no-details details > * { display: none; }
/* Make sure summary remains visible */
.no-details details summary { display: list-item; }
/* Apply a pointer cursor upon hover to indicate it’s a clickable element. These styles can be applied regardless of whether the fallback is needed */
summary { cursor: pointer; }The jQuery magic
I’ve written a jQuery plugin that makes it very easy to emulate <details>/<summary> in browsers that don’t support these elements yet. Check out the code on GitHub.
After including jQuery and the plugin, you can just write something like this to emulate <details>/<summary> where necessary:
$('details').details();The result of the feature test is stored in $.fn.details.support, which will be true if the browser natively supports <details> and <summary>, and false otherwise:
// Conditionally add a classname to the `<html>` element, based on native support
$('html').addClass($.fn.details.support ? 'details' : 'no-details');The plugin will also add the appropriate ARIA annotations for optimal accessibility. This will be done even in browsers that natively support <details>, just in case.
Demo
I’ve put up a demo page with heavily commented source code as well. Enjoy!
This fallback works in all A-grade browsers, including IE6. It will only be executed if the <details> element is not natively supported in the browser. If it isn’t, and JavaScript is disabled, all elements will still be visible to the user.
Note that you should never pull in a 25 KiB JavaScript library just to make <details> work — this solution should only be used in cases where jQuery is used already. Of course it’s possible to rewrite this as plain JavaScript, but I’ll leave that as an exercise to the reader ;)
Comments
riddle wrote on :
Remy Sharp wrote on :
Mathias wrote on :
Shelley wrote on :
Mathias wrote on :
Shelley wrote on :
Mathias wrote on :
Summary goes here
Shelley wrote on :
Benjamin Hawkes-Lewis wrote on :
Shelley wrote on :
Benjamin Hawkes-Lewis wrote on :
Ryan wrote on :
Mathias wrote on :
Steve wrote on :
Bramus! wrote on :
Webstandard-Blog wrote on :
Mathias wrote on :
anon wrote on :
Cam wrote on :
Mathias wrote on :
Cam wrote on :
Mathias wrote on :
Cam wrote on :
Brett Widmann wrote on :
Prestaul wrote on :
Mathias wrote on :
: rendering"). Check out [comment #48](https://bugs.webkit.org/show_bug.cgi?id=51071#c48) which I wrote a couple of days ago: > As long as this patch isn’t landed, WebKit false positives on the feature test for native `` support (without actually supporting it) […]
As long as there’s no stable browser release with this issue, I don’t think we should start looking for a more complicated feature test.
Jonathan wrote on :
Mathias wrote on :
foo
bar`), then checking the height again to see if it changed. If it did, `` is likely to be supported.
David Mark wrote on :
David Mark wrote on :
Mathias wrote on :
` [just landed in WebKit](http://trac.webkit.org/changeset/81035). `
` elements aren’t keyboard-navigable yet, but accessibility issues will be handled in future patches. What’s exciting is that the native behavior looks almost identical to the demo page :)
Rudie wrote on :
Mathias wrote on :
Cam wrote on :
Mathias wrote on :
a
b'; el.style.display = 'block'; root.appendChild(el); diff = el.offsetHeight; el.open = true; diff = diff != el.offsetHeight; root.removeChild(el); if (fake) { root.parentNode.removeChild(root); } return diff; }(document)); ``` The `isDetailsSupported` variable will be `true` if ``, treat these elements as inline elements (`display: inline`). If we don’t override that, there’s no way to get reliable results for the height in all browsers. Secondly, this makes sure the test will still return the correct result when the document has `details { display: none; }` in its style sheet. (Edge case, but still.)
Mark wrote on :
Michael A. Peters wrote on :
Carlos Ramirez III wrote on :
Stephan Sokolow wrote on :
Daniel wrote on :