HTML5 Doctor » figure

Your Questions Answered 9

Richard Clark — Fri, 14 May 2010 14:15:57 +0000

The Doctor is in with another round of patient questions about HTML5. This week, we’ll cover offline viewing on requests, the drag-and-drop API, using href on any element, the

element, and headings.

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:

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.
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
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 around the other tags. It’s called block-level linking, and we’ve written an article about it.

Cheers, Bruce

W3C Validator for the
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

anymore. Please use

See our article on the

and

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:
	
		My major heading
		Subheading
		Abstract text...
	
	... lorem ipsum ....
	Heading within my article
	... dolor sit amet ...
	Subheading in my 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 is a new subheading and not related to the

already there, then would be an
. Then would be an
if it is a subheading of the above
.

However, if you’re splitting the article into sections, then you could use an
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.

Related Posts:

Your Questions Answered #10

Your Questions Answered #7

Your Questions Answered #4

Your Questions Answered #3

Your Questions Answered #8

Share and Save:

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

The figure & figcaption elements

Richard Clark — Tue, 13 Apr 2010 13:45:20 +0000

In traditional printed material like books and magazines, an image, chart, or code example would be accompanied by a caption. Before now, we didn’t have a way of semantically marking up this sort of content directly in our HTML, instead resorting to CSS class names. HTML5 hopes to solve that problem by introducing the

and

elements. Let’s explore!

The
element

The

element is intended to be used in conjunction with the

element to mark up diagrams, illustrations, photos, and code examples (among other things). The spec says this about

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

The
element

The

element has been the subject of much debate. The spec initially wanted to repurpose rather than introduce a new element. Other suggestions included , ,

or the

–

elements. was changed, so we then used a combination of

and

inside

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

. Who knows if it’ll stick, but for now here’s what the spec says about

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

The

element is optional and can appear before or after the content within the

. Only one

element may be nested within a

, although the

element itself may contain multiple other child elements (e.g., or

).

Using  and 

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 
 element without a caption:



Here’s the code for that:


  


Figure with an image and caption

An image within a 
 element with an explanatory caption:

A cheeky macaque, Lower Kintaganban River, Borneo. Original by Richard Clark


and the code that we used:


  
  A cheeky macaque, Lower Kintaganban River, Borneo. Original by Richard Clark


A figure with multiple images

Nesting multiple images within one 
 element with a single caption:

Australian Birds. From left to right, Kookburra, Pelican and Rainbow Lorikeet.
Originals by Richard Clark


The code:


  
  
  
  Australian Birds. From left to right, Kookburra, Pelican and Rainbow Lorikeet. Originals by Richard Clark


Figure with a code block

The 
 element may also be used for code examples:

Creative Commons Attribution Share-alike license
Using  around a Creative Commons license link with rel="license"


Here’s the code for that:


<small><a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution Share-alike license</a></small>
Using <small> around a Creative Commons license link with rel="license"


Differences between  and 

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


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


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

Don’t stop there!

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

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

Summary

As we’ve illustrated in this article, there are a lot of possibilities for the 
 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?  
Related Posts:
The small & hr elements
The hgroup element
Hello, summary and figcaption elements
Your Questions Answered 9
September HTML5 spec changes


Share and Save:


	
	
	
	
	
	
	
	
	
	
	
	
	
	
	




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



Hello, summary and figcaption elements
Bruce Lawson — Mon, 01 Feb 2010 10:42:38 +0000

			

				

			
		
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:

More information
Here is the source data that is discussed in the article ... 

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:

 (or video, table etc)
A rabid unicorn goring a fairy.

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.

Related Posts:

Legend not such a legend anymore
dd-details wrong again
HTML5 Doctor Speaking and Training Appearances
HTML5 Reset Stylesheet
Your Questions Answered #4


Share and Save:
	

	

	

	

	

	

	

	

	

	

	

	

	

	

	



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



dd-details wrong again
Remy Sharp — Mon, 12 Oct 2009 12:00:57 +0000

            
                
            
        
You may recall that I blogged about legend not being so legend as the heading element for details or figure. After enough noise was made the spec was changed so that the heading and contents of these elements can now be marked up using the dt/dd combo.

Although not immediately obvious why it’s the right choice, it appeared to work for our needs…at first. Of course now, it’s been discovered that it’s actually a pretty bad idea.



How we got here

In short, details and figure solve a common design pattern and provide nice new semantic tags to solve that problem.  A figure could be an image you’re referring to in an article or chapter of a book, and the details element allows the user to interactively show and hide the details of some piece of information.

Both elements can contain a heading element to label up the contents.  For some reason, beyond this author’s understanding, these two elements, completely different in meaning, have been historically tied to using the same solution solve the problem how to markup the heading.

As I mentioned earlier, originally the proposed solution for the headings was to use the legend element, which proved to completely break in every browser (in new and interesting ways).

Skip forward to mid-September, and Jeremy Keith proposes that we solve the legend issue with the dt/dd combo, and Ian Hickson says:


  That’s not a bad idea actually. Ok, done.


Before this was proposed there was lots of discussion about why we couldn’t introduce a new element to solve this problem, and Ian points out already 18 (or 22, I forget!) elements that represent some sort of heading.  This is the argument for not introducing another new heading type element to solve the details and figure problem.

The problem with dt/dd

Ironically the problem isn’t with the dt part of the solution, it’s actually with the dd.  

Dean Edwards (genius behind some very cool JavaScript and something that will soon blow your minds) has been testing these elements in detail and found a very serious issue with the dd in, guess what, IE6 & 7.  I want to explain and draw attention to what Dean has found.

Styling a dd within details or figure (and probably other elements) bleeds to the next element.

By styling a dd red, and only the dd, here’s what it should look like (and does in IE8):



Where as in IE7 (and IE6), the red style bleeds in to the following p element (note the “this paragraph shouldn’t be red”):

![dd styled in IE7](

What’s more, if you look back at the screen shots you can see the last paragraph says “Contents of first 
”.  The result of that test is being generated by the following JavaScript:

document.getElementsByTagName('dd')[0].innerHTML

Notice how in IE7, the contents of the first dd’s innerHTML is empty.

The problem here is that:


IE7 and below can’t style a dd properly without it breaking and the style bleeding in to adjacent elements.
JavaScript, randomly, can’t see the contents of the dd.


Is there hope?

There is a hack that fixes this issue. It’s pretty mad, but it does fix the styling issue. However the side effects from this hack are outright unacceptable and are so serious I would argue that the hack solution itself is a bug.

The hack is over at the public-html of W3.org, and involves stuffing an open object tag just before we close the head tag.

This isn’t a clean solution for including in HTML by hand, authors won’t remember or might get it wrong, so it needs to be perhaps automated as part of the HTML5 enabling script, right?  It would have to be inserted using document.write() as the last part of the head element.

Dean went on to test this, and he found:


  There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the . If there are any scripts following the document.write() then they are not executed.


The really freakin’ important bit:


  If there are any scripts following the document.write() then they are not executed


So, to answer the question: is there hope? No, not for the dd/dt combo.  It can’t be styled properly and hacks will break JavaScript.

We want the details

We, as authors, want to make use of details and figure today. Waiting for IE7 to fall out of circulation before we start using these elements (as it’s been proposed a number of times on the IRC channel and mailing boards) is outright not going to happen.  IE6 & 7 are going to be around for a good more number of years, certainly IE7 (IE6 has at least another 5 years in the beast).

We are going to start enabling the details interactive UI pattern using JavaScript whilst we wait for vendors bake it in to the browser, so the final proposed markup needs to work in all the browsers, including IE6 and IE7.

What are our current options?


Give new meaning to an existing element (as we’ve already tried to), legend, label and dt/dd have been tried, tested and failed. What else could we use?
Repurpose one of the existing new elements (keeping in mind that the dt/dd was repurposed so it should be a consideration).
Create another heading element to solve this problem.


The problem is that the conversation seems to have lost steam (or certain Dean was starting to see the conversation go in circles).  If you want to see these two elements make it the final spec, and correctly, head over to either the IRC channel or the mailing list, and get heard.

Reference links


Dean’s original details test (my modified tests to fire the innerHTML on load: details, figure)
Litmusapp browser screenshots of the results: details, figure
whatwg mailing list thread: September, OctoberRelated Posts:
Legend not such a legend anymore
Hello, summary and figcaption elements
How to get HTML5 working in IE and Firefox 2
2022, or when will HTML 5 be ready?
September HTML5 spec changes


Share and Save:





















dd-details wrong again originally appeared on HTML5 Doctor on October 12, 2009.



September HTML5 spec changes
Remy Sharp — Thu, 17 Sep 2009 12:00:20 +0000

            
                
            
        
September being one month before the HTML5 spec goes to last call in October, there’s been a few significant changes to the HTML5 spec that we wanted to briefly share with our patients.



Clarification over section and article

The spec has been clarified to help authors correctly choose between when to use section and when to use article, and Bruce’s section post has also been updated.

footer now works like header

This was a big one and causing confusing to people coming to HTML5 for the first time.  Originally you couldn’t include a nav element inside a footer, or a section. 

Now the spec has been changed to match the header element.

details and figure saved

Instead of using legend, which didn’t work, Jeremy suggested (although slightly tongue in cheek) to use dt for the title and dd for the body.  Ian Hickson agreed, and it’s in

Example:


 
 
Exhibit B. The Rough Copy trailer.


aside has better examples

The documentation has been updated to specify better examples of how the aside element can be used.

Better examples help us authors understand how it can be used.

Dropped Elements

The following elements have been dropped from the HTML5 spec (though bb and datagrid were some time ago, and datagrid has been postponed rather than dropped entirely):


dialog
bb
datagrid


Ch-ch-changes

We’ll be posting in more detail about some of these changes, and as further changes come out of the editing process we’ll no doubt keep you all up to date, either via our Twitter account (which you should follow) or feel free to let us know too!
Related Posts:
Legend not such a legend anymore
The section element
The figure & figcaption elements
The small & hr elements
The Footer Element Update


Share and Save:





















September HTML5 spec changes originally appeared on HTML5 Doctor on September 17, 2009.



Legend not such a legend anymore
Remy Sharp — Fri, 31 Jul 2009 12:00:26 +0000

            
                
            
        
Lately I decided I was going to recreate the interactive features of the details element using JavaScript (apparently the same day as fellow Brightonian Jeremy Keith).

However I ran in to some very serious issues with the tag, so serious, in it’s current state, it’s unusable.



Overview of the details element

The details element, by default, is a collapsed element whose summary, or label, is the first child legend (if no legend is used, the UA provides a default, such as “Details”), with a triangular button to indicate it’s current open state.

If you include the open attribute, then the element is open by default.  In theory, you could attach a click event to the legend, and switch the open attribute.

The markup would roughly be this:


  Terms & Conditions
  You agree to xyz, etc.


Here’s the details test page I was working from: HTML 5 details test

The issues

The biggest problem, and the show stopper for me, is that the browser’s treatment of the legend element completely breaks this markup pattern – this is true for all the major browsers: Opera, Safari, Firefox and IE (tested in all the latest and some older browsers).  I’ll go in these issues in detail in a moment.

Other problems include:


Styling the legend element is exceptionally difficult, particularly positioning
Using the WHATWG guidelines to styling the details element prove both difficult to interpret and difficult to implement.
When using CSS to style the open state of the details element using: details[open] { height: auto; }, meant that once I changed the open state using JavaScript, it wouldn’t trigger the browser to redraw (as it would if I had added a class). I’ve run in to this before, CSS 2.1 is styling source, not the DOM.


Legend treatment

Surprisingly Firefox is the worst one out in these issues, the rest of the browsers have fairly same treatment of the issue.  In the screenshots, I’ve included a fieldset and nested legend for reference.

Internet Explorer

IE7 & IE8 closes the legend element it encounters when it’s not inside a fieldset element and move it’s contents out to an adjacent text node.

What’s also strange, is that looking at the DOM it also creates another empty(?) closed legend element after that text node.  It doesn’t have any effect, but just looked odd:



Opera

Opera (9 & 10b) is very similar to IE in it’s treatment of the legend in the details element, except it doesn’t create the second closing legend node.  It just closes the legend, and creates the adjacent text node.

Safari

Safari simply strips the legend all together out of the DOM.  So much so, that if you open the web inspector, then the error console, you’ll see it warning out that it’s encountered an illegal element, ignoring it, then encountering the closing tag, so it ignores that too.  You’re left with just the text node.

Firefox

The best for last.  Firefox goes one step beyond the other browsers.  It assumes you’ve forgotten to include the fieldset element.  So when it hits the legend element, Firefox inserts an opening fieldset up until it finds (I believe) the closing fieldset element, which obviously it doesn’t so the result is the rest of the DOM, after the first illegally placed legend ends up eaten by fieldset element, which leaves my DOM in a mess:



Impact on other elements

details isn’t the only element that reuses the legend element for labelling, the figure element also is supposed to support the legend element.  The result is obviously going to be the same.

Conclusion

We can’t style the legend element when the text is being thrown out by all the browsers, and Firefox’s DOM mangling is just too painful to look at.

This basically means that we can’t, in any reasonable amount of time, use the legend element inside both the details and figure element in the spec’s current state.

For me, I’ll be using an alternative element, probably just a p element styled to look like a legend, but that’s really not the point.  Ideas anyone?

It turns out we weren’t the only ones looking at this and Ian Hickson has responded on the issue:

My plan here is to continue to wait for a while longer to see if the parsing issues can get ironed out (the HTML5 parser in Gecko for instance solves this problem for Firefox). If we really can’t get past this, we’ll have to introduce a new element, but I’m trying to avoid going there.

It’s fine to think that Gecko will update, but it’s IE that I’m worried about, they won’t turn out their render engine, and the result is we’ll have to avoid using the legend in any element other than fieldset.
Related Posts:
dd-details wrong again
Hello, summary and figcaption elements
September HTML5 spec changes
HTML5 Doctor Speaking and Training Appearances
The figure & figcaption elements


Share and Save:





















Legend not such a legend anymore originally appeared on HTML5 Doctor on July 31, 2009.

HTML5 Doctor » figure

Your Questions Answered 9

Offline viewing on requests

Question about dragging

About the href on any element

W3C Validator for the element

Headings

. However, if you’re splitting the article into sections, then you could use an

each time. See our article on the section element for more. Thanks, Tom

Got a question for us?

Related Posts:

The figure & figcaption elements

The element

The element

Using and

Figure with an image

Figure with an image and caption

A figure with multiple images

Figure with a code block

Differences between and

Related Posts:

Hello, summary and figcaption elements

Related Posts:

dd-details wrong again

How we got here

The problem with dt/dd

Is there hope?

We want the details

Reference links

Related Posts:

September HTML5 spec changes

Clarification over section and article

footer now works like header

details and figure saved

aside has better examples

Dropped Elements

Ch-ch-changes

Related Posts:

Legend not such a legend anymore

Overview of the details element

The issues

Legend treatment

Internet Explorer

Opera

Safari

Firefox

Impact on other elements

Conclusion

Related Posts:

About the `href` on any element

W3C Validator for the
element

.

However, if you’re splitting the article into sections, then you could use an

each time. See our article on the section element for more.

Thanks, Tom

The
element

The
element

Using
and

Differences between
and

Clarification over `section` and `article`

`footer` now works like `header`

`details` and `figure` saved

`aside` has better examples