[whatwg] The IMG element, proposing a CAPTION attribute

[Michel Fortin]

Le 10 nov. 2006 à 19:16, Ian Hickson a écrit :

> The difference is that <caption> will never work, because of things  
> like
> this:
>
>    <table>
>      <caption>
>         <figure>
>            <img ...>
>            <caption> ...A... </caption>
>         </figure>
>      </caption>
>      ...
>    </table>
>
> ...which, for legacy compatibility reasons, must result in a DOM  
> where the
> text with "A" ends up in a second <caption> element that is a child  
> of the
> <table> element.

I don't get it. Are you saying that <caption> cannot work outside  
<table> because it has to work a certain way when inside a <table>  
element? Or are you simply saying that <figure> cannot work because  
it cannot work inside a table caption?

If supporting <figure> inside a caption is so important, browsers  
could treat <figure> in the same way they treat <table> when inside a  
caption. This works fine in current browsers:

    <table>
      <caption>
         <table>
            <caption> ...A... </caption>
            ...
         </table>
      </caption>
      ...
    </table>

Now, I can't be sure how hard it'd be to make <figure> behave like  
<table> in this specific case, but as I already said.

But any of these two samples seems completely ridiculous and  
confusing to me. Personally, I don't think any of the above cases  
should be allowed (caption has inline-level content in HTML4 by the  
way), and I it'd also be fine if browsers continue to do whatever  
they do when inside a <caption> element.

And I don't see how any of this could prevent <caption> from creating  
a caption element in the DOM when *outside* a table.


> The idea of having markup of this form:
>
>    <-container->
>      <-embedded-content-/>
>      <-caption-> ... </-caption->
>    </-container->
>
> ...is a fine idea, however, which has been proposed multiple times,  
> and
> I'm sure we'll use some variant on that. We just can't use  
> <caption>. Or
> <label>, because that's for form controls.

I certainly agree that <label> is a poor choice, because even if it's  
not necessarily a bad word for the concept, it's already used to mean  
something else which has little to do with image captions.


> I imagine we'll use <legend>. Parsers are a bit erratic with it  
> right now,
> but we're requiring them to shape up for the parser part of the spec
> already, and the <details> element uses it already.

I'm not sure I like "legend" as a word for captions. A legend -- in  
the context of a graph, a map, or a schema -- is a list of symbols or  
colors followed by some definition of what they represents on the  
figure. It's far different from a caption or the title of a figure.

But <legend>, as an element, is worse: image captions and table  
captions are much more similar in concept and in default presentation  
than fieldset legends, which are some kind of title for a thematic  
group of form controls.

By the way, I think <legend> for <details> is a perfect choice,  
because like <fieldset>, <details> is a functional regroupment, so  
<legend> becomes some sort of title for a group of related user  
interface elements. That definition works for both <fieldset> and  
<details>. If you add <figure> into the mix, <legend> becomes a title  
for something on the page. I think this would dilute the semantics  
and make the language less coherent.

Even if it's a little more difficult, I think using <caption> is the  
right thing to do.


Michel Fortin
michel.fortin at michelf.com
http://www.michelf.com/