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: https://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

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: https://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

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?