Re: Bug 8404 -- taking it to the lists

Jeroen van der Gun, Wed, 2 Dec 2009 23:04:44 +0100:
> 2009/12/2 Leif Halvard Silli:
> 
>> 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.

We agree that in a caption, that's the function a <dfn> should have.

>> 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.

I agree in principle that the identification doesn't need to be a 
number. I think, however, that something that is referred to as 
"figure" _must_ have such a identification string. But I want to remove 
the restriction on "this element" - we don't need a figure element - 
that "the thing" is a figure can be found out from the fact that its 
caption eventually has a <dfn> element. We instead merely need a way to 
add captions, to whatever we want.

> 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.

I guess you could say <captionElement><dfn>My 
dog</dfn><captionElement>. But I wonder what would happen if your dog 
was also "defined" in another place in the page.

> 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.

I think we eventually need a construct/element that merely links a 
caption to another construct/element. It will then be up to the author 
how "independent/self-contained" he or she make each concrete instance 
of that element. Clearly, if the caption contains a <dfn> - or a 
similar element - _then_ the element is independent and could 
theoretically be moved away from the context.

>> 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>

[ snip ]

No. I did not not suggest anything. I merely commented what happened 
when you converted your own example figure to a "non-figure" - a bare 
naked <img>: you dropped the caption text. And you did not place the 
caption text inside the @alt attribute instead. And neither did you 
place it in its nearby context. If this "figure" element had been some 
sort of caption construct, then you did not need to remove the caption 
simply because the "figure" formalistically wasn't a figure anymore.

>> 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. ;-)

There was a word too much. Just drop the word "it" in the first line.

>> 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.

I think that the problem here is merely the definition of the element 
(and thus, also the name of the element is wrong). Even if that text 
refers to the element via a colon, it is still justified to have a 
caption on it.

> (Note that the current spec version does allow this usage,
> but I don't agree with it.)

The current version forbids it. It isn't self-contained that way.

> 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.

Table has a caption. And there is something called inline-tables. (In 
HTML 4 you can validly place a table inside a paragraph by placing it 
inside an <object> element.)

Clearly images, which by definition are inline, could also need a 
caption. An image, when it appear floated inside a paragraph, will 
often be inspected independently from the paragraph, and may thus need 
a caption so you can quickly see what it is about.
-- 
leif halvard silli

Received on Wednesday, 2 December 2009 23:59:39 UTC