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