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> <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
figcaption lives inside the
<figure> <img ... > (or
tableetc) <figcaption>A rabid unicorn goring a fairy.</figcaption> </figure>
If you want some history, continue reading. Otherwise, bye bye!
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
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
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.
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.
50 Responses on the article “Hello, summary and figcaption elements”
Thanks for the overview, much appreciated. I agree,
rubricwould indeed have been a welcome choice, for the esoteric amongst us.
What a wonderful idea. I like these elements a lot, as you say, a very common requirement.
Thanks for the news.
So can we assume the details element is finally ready? Or is it going to change again in the near future?
I assume that the details element is “ready” – although there is no implementation of it yet. Shelley Powers originally objected to using
summarybecause of potential confusion with table’s summary attribute, but dropped her objection.
(Ah, dreaming of JS and HTML5; wasn’t Joni Mitchell right when she sang ” dreams have lost some grandeur” in Circle Game http://www.youtube.com/watch?v=6XOV34vsjfg ?)
I expect to provide a sound argument for its removal.
How is “More Information” a good summary of anything? We’ve got all of these brilliant minds working on the future of the web and this is the best they can do?
I’m typically good at avoiding the writing of these specs. Don’t know how you guys keep up with it without screaming every day.
Source of details:
Colin: “more information” is my text, not in the spec. Although I agree, it’s not a summary.
Shelley: Thanks for the comment. I don’t see anything in the spec that says details requires scripting. However, Hixie’s justification of the details elementis ambiguous, as it doesn’t require extensive scripting:
Other than that, I’m glad the figcaption issue was finally settled, but damn, could they come up with an uglier element name ;-)
I see your point, Adam.
HTML5 also retains
target=blankon links to open new tabs/ windows.
Are those wrong? They’re not “pure”, I agree. And I’m with you in the separation of content and style. But is it useful to require scripting knowledge to implement behaviours which experience and expectation means are considered to be inherent in some kinds of structure?
Ok, so I can buy an argument that sometimes aiming for 100% purity is detrimental to the industry as whole as we’d be spending time arguing over semantics and ignoring that sometimes you just need something to work without writing 500 lines of code to do so. Hell, that’s mainly why XHTML2 died a slow death, it was two abstract and “pure” and not usable enough.
That said, I do think there are some thin lines between acceptable impurities and unacceptable ones. I’m okay with the :hover pseudo selector for anchor tags, I’m on the line for about it for other elements, and I’m okay that field focusing is extended to the label element for a given input. From a user experience perspective, I hate target=blank, because 99% of designers/developers never give me a warning that the link will open in a new window and if I want a link to open in a new window/tab then I’m going to right/scroll click to do so. But that’s a rant for a different conversation.
It could be non-scripted, or both non- and scripted. Or it could be up to the user agent (and wouldn’t that be ugly?)
Adam’s point is good: we’ve spent the last how many years getting people to understand about the separation of style and content, and now we’re throwing all of that good design practice by smooshing together behavior and content?
One can easily embrace the Details behavior using existing technologies, have it be accessible, can be styled, can be turned off by the user (without having to have a separate turn-off button), and will work in all of the modern browsers. You say oh that requires us to have a JS library. Something like jQuery is smaller than most people’s header graphic. And included by default by many CMS. I noticed you have it installed at your site. You could save bandwidth if you used the minified version.
As for designers not having to know how to code for adding this functionality, they don’t code this stuff anyway–there’s plug-ins and widgets and goodness knows what to do all of this. We’ve been managing to incorporate this functionality for a decade now. This is old school stuff.
And why do we stop at details, or popup menus (another interactive element)? We should have a tab element, and a slide element, and a help window element, a photo overlay element, and … once you open the door, you might as well kiss a clean HTML spec good-bye.
It’s time to bring a little discipline back into the HTML spec. Discipline and sound design practices.
As Adam says, to each their own…except that what we decide with an element like Details could redefine the scope of what we think of as HTML. An element like Details could re-define HTML to be less a markup language, and more the lingua franca for one specific class of user agents: browsers. To me, that would be an extremely bad mistake, because we’ll never have a stable environment in which to develop.
The spec may be making things exciting for those who love the wiz bang, on the edge stuff, but it promises to be a nightmare for the poor souls who have to create and support corporate and other business sites–not to mention a host of others who write the tools, write about the tech, create the libraries, provide the training, and so on. Believe it or not, a constantly changing environment is not a healthy environment in which to do business.
More, later, when I publish my change proposals. I’ll send you a link when they’re ready.
I don’t think details is any more likely to re-define html as a language for browsers than canvas, video is, or img was. Details does what it says on the tin; it gives more information that can be hidden away, but which is in the markup, accessible to crawlers, screenreaders and browsers that don’t understand the element. In my opinion, it’s a semantic element that has an associated behaviour.
It’s interesting you say “We should have a tab element, and a slide element, and a help window element ….”. We will have a sort of slide element with
It seems to me, purely from reading this article, that Shelley’s and Bruce’s arguments are equally valid depending on context.
“I don’t see how this element will make developing web applications that much simpler. This type of functionality is trivial with JS.”
Trivial for anyone experienced with JS yes – not everyone making webpages is though.
Both of these are examples of poor web development practice, arising from lack of foresight and/or development experience and knowledge of good coding standards.
So overall, Shelley is saying details is of no benefit to experienced web developers, Bruce is saying it will benefit inexperienced developers unfamiliar with JS – it’s inclusion is to cater for the lowest common denominator. Are we to take it then that details should only be used by inexperienced developers?
Bruce, you didn’t mention why your team weren’t able to develop with JS or CSS. I can’t address this specifically without knowing why your team wasn’t allowed to use CSS or JS.
lucideer, what I’m saying is that something like details pushes the scope of what is HTML, and does so in a way that could undermine the stability of HTML. As for experienced or not, you don’t need to be an experienced web developer (or even an inexperienced web developer) to use canned or packaged JS-enabled behaviors.
PS, when I mention “slide”, I’m talking about the JS behavior, such as sliding a menu in from the side, or sliding a collapsed accordion down — not a range of values. Sorry, my bad for not being more clear.
Shelley: crazy IT director wouldn’t allow “scripts” because of “security”. Crappy $250K CMS only allowed access to body element, stripped out script elements.
I think HTML needs such elements for standard widgets.
There are certain conventions for UI that are seen in all operating systems. Disclosure triangles for something like <details> is very common, and there’s no reason why that shouldn’t be a built-in part of html.
One concern too about the summary / detail idea is that it’s one specific case of a more general interaction: show more / show less. For example, I often create lists (UL / OL) where a few list items are visible, but via JS, the user can “show more.”
Though it’s less common, this interaction can also follow multiple steps of “more” — e.g., summary, some details, more details, even more details.
The good thing about leaving this to the scripting is that a wide variety of interactions can be accomodated in relation to a wide variety of HTML elements.
If this is being added to HTML, I think it’d be sensible to include the idea of levels or counts such that a series of elements could be grouped and understood as a progression from less to more detail. This added complexity might also justify the absence of a default behavior in the web browser, albeit a variety of user agents could liklely offer features to show less or more, e.g., the way the Safari web browser displays RSS feeds.
What you may want to consider doing is writing a counter-proposal for keeping the Details element, following the HTML WG policy. You don’t have to be a member of the group to write a counter-proposal. That way your concerns are heard by all team members when making a decision on whether to keep the element or not.
Andrew, I can honestly say I’ve never tried to emulate a select element using other elements and JS. At least, not one that can participate in the form, and also provide the dropdown and selection US. I can’t help thinking that it wouldn’t be a trivial task.
Shelley, because it was the worst CMS in the history of the world. (More accurately, configured by a bunch of baboons.
I like this. I can now update my script for HTML 5 behavior, which is a lot like Remy’s, but we developed the scripts independently. I didn’t update it for the
What about using the :target pseudo-class for expanding/collapsing?
What about doing it with css?
<a href="#myDiv">more info</a>
<div id="myDiv">here's the extra info</div>
“Trivial for anyone experienced with JS yes – not everyone making webpages is though”—@lucideer nails it
“you don’t need to be an experienced web developer (or even an inexperienced web developer) to use canned or packaged JS-enabled behaviors”—@Shelley
I think a majority of those making web pages would have no idea what you just said. For better or worse HTML was created to be simple enough that anyone can use it, and they are.
“An element like Details could re-define HTML to be less a markup language, and more the lingua franca for one specific class of user agents: browsers”—@Shelley
Can you speak to this more Shelley (or someone)? Is there something in the Details spec that makes it inaccessible or otherwise bad for non-browser agents? Or does this refer to something else?
peace – oli
I read this twice, looking for details of the “hello” element.
Ha ha! I ‘m with you there, Andy, I read the title and thought (somewhat recursively) “Hello, what’s this ‘hello’ element then?”
Question for you HTML5 doctor types.
Finger in the air time – how confident are you that these are now a done deal? I’m trying to specify markup for a project to use and am trying to encourange HTML5 elements where possible and where absolutely safe. I’m *only* doing it for elements that would currently be marked up as a div, so there’s no danger of me swapping out a semantic HTML element for an HTML5 element that may later be pulled, so on that basis I’m playing it safe.
So far, I’ve only suggested using , and elements, but these (well, figure) would be really good for marking up some illustrative content, e.g. graphs. I’d like to get a feel for how stable this might be, if that’s at all possible?
Dammit, forgot that markup would be stripped. Last paragraph should begin ‘So far, I’ve only suggested using header, footer and section elements’
Bruce, I’ve been mulling this over since reading your post a day or two back and I think I’m siding with Shelley on this I’m afraid.
A details element would mean we are marking up content (as in actual page content – not just form elements) for functionality rather than semantics. Personally I don’t feel the benefits of the added functionality outweigh the added confusion to the meaning of the document’s markup.
Also what happens when you print a details element? should the content be visible or hidden? What if I want it closed by default on screen but open when printed or vice-versa? This is fairly straightforward with some basic js and css. I’m guessing this is the sort of issue Shelley was refering to when she suggested this wasn’t a user-agent agnostic idea.
“lucideer, what I’m saying is that something like details pushes the scope of what is HTML”
It pushes the scope of what HTML is to experienced developers – the question is, who is <details> aimed at? Most inexperienced developers have never used <ins> or <del>, or if they have they’ve put them in the wrong place, the idea that they’ll be learning off a whole host of new elements and their intended usage seems fairly laughable.
Inexperienced developers will surely take details and use it in any completely un-semantic context where they want something collapsible – like wrapping entire posts/articles in <details>.
My overall question above was – who is <details> for? If it’s for the experienced – they don’t need it, and it is superfluous and redundant. If it’s for the inexperienced, will they use it as intended? Will it be another <marquee> (yes I know marquee is technically part of HTML5 too)?
@Ian – HTML in blog comments is always a problem, since some accept it, some don;t< So much for standards!
@Peter – I was thinking along the same lines. It's a presentational matter; and presentation is supposed to go in CSS, not mark-up. What's wrong (other than impatience) with proposing a new style, along the lines of
[p style="collapse:yes;"]Hide this until I tell my bowser not to; look at the print style sheet for further guidance[/p]
Another advantage is that user could set a local, important style to "collapse:no", by default.
Oll, it sounds like you’re also asking what lucideer is asking: who is this for?
lucideer, you mentioned about Marquee, but there’s also blink, and animated GIFs. How long were we using animated GIFs before realizing that some could trigger seizures? Then we had Flash, and next thing we knew, we had entire sites made from Flash–and completely inaccessible.
We had the capability, without knowing the consequences.
Lot of questions. Good ones, too.
Anyway, I have to have my change proposal to the HTML WG the 8th of March, and my next batch the 31st. Just because I’m putting out change proposals, though, doesn’t mean anything will change. But, hopefully, the change proposals will start up discussions such as these, because most of the discussions about Details have been on browser implementations, and not necessarily focused on use case.
Ian, you’re probably safe with article, section, and footer. I can say that there are change proposals in the works for Figure, aside, progress, meter, and several others.
[…] This post was mentioned on Twitter by Boagworld Links, bruce lawson, Standardistas, Leon Paternoster, Remy Sharp and others. Remy Sharp said: Updated html5.js in accordance with http://bit.ly/cp63AW available here: http://bit.ly/MbS5v […]
Jethro Larson asks “What about doing it with css?”.
Because it has no semantics; it’s not clear that the div is “details” for something else. (It’s like a footnote, which is still not properly possible in HTML; it’s not clear what’s related to what).
Shelley, you said “lucideer, you mentioned about Marquee, but there’s also blink, and animated GIFs. How long were we using animated GIFs before realizing that some could trigger seizures? Then we had Flash, and next thing we knew, we had entire sites made from Flash–and completely inaccessible.
We had the capability, without knowing the consequences.”
Are you suggesting that we shouldn’t add things to the spec because, if used badly, they might be dangerous/ misused?
Your point about printing is well-made. Thanks. I’ve asked the WHATWG for clarification. My feeling is that the contents of the details element should be printed regardless of the boolean attribute (because a print stylesheet can’t change markup).
Hixie replied “Generally speaking, browser vendors have found that people expect their “print” features to just print what’s on the screen. However, I’m certainly open to changing the spec on this if the browser vendors feel the spec should change”.
Bruce, I’m saying that we have to understand who the element is for, and the use cases for the element, first.
We shouldn’t be adding things into HTML because of some coolness factor, or a browser developer or spec writer thought it would be neat.
Everything that goes into the next version of HTML should be questioned, its impact understood, backed by relevant use cases, a solid understanding of the audience for the change, and rigorous testing to ensure that the addition won’t cause confusion or break existing web pages.
This process may come off dull and uninteresting, but HTML is the foundation on which everything is built: we can’t turn it into an ever changing set of tinker toys.
There’s nothing “semantic” about an expando section. It’s nothing more than a way of compressing page space. It’s no different than the use of tabs, but we’re not adding these to the spec. Or at least, not yet (now that we’ve opened the door, who knows). Or overlay elements, or popups, or any of the other JS/CSS enabled behaviors we’ve used to manage page space.
In fact, to return to Peter’s note about print (or other instances where JS and JS behaviors are turned off), if the details element was semantically viable, its state should be preserved in the printed result, but I can’t imagine anyone who would want it to be.
You might want to consider bringing this up in the W3C, because that’s where the discussion on the change proposal will be. Or not, your choice, but that is where the discussion will occur.
Oh and PS, as for Hixie’s statement:
“Hixie replied “Generally speaking, browser vendors have found that people expect their “print” features to just print what’s on the screen. However, I’m certainly open to changing the spec on this if the browser vendors feel the spec should change”.”
The web, past, present, or future, does not belong only to Opera, Apple, Mozilla, Microsoft, and Google.
“Are you suggesting that we shouldn’t add things to the spec because, if used badly, they might be dangerous/ misused?”
I would think things shouldn’t be added to the spec if it’s reasonable to assume they will be used badly often enough to degrade the overall quality/usabilty of websites by a greater amount than any potential benefit.
@Shelley, on printing.
I would imagine the ideal behaviour, if details is kept, would be to print details in it’s current state. That would be the expected behaviour I would guess.
If I read the spec correctly, the summary tag is always visible, and everything else in the details tag is only visible when the open attribute is set. Pillar Magazine Example
Assuming this is correct, I have some comments about the summary tag. The content model for the summary tag is phrasing content, which means it can only contain other phrasing content.
What if you want to have more complex info in the summary. As an example, I’m thinking about the Facebook Settings page. They have a setting heading, description and current value. When you show the “details” area, you see the edit fields (like the Pillar Magazine example, BUT some of the “summary” is not visible.
I can’t see this working with summary as currently defined unless, summary is not phrasing content or if other child elements of the details element could be visible when it is “closed.”
my reading is same as yours. But I think that they way details is currently specified is enough for the 80% of authorial needs.
Do you have any document shows logic order of html5 tags? I mean shows what is the best practice using tags within each other.
For example, I saw a developer is using <section first and then <article but others use vice versa.
Probably, I misunderstand the intent of <figure> and should be using <section> instead, as I see the W3 validator rejects what I’m trying:
<a href=”http://[…rest of URL…]”>
<img […stuff…] >
The W3 validator wants an <a> for the <img> and a separate <a> inside the <figcaption>.
@fjpoblam – The figcaption needs to be a direct child of figure. You can put the <a> tags outside the <figure> tags to achieve what you’re trying to do in a valid way.
[…] two new HTML elements: summary and figcaption were added to HTML5 project. The creation of these new elements to the […]
[…] readers will know that a new element was recently introduced, namely <figcaption>. Who knows if it’ll stick, but for now here’s what the spec […]
Will the implementation include an automatic scroll down when the content is not visible in the viewport (only if the summary+details max height < viewport height)?
Anon- it depends on the implementation. Nothing like this is required or forbidden by the specification.
[…] Hello, summary and figcaption elements […]
Wow, it all started at least four years ago that everybody was talking about hiding/showing content. Feel like I’ve been living in a cave and wish I had read this article earlier :)
I thought about it as well, only I tried incorporating the existing elements for such tasks. The final variant that I had was to use
<dd>to markup the widget, summary and additional (hidden) info respectively. Although to get some more functionality I decided to use the
<a>tag as well. Using a combination of the html
tabindexattribute (to aid keyboard navigation) and some JS (like opening, preventing the hash change (if unneeded) and other things) we can get the same result. It is described in more details (pun) in my article on anchor tags versus buttons. There I take an interactive FAQ section (a simple accordion) as an example which resulted in this code.
<dt><a href="#answer1" tabindex="1">Question 1</a></dt>
<dd id="answer1">Answer 1</dd>
<dt><a href="#answer2" tabindex="1">Question 2</a></dt>
<dd id="answer2">Answer 2</dd>
<dt><a href="#answer3" tabindex="1">Question 3</a></dt>
<dd id="answer3">Answer 3</dd>
Please feel free to give a comment whether it’s OK either here or in a comment to my blog post.
Leave a Reply to Shelley