Re: Bug 8404 -- taking it to the lists

2009/12/2 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>:

> But, this way we get closer and closer to how the HTML 5 draft
> recommends that we use <dfn> in connection with <dl> lists.
>
> It seems to me, though, that in order to be certain that it is a
> "figure reference" and not a definition that is meant, it would be nice
> to have something that can be clearly identified as a caption element.

Since the dt element has a figure parent, user agents can understand
that the dfn element is inside a figure caption. A notice could be
added to the dfn element specification that it has this special
numbering meaning inside a dt of a figure.

> So you are after the structure, primarily? But then the draft should
> remove the text that says that it must be possible to move the figure
> to an appendix etc without affecting the flow content. Then we are,
> however, moving further away from what a figure is - or is conceived to
> be.

Figures don't need a number to get linked to the text. A textual
caption can sufficiently explain what it has to do with the main
content.

In scientific documents, the dfn element would of course be required,
but such a strict numbering is simply not necessary in more informal
documents. For example, in my dog photo example, if there is only one
photo of a dog in the document, there can be no confusion about which
figure I refer to.

Movement to an appendix might be a little bit too far. Perhaps we
should reduce that to "freely movable throughout the current section
or article". In my opinion it should also be made clear that this
possibility of free movement is a requirement.

> It surprises me that you did not at least place the caption text of the
> <figure> inside the @alt text of the <img>.

You are suggesting this:

<p>See the attached photo.</p>
<figure>
<dd><img src="photo.jpg" alt="A photo of my dog in the garden." /></dd>
<dt>A photo of my dog in the garden.</dt>
</figure>

Without image support, this will reduce to:

<p>See the attached photo.</p>
<figure>
<dd>A photo of my dog in the garden.</dd>
<dt>A photo of my dog in the garden.</dt>
</figure>

This is a very bad practice, since the same piece of text is now
listed twice. The alt text should be able to replace the image, so
that the document continues to make sense. See HTML5 spec section
4.8.2.1 for more info (part 4.8.2.1.5 includes an example of a figure
element):
http://dev.w3.org/html5/spec/text-level-semantics.html#alt

> Otherwise, this example demonstrates the problem: As soon as you it for
> some - draconian - reason can't be defined a figure, you suddenly can't
> have a caption anymore ... That is illogical. Didn't you care most
> about the structure?

I don't understand what you mean here. I think there is a word missing
in the second sentence. ;-)

> I don't understand what you mean by "in the original situation". The
> book? Otherwise, I think that inline images are just as much in need of
> captions as paragraph level images/figures. I also do not understand
> what you mean by saying that a table could not be moved a way ...
> Clearly it can, if it is designed that way. It just need a <dfn>
> element for marking up its identity reference ...

The original situations is the first piece of code (the bad one):

<p>See this photo:</p>
<figure>
<dd><img src="photo.jpg" title="Photo" /></dd>
<dt>A photo of my dog in the garden.</dt>
</figure>

This is wrong because the colon in the paragraph fixes the position of
the figure. (Note that the current spec version does allow this usage,
but I don't agree with it.) However, if the paragraph using another
formulation, then it is correct. The consequence is indeed that inline
objects cannot get a caption. However, since the object has a fixed
position relative to the paragraphs (since the figure element is not
used), I do not believe caption functionality is necessary, since the
object can be described in a paragraph and the object is guaranteed
not to be moved away from the paragraphs.


Jeroen van der Gun
http://www.jeroenvandergun.nl

Received on Wednesday, 2 December 2009 22:05:21 UTC