Saving Figure & Detail

In finding that the legend element simply doesn’t work inside both details and figure, myself and others been keen to find a solution.

Ian Hickson has said:

I am leaning towards keeping the language sane (not introducing yet another element that basically means “header” or “important” or “caption”), at the cost of delaying how soon we can use the feature.

The huge problem with this is that browsers will not catch up. IE is the dominant browser, and if IE6 to IE8 don’t support the legend element embedded in anything other than fieldset then we, as authors, are going to have to find an alternative. This is where the spec is fiction.

I agree with Hixie that a new element isn’t required that means “header” or “caption”, but equally I believe we have enough in the spec to label the figure and details elements properly.

Alternatives

I’ve gone through a number of alternatives with Jeremy and Bruce and I want to share them with you:

label

label: This was my initial favourite to work within the new elements, since what we’re trying to do is label the figure or details that are tucked away.

The problem Jeremy raised was that of screenreaders. Are they going to look or assume there’s an associated input element?

I’m not an expert on screenreaders, so I can’t say for sure. Bruce suggests screenreaders may only look for the input element if the label is within a form. If this is so, then it’s almost a good candidate.

My issue with this, is that it’s perfectly reasonable, in my head, to have a figure within a form, which could cause screenreader problems.

Here’s a label figure test: http://jsbin.com/elatu (edit)

Here’s label in a details element and nested in a form: http://www.brucelawson.co.uk/tests/html5-details-label.html

Update Bruce’s tests so far show that label is working fine with screenreaders

caption

caption is used to add a caption to tables, which makes it a good candidate for captioning the figure and details elements.

However, due to a similar bug as the legend issue, if the browser finds the caption element outside a table, it simply strips it from the DOM – which makes this a non-option.

Example of caption being stripped from the DOM: http://jsbin.com/eloda (edit) (view the DOM and you’ll see the element has gone)

Heading

Could we use an hX tag? We want to give the figure or details element a heading, so it stands to reason that we could use an h2 or h3, etc.

The problem is the TOC that’s created.

I originally thought I could hide this from the TOC by using the hgroup, but this element will grab the first heading and include it in the TOC. So this isn’t a viable solution because I don’t believe these should be part of the TOC.

On top of which it seems over the top to include two elements just to solve this issue. I think the figure and details need a heading, and although using hX elements make sense to me, it feels klunky (for want of a more expressive technical term!).

header, to me, has a similar semantic meaning as an hX element, and we could reuse this to replace the legend in the figure and details elements.

It wouldn’t become part of the TOC, because you’d need an hX element to create a new item in the TOC. This also doesn’t cause any issues with screenreaders (if in fact label does).

Here’s an example of header being used in the wild (for the button example on the right): http://2009.full-frontal.org/ticket-draw

Lachy pointed out on the WHATWG IRC channel that in the future User Agents may treat the header element properly and using it for the caption to the figure or details would cause confusion to the browser (citation needed).

New Element

After discussing the issue on the IRC, aside from Hixie suggesting that the figure and details is dropped, one solution is to create a new element. This works fine in any browser because you’re not stepping on an existing element. For example, using <c> as caption can solve the issue.

I don’t mind how it’s solved, obviously a c element would be duplicating the caption element, but that’s unavoidable.

Conclusion

I think we need to discuss and find an alternative to hoping the browsers will fix the legend issue. figure and details are both useful elements, particularly the former, so I’d rather not see them binned from the spec. If label is viable, I think this is the best fit, otherwise (since header could cause long term issues), a new element can solve this.

HTML 5 paves the cowpaths but the use of legend isn’t possible, so we must find an alternative if we want to sensibly uses this captioning feature.

I know using the html5.enable feature if Firefox 3.6b, but this still leaves all the other browsers (and Firefox 3.6 isn’t even out) – so again, waiting to see what browsers do isn’t a solution (nor is serving the page as XML – since IE just chokes).

What do you think? Is there a better alternative? How do screenreaders react to label?

7 Responses to “Saving Figure & Detail”

  1. Preliminary tests on http://www.brucelawson.co.uk/tests/html5-details-label.html by the ever-so lovely Léonie Watson of Nomensa show no screenreader problems in Jaws, NVDA, SA To Go and Window Eyes on IE8 and FF3.5. All treat the associated form label as expected, and the label inside the details tag as plain text.

    I’ve made another test, in which there is a form inside the details element (think collapsible advanced search option): http://www.brucelawson.co.uk/tests/html5-details-label-complex.html. Léonie reports similar results: “the same with Jaws, NVDA, SA To Go and Window Eyes. The associated label is dealt with as expected, and the details label is treated as plain text.”

  2. I’ve now run in to a much bigger problem with using label: you can’t get the keyboard to focus on it, see this label example: http://jsbin.com/ebexe

    This isn’t a problem for figure, but is a problem for details, as the user should be able to tab to the collapsed details (as per Gez’s tweet).

    The only solutions I now see are either a new element or header (and I know Lachy didn’t like that because of the semantic mess it might make).

  3. Well, we could persuade Hixie’s Pixies to redefine header .. someone on IRC suggested it (the logging site was down so no logs available publicly)

  4. The example http://remysharp.com/demo/details-with-js.html seems to work in all my browsers, though the focus is invisible in FF3.5.

    http://jsbin.com/ebexe shows focus on the label in IE8 and Opera 10, but not in Saf4 and FF3.5.

  5. @Rijk – thanks for the testing. I did my initial testing in Safari, which you’ve seen doesn’t focus on the label element (which to be fair, is pretty damn random!).

    Based on chats with Bruce, I think we’re going with, as authors and trailing in the wild, a new element along the lines of <c>

  6. Regarding using label: what if you want a label and a form field inside the figure caption? Or what if you want to use a label as the actual figure content?

  7. [...] legend is specified as a child of figure and details, although it’s unstyeable in all current browsers. Remy Sharp and I have suggested re-specifying header to replace legend or—better still—dream up a new element. (Bug report, Remy’s blog post “Saving Figure & Detail“). [...]

Leave a Reply
Not required

CODE: Please escape code and wrap in <pre><code>, doing so will automatically syntax highlight