[whatwg] The IMG element, proposing a CAPTION attribute
Michel Fortin
michel.fortin at michelf.com
Fri Nov 10 18:19:59 PST 2006
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/
More information about the whatwg
mailing list