<a href="/">
<hgroup>
  <h1>Title</h1>
  <h2>Sub Title</h2>
</hgroup>
</a>

<a href="#"><img alt="Bob's homepage">Bob Smith</a>

Your Questions #15 originally appeared on HTML5 Doctor on January 14, 2011.

Offline viewing on requests

Johan asked:

It is possible to let Firefox 3.5/3.6 save a page for offline viewing with the manifest file?
In that case Firefox asks for permission to save the site the same second you arrive – not very user-friendly.

Is it possible to send the save-it-locally request via Javascript on a click?

Basically I want a link/button which will fire the request – and not on document load.

While it isn’t possible to make Firefox 3.5/3.6 save a page for offline viewing with the manifest file, there is a way to do this. It all depends on how you write the “save-it-locally request” code. You have two options:

1. If you want to store an arbitrary document that is not explicitly listed in your manifest, you could run an Ajax request for that document and store its contents in localStorage. When you want to view that document, load it from localStorage and overlay it on the existing page.
2. Dynamically manage a manifest file for individual users, so that if a user requests a new file that isn’t in their manifest, register this on the server side and add it to the manifest — which is bespoke to this specific user — on the fly.

I’m not sure what you’re seeing with regards to the permissions error. When I test the manifest (offline **cache**), it doesn’t ask twice.

Note: you asked about Firefox 3.5 — the offline manifest doesn’t work properly at all in this version.

Thanks, Remy

Question about dragging

Marc asked:

Evening,

I’m trying to get my head around the drag and drop (DnD) possibilities of HTML5. I have a “simple” task: Read the content of a XML file, using JavaScript, and do some manipulations of he XML. Without the use of server side scripts.

I tried my way with Google, but apart from people complaining about the DnD specs, I wasn’t able to find much insightful informations.

Can you point me toward resources to understand the DnD possibilities of HTML5?

Thank you Doctor, a French canadian HTML5 fan ;)

Absolutely! There’s actually an HTML5 Doctor article covering native drag-and-drop. It also includes links for further reading and related posts (such as accessibility experiments).

I hope that helps.

Cheers, Remy

About the href on any element

Luan asked:

I’ve heard a long ago that href would work in any tag, such as a <p href="..."> or a h1, even a div and others… but I don’t see anything about this in the last days. Do you know if this is going to work?

That was in XHTML2 (on which the W3C have now stopped work).

The HTML5 equivalent is to wrap an <a href="..."> around the other tags. It’s called block-level linking, and we’ve written an article about it.

Cheers, Bruce

W3C Validator for the <figure> element

Fjpoblam asked:

I have a (prospective) structure containing 8 figures: each an image with a caption. My goal is an image gallery, each image clickable toward an individual htm file containing a slide show. (In html4 I structured each “figure” as a div: figure seemed ideal for the task.)

Problem is, I tried to follow the *validator* hint with a dd for the image and a dt for the caption (each surrounded by an a). Upon doing so, the validator pops up an error. When I try a straight image with a legend, it is also rejected for want of a dd and an optional dt.

What gives? Do you have a hint? Or better, simply, point me doofus to the correct doc so’s you’ll “teach a man to fish”.

I’m not sure if the validator is up to date or not, but you shouldn’t be using <dd>/<dt> in <figure> anymore. Please use <figcaption>.

See our article on the <figure> and <figcaption> elements for more.

Also see our glossary for more examples.

Cheers, Rich

Headings

Thomas asked:

Dear Doctors,

you covered the new header tag in an article. The header tag should contain a heading element, like h1-6. So far so good, but how do I structure my headings further on. E.g. I’ve got this:

<article>
	<header>
		<h1>My major heading</h1>
		<h2>Subheading</h2>
		Abstract text...
	</header>
	... lorem ipsum ....
	<hX>Heading within my article</hX>
	... dolor sit amet ...
	<hX+1>Subheading in my article</hX+1>
</article>

Which heading-level would be appropriate in my example? h1 because it starts again? or h3 because it continues?

Thank you

If the first <hX> is a new subheading and not related to the <h2> already there, then <hX> would be an <h2>. Then <hX+1> would be an <h3> if it is a subheading of the above <h2>.

However, if you’re splitting the article into sections, then you could use an <h1> each time. See our article on the section element for more.

Thanks, Tom

Got a question for us?

That wraps up this round of questions! If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.

Your Questions Answered 9 originally appeared on HTML5 Doctor on May 14, 2010.

The <figure> element

The <figure> element is intended to be used in conjunction with the <figcaption> element to mark up diagrams, illustrations, photos, and code examples (among other things). The spec says this about <figure>:

The figure element represents a unit of content, optionally with a caption, that is self-contained, that is typically referenced as a single unit from the main flow of the document, and that can be moved away from the main flow of the document without affecting the document’s meaning.

The <figcaption> element

The <figcaption> element has been the subject of much debate. The spec initially wanted to repurpose <legend> rather than introduce a new element. Other suggestions included <label>, <caption>, <p> or the <h1>–<h6> elements. <legend> was changed, so we then used a combination of <dt> and <dd> inside <figure> at Jeremy’s suggestion. Most of these suggestions failed since there was no backwards compatibility for styling with CSS.

Regular 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 says about <figcaption>:

The figcaption element represents a caption or legend for a figure.

The <figcaption> element is optional and can appear before or after the content within the <figure>. Only one <figcaption> element may be nested within a <figure>, although the <figure> element itself may contain multiple other child elements (e.g., <img> or <code>).

Using <figure> and <figcaption>

So we’ve seen what the spec says about these elements. How do we use them? Let’s look at some examples.

Figure with an image

An image within a <figure> element without a caption:

Here’s the code for that:

<figure>
  <img src="/orang-utan.jpg" alt="Baby Orang Utan hanging from a rope">
</figure>

Figure with an image and caption

An image within a <figure> element with an explanatory caption:

and the code that we used:

<figure>
  <img src="/macaque.jpg" alt="Macaque in the trees">
  <figcaption>A cheeky macaque, Lower Kintaganban River, Borneo. Original by <a href="http://www.flickr.com/photos/rclark/">Richard Clark</a></figcaption>
</figure>

A figure with multiple images

Nesting multiple images within one <figure> element with a single caption:

The code:

<figure>
  <img src="/kookaburra.jpg" alt="Kooaburra">
  <img src="/pelican.jpg" alt="Pelican stood on the beach">
  <img src="/lorikeet.jpg" alt="Cheeky looking Rainbow Lorikeet">
  <figcaption>Australian Birds. From left to right, Kookburra, Pelican and Rainbow Lorikeet. Originals by <a href="http://www.flickr.com/photos/rclark/">Richard Clark</a></figcaption>
</figure>

Figure with a code block

The <figure> element may also be used for code examples:

Here’s the code for that:

<figure>
<blockquote><p><code>&lt;small&gt;&lt;a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/"&gt;Creative Commons Attribution Share-alike license&lt;/a&gt;&lt;/small&gt;</code></p></blockquote>
<figcaption>Using <code>&lt;small&gt;</code> around a <a href="http://creativecommons.org/choose/" title="Choose a License">Creative Commons license</a> link with <code>rel="license"</code></figcaption>
</figure>

Differences between <figure> and <aside>

We covered <aside> in an earlier article, but it is important to note the difference between the two. You should choose between <aside> or <figure> by asking yourself if the content is essential to understanding the section:

• If the content is simply related and not essential, use <aside>.
• If the content is essential but its position in the flow of content isn’t important, use <figure>.

Having said that, if its position relates to previous and subsequent content, use a more appropriate element — e.g., a <div>, a plain old <img>, a <blockquote>, or possibly even <canvas>, depending on its content.

Don’t stop there!

No need to constrain your <figure>s to images and code examples. Other content suitable for use in <figure> includes audio, video, charts (perhaps using <canvas> or <svg>), poems, or tables of statistics.

It may not always be appropriate to use the <figure> element, though. For example, a graphic banner should not be marked up with <figure>. Instead, simply use the <img> element.

Summary

As we’ve illustrated in this article, there are a lot of possibilities for the <figure> element. Just remember to make sure it’s the most appropriate element for the job. But you already do that for all your markup, right? :)

The figure & figcaption elements originally appeared on HTML5 Doctor on April 13, 2010.

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

Hello, summary and figcaption elements originally appeared on HTML5 Doctor on February 1, 2010.