[whatwg] several messages about <figure> and related subjects

Maciej Stachowiak mjs at apple.com
Mon Feb 25 21:16:15 PST 2008

On Feb 25, 2008, at 2:42 PM, Ian Hickson wrote:

>   <label>
>      This would preclude any sane way of putting form controls in
>      legends, which would be bad.
>      This can't be fixed in the spec.

Is the ability to put form controls in figure captions (let alone more  
than one form control) really more important than ability to style  
them sanely? Putting a form control in a figure caption seems unlikely  
to me. Even more so for <details>, where form controls inside the  
label would be confusingly inside another interactive element. Indeed,  
<details> is arguably a kind of form control.

>   <legend>
>      Parsing issues in Firefox and IE:
>         http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%3Edocument.createElement(%27figure%27)%3C%2Fscript%3E%3Ctitle%3ETitle%3C%2Ftitle%3E%3Cp%3E...%3C%2Fp%3E%0A%3Cfieldset%3E%0A%20...%0A%20%3Cfigure%3E%0A%20%20%3Clegend%3Efigure%3C%2Flegend%3E%0A%20%20content%0A%20%3C%2Ffigure%3E%0A%20...%0A%3C%2Ffieldset%3E
>      ...and the element doesn't appear in the DOM when there's no
>      <fieldset> in at least Safari and Firefox.
> This is quite the messy situation.
> I think we should discount <dt>, <h1>-<h6>, <header>, <div>, and <p>  
> right
> off the bat, since they would confuse matters greatly. We should  
> similarly
> discount <title>, <caption>, <th>, <dt>, and <label>, because the  
> problems
> with those can't be fixed.
> That leaves <legend>, or inventing a new element. Both options are
> unappealing.
> One of the advanages with <legend> is that while the parse issues  
> today
> are messy, we can fix those (indeed the spec now has them fixed  
> already,
> though we might want to consider making <legend> close <p> tags).
> A new element would be a neat solution, but frankly I'm out of words  
> to
> use, and if we keep adding new ways to mark up titles and captions and
> legends and labels, authors aren't going to be able to work out when  
> they
> should use each element. Various people suggested various element  
> names in
> the e-mails below, but from the names proposed it should be clear  
> that we
> are scarping the bottom of the barrel. I'd rather have a cleaner  
> solution
> for something that could be with us for years to come.

It seems to me that the problems with adding a new element are purely  
aesthetic, while the problems with reusing 'legend' are practical and  
harm deployment of the new element.

> I think our only option is to use <legend>, and, while in the  
> migration
> period, have people use markup like:
>   <figure>
>     <legend><span class="legend"> ... </span></legend>
>     ...
>   </figure>
> ...with styles like:
>   figure > legend, figure > .legend { ... }

Yuck. Surely writing <legend><span class="legend"> ... </span></ 
legend> is uglier than writing something like <figcaption> ... </ 
figcaption>. And the migration period could take more than a decade.  
Given the lengths that HTML5 goes to so that it can degrade  
gracefully, this sounds like a high price to pay to avoid adding an  

>> 4) Another alternative would be using a new unknown element. Whipping
>> out my thesaurus, I see <rubric>, <inscription>. Another  
>> possibility is
>> something like <figcaption> (to avoid the problems <caption> would  
>> cause
>> for figures inside tables), but that wouldn't be a good fit for
>> <details>.
> <figcaption> and <detailscaption> and so on just seems like it would  
> make
> the language really complicated.

But <rubric> is pretty reusable and about as semantically correct as  
<legend> for general use as a caption:


I agree that the multiplicity of single-purpose elements for seemingly  
similar purposes is confusing. But HTML is already well down this  
road. I think introducing a new element that's intended to be reusable  
for similar contexts would be cleaner than trying to force reuse of  
what was meant to be a special-purpose element.

> We've waited years for <figure>, can't we wait a few more while  
> browsers
> get their act together in their parsers?

<figure> could be used right now with CSS styling as backup and  
without polluting up the markup if it didn't rely on an aspect of the  
HTML5 parsing algorithm that no browser implements yet. Otherwise we  
will indeed have to wait years, needlessly.


More information about the whatwg mailing list