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
[EMAIL PROTECTED]
http://www.michelf.com/
