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
details elements properly.
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 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 is used to add a caption to tables, which makes it a good candidate for captioning the
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.
Could we use an
hX tag? We want to give the
details element a heading, so it stands to reason that we could use an
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
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
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
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
details would cause confusion to the browser (citation needed).
After discussing the issue on the IRC, aside from Hixie suggesting that the
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.
I think we need to discuss and find an alternative to hoping the browsers will fix the
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