<figure>
<a href=”http://[...rest of URL...]“>
<img [...stuff...] >
<figcaption>
[text]
</figcaption>
</a>
</figure>

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

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.

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

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

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

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

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.