Hello, summary and figcaption elements

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:

46 Responses to “ Hello, summary and figcaption elements ”

Comment by Christopher Murphy at February 1st, 2010 at 11:30 am

Thanks for the overview, much appreciated. I agree, rubric would indeed have been a welcome choice, for the esoteric amongst us.

Comment by Ian Devlin at February 1st, 2010 at 12:03 pm

What a wonderful idea. I like these elements a lot, as you say, a very common requirement.

Comment by Bartek Stankowski at February 1st, 2010 at 12:28 pm

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?

Comment by Bruce Lawson at February 1st, 2010 at 12:38 pm

I assume that the details element is “ready” – although there is no implementation of it yet. Shelley Powers originally objected to using summary because of potential confusion with table’s summary attribute, but dropped her objection.

It’s fakable with JavaScript now; Remy had a demo, I think – though I can’t find it. Maybe I’m dreaming.

(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 ?)

Comment by Shelley at February 1st, 2010 at 1:07 pm

I was mistaken with the Details element. I assumed it was a declarative animation, since why else would you create an element that does nothing special? However, after closer look at the spec, I believe it doesn’t animate outside of JS. You still have to have JavaScript to expand and collapse the element.

I expect to provide a sound argument for its removal.

Comment by Colin at February 1st, 2010 at 1:12 pm

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.

Comment by Remy Sharp at February 1st, 2010 at 1:20 pm

I’ve updated my demo code showing how details would work – implemented with JavaScript in a way that should be transparent to the author (though note that it needs to run when the doc is finished – i.e. before the closing body tag):

http://remysharp.com/demo/details-with-js.html

Source of details:

http://remysharp.com/demo/details.js

Comment by Bruce Lawson at February 1st, 2010 at 1:20 pm

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:

The
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.

Comment by Adam Hobson at February 1st, 2010 at 2:08 pm

I’m not sure I buy your argument for the details element. Basically it boils down to designers who aren’t good at development are bad at implementing javascript so lets give them an HTML element to fake it. I could make the same argument for the font tag, CSS is really complicated and now we can give bad developers an easy way to change text in HTML really easy.

But we all know that style should be separate from the content, which is why we have CSS and HTML. But what we often forget is that the functionality of the site, it’s actions and events, should also be separate from the content, which is why actions like hiding and collapsing an element should be done via Javascript and not via the HTML which should be used for content only. If developers implementing an entire library to just do collapsing/expanding is a problem, then lets fix that with education, not an element that breaks the HTML is for content only mold. Besides, since this element now does make it easy to implement expand/collapse without Javascript, I’m definitely going to predict that many a developer will use it improperly and non-semantically just because they want a cheap and easy expand/collapse.

Other than that, I’m glad the figcaption issue was finally settled, but damn, could they come up with an uglier element name

Comment by Bruce Lawson at February 1st, 2010 at 2:19 pm

I see your point, Adam.

You can make the same argument that CSS should not have implemented a :hover pseudo-class, because JavaScript should (and can) do that. (See Jeremy Keith’s :hover Considered Harmful).

Or you could argue that the HTML4 specification had no right to say that focussing on a form label should pass that focus on to the associated input field, because that can be done in JavaScript.

HTML5 also retains target=blank on 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?

Comment by Adam Hobson at February 1st, 2010 at 3:37 pm

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.

I just feel that expand/collapse functionality is going a little too far to implement in solely HTML with no Javascript. I think that once this is supported by most browsers, mainly IE, it will become one of the most abused elements, as bad designers and developers will use it to implement all of their expand/collapse behaviors regardless of their semantic intentions.

We all have a line in what we consider acceptably impure, and I guess this just crossing my line, but not yours. To each his own, but I’m just not comfortable with this behavior sans-Javascript.

Comment by Shelley at February 1st, 2010 at 3:38 pm

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.

Comment by Shelley at February 1st, 2010 at 3:50 pm

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.

Comment by Bruce Lawson at February 1st, 2010 at 4:08 pm

Interesting that you mention corporates, Shelley. My wish for the details element comes from the time when I worked at a big public sector organisation 2004-2008. for the first three years, we Webteam had no access to CSS or to JavaScript. There was no way for us to add libraries to make rel=”external” on links (instead of target=”_blank”) work or to mimic a details element.

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 input type="range". All the new forms attributes (and their validation) can be achieved in JavaScript. But I still think it;s better to fold them into the browser. It’s easier for the developer, gives a consistent user experience for the customer.

Comment by lucideer at February 1st, 2010 at 4:31 pm

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.

“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,”
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?

Comment by Shelley at February 1st, 2010 at 4:51 pm

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.

Comment by Shelley at February 1st, 2010 at 4:55 pm

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.

Comment by Bruce Lawson at February 1st, 2010 at 4:59 pm

Shelley: crazy IT director wouldn’t allow “scripts” because of “security”. Crappy $250K CMS only allowed access to body element, stripped out script elements.

Comment by Andrew Vit at February 1st, 2010 at 5:16 pm

I think HTML needs such elements for standard widgets.

I would compare <details> to a form input element, something like <select>, which is also “trivial” to do in Javascript, and many sites do so in order to include block-level content (such as images) inside the select options.

How far do we need to go in the separation of content and behaviour and style before it becomes absurd? I mean, a text input can be done as a plain <div> too, like you see with rich text editors written in javascript. Same with checkboxes, radio buttons, etc. If you agree with the argument to remove <details> then why do these have a right to exist if everything could be handled with javascript instead?

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.

Comment by Jay Fienberg at February 1st, 2010 at 5:36 pm

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.

Comment by Shelley at February 1st, 2010 at 6:55 pm

Bruce, I can kind of understand about JavaScript, but not concerns about CSS. The CMS didn’t allow template access? Or incorporate the concept of extended blocks, modules, or widgets? Sounds like college education software.

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.

Comment by Bruce Lawson at February 1st, 2010 at 7:08 pm

Shelley, because it was the worst CMS in the history of the world. (More accurately, configured by a bunch of baboons.

Comment by Aleksey at February 1st, 2010 at 8:02 pm

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 <dt> and <dd>.

Comment by Ken at February 2nd, 2010 at 5:18 pm

As the web matures and grows ever more sophisticated, the minimum bar for “basic behavior” has increased. (Years ago, the only basic behavior was click a link, go to new content.) Its only pragmatic that this “basic behavior” be included in the “content” area of separation. Advanced behavior (that which isn’t below the bar) should fall under the Separation of Concerns. Its only left to argue where that bar is, what is now basic and what is advanced, not whether all behavior should be segregated. The web should still function (to some extent) for users that don’t have JavaScript enabled. Basic should be what behavior is fairly Standard by now, and advanced be everything else custom.

Comment by Anders at February 2nd, 2010 at 7:34 pm

Reinstating this element would be advantageous to developers, who wouldn’t need to learn JS to accomplish a common task

What about using the :target pseudo-class for expanding/collapsing?

Comment by jethro larson at February 3rd, 2010 at 12:33 am

What about doing it with css?
<style> #myDiv{display:none} #myDiv:target{display:block;} </style> <a href="#myDiv">more info</a> <div id="myDiv">here's the extra info</div>

Comment by Oli at February 3rd, 2010 at 5:18 am

“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

Comment by Andy Mabbett at February 3rd, 2010 at 2:44 pm

I read this twice, looking for details of the “hello” element.

Comment by Ian Lloyd at February 3rd, 2010 at 3:26 pm

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?

Comment by Ian Lloyd at February 3rd, 2010 at 3:27 pm

Dammit, forgot that markup would be stripped. Last paragraph should begin ‘So far, I’ve only suggested using header, footer and section elements’

Comment by Peter at February 3rd, 2010 at 3:33 pm

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.

Comment by lucideer at February 3rd, 2010 at 5:44 pm

@shelley
“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)?

Comment by Andy Mabbett at February 3rd, 2010 at 5:45 pm

@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.

Comment by Shelley at February 4th, 2010 at 4:00 am

Oll, it sounds like you’re also asking what lucideer is asking: who is this for?

Experienced folks don’t need it, and I’m not sure people who are inexperienced need it either. Implementing something like an expando section into a web page design is not something you just throw into the page. Then there are those issues, such as what Peter mentioned: what happens when the page is printed out? Currently, the print capability in most web sites strips out Flash, much of the CSS, and the JavaScript. Where does Details fit into all of this?

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.

Comment by Tweets that mention Hello, summary and figcaption elements | HTML5 Doctor -- Topsy.com at February 4th, 2010 at 8:22 am

[...] 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 [...]

Comment by Bruce Lawson at February 4th, 2010 at 10:35 am

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”.

Comment by Shelley at February 4th, 2010 at 1:17 pm

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.

I checked back into the history of Details, and can never find where anyone specifically asked for this element. Definitely no one from the HTML authoring community asked for it, at least, as far as I can discover to this point. So what we’re doing, then, is providing this brand new element, and also introducing declarative animations into an environment that isn’t necessarily set up to handle such animations. At least, not handle declarative animations, cleanly. And we’re doing so because someone had an idea that the triangle expando sections should be markup, rather than CSS and JavaScript.

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.

Comment by Shelley at February 4th, 2010 at 1:21 pm

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.

Comment by lucideer at February 4th, 2010 at 6:51 pm

“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.

Comment by JoshS at February 5th, 2010 at 8:44 pm

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.”

Comment by Bruce Lawson at February 8th, 2010 at 9:34 am

JoshS

my reading is same as yours. But I think that they way details is currently specified is enough for the 80% of authorial needs.

Comment by bractus at February 18th, 2010 at 5:33 pm

Hi Bruce

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.

Comment by fjpoblam at February 24th, 2010 at 4:12 pm

Probably, I misunderstand the intent of <figure> and should be using <section> instead, as I see the W3 validator rejects what I’m trying:

The W3 validator wants an <a> for the <img> and a separate <a> inside the <figcaption>.

Comment by Alohci at February 25th, 2010 at 12:43 am

@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.

Comment by New HTML5 elements: summary & figcaption - Gurushala at February 28th, 2010 at 12:29 am

[...] two new HTML elements: summary and figcaption were added to HTML5 project. The creation of these new elements to the [...]

Comment by Adam Boarman's dot com » Blog Archive » The figure & figcaption elements at June 24th, 2010 at 9:14 am

[...] 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 [...]

HTML5 Doctor

helping you implement HTML5 today

Hello, summary and figcaption elements

Related Posts:

Share and Save: