[whatwg] many messages regarding image captions

Le 27 nov. 2006 ? 20:49, Ian Hickson a ?crit :

> On Wed, 1 Nov 2006, Michel Fortin wrote:
>
>> I see no reason to be restrictive on the kind of content that can be
>> captioned.
>
> Well, we want the semantics to be well-defined. It's not clear to  
> me what
> the semantics will be in all cases if we allow anything to be  
> captioned.

To me, a figure contains illustrative content attached to a document.  
It may be an image, a code sample, or a snippet of another document  
used as an example. I think it's important we do not try to narrow  
too much what can and what cannot be contained in a figure; that's  
the job of the author do decide.

For instance, lets say an author wants to put a paragraph in a  
figure. It could be to show how the font is rendered, in which case  
he may prefer to use a pixel or vector image because what is  
important is the shape of the characters; it may be to show a  
particular writing style, in which case it's much better to provide  
the paragraph as text directly as the text itself is the  
illustration. In any case, the author knows what he wants to  
illustrate, and we should allow him to use the best medium for that  
task.

Moreover, I don't think the caption should be mandatory. I know that  
the primary reason for including a figure element is to have a way to  
put captions on things, but <figure> as a simple container for  
illustrative content has value too. For instance, I would gladly use  
<figure> to denote HTML snippets in the following document of my own  
website:

<http://www.michelf.com/projects/php-markdown/concepts/>

Would this be a valid usage? (Of course, according to the current  
spec: no. But should it be?)


> This one in particular:
>
>> http://politics.guardian.co.uk/homeaffairs/story/0,,1806799,00.html
>
> ...suggests we may want to have multiple <legend> elements per  
> <figure>,
> to allow for a caption and photo credit to be given. What do people  
> think?
> Would some other way of inline giving photo credit metadata be better?

I think that could be useful. But my opinion is that it'd probably be  
better to find a way to do this in the same manner for table captions  
too. (A table caption citing the source for its data is quite  
common.) I think it'd be wiser to do this using inline elements  
inside <legend> or <caption>.


> Why not just embedded elements?

Do you really want to disallow inline SVG or MathML as figures?


>> Block-level element, and structured inline-level element.
>
> I couldn't really work out why it should be inline. It seems  
> equivalent to
> a <p>.

I'm not sure about this either; I think it should be like table, and  
table is declared as such. That's all.


Le 27 nov. 2006 ? 20:49, Ian Hickson a ?crit :
>
>> I suggest that this element behave in the opposite way from alt=:
>> whereas alt= should be presented only if the image itself is *not*
>> presented, the caption element should be presented only if the image
>> itself *is* presented. Otherwise there would be the same problem with
>> non-sequiturs in non-visual media as there is with descriptive alt=.
>
> Agreed; spec now requires this. Not sure how to make this jive with  
> the
> idea of allowing <pre>/<ol>/etc, though; see above.

Why would you need a substitue for "alt" in these cases? I see not  
need for alternative content when the content is already in text  
format, or am I missing something?


Le 27 nov. 2006 ? 20:49, Ian Hickson a ?crit :

>> So I propose a new <fcaption> elements -- for "figure caption" -- in
>> replacement for the <caption> element in my previous figure  
>> construct:
>>
>>     <figure>
>>       <fcaption>Caption Text</fcaption>
>>       <img src="...">
>>     </figure>
>
> I really want to avoid introducing new elements for concepts we  
> already
> have... We already have four or so ways of doing "caption"-like  
> things:
> <caption>, <legend>, <label>, and title="", not to mention the <hx>
> elements, <th>, and <title>, which are similar enough that people  
> on this
> thread have sometimes mentioned them. The more we introduce the more
> confusing the language becomes.

Ok, that's fine. Goodbye <fcaption>.


> On Wed, 22 Nov 2006, James Graham wrote:
>>
>> Another issue to consider is the possibility of multiple images  
>> with a single
>> caption (this is very common in scientific papers, print  
>> magazines, etc.). A
>> construct like
>> <figure>
>> <img>
>> <img>
>> <img>
>> <imgcaption>
>> </figure>
>> might be enough to support this (the details are, I think, non- 
>> trivial);
>> something that requires the caption to point to exactly one image  
>> cannot.
>
> Hm. This is currently not possible either. I didn't see many (any?)
> examples of this in the list of sample pages that Michel provided,  
> though,
> so I'm not sure we need to address this in the first version. What do
> people think?

There isn't many, but there are some. I'll just point out that if you  
were using the content model I suggested there would be no problem  
incorporating multiple images in a figure.


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

Received on Monday, 27 November 2006 19:39:51 UTC