Re: Bug 8404 -- taking it to the lists

Maciej Stachowiak, Tue, 01 Dec 2009 11:07:19 -0800:
> On Dec 1, 2009, at 6:19 AM, Tab Atkins Jr. wrote:

> I also found numerous examples of figures explicitly marked as such 
> and containing tables, code samples, lists, multiple images or tables 
> individually captioned, and so forth, in the books and academic 
> papers I had lying around.

Do you also have examples from the photo web site genre where the photo 
and its accompanying text is marked up as a figure? (You used Flickr as 
a use case for <figure> many times earlier and, as Shelley has pointed 
out, <img> continue to be the most typical use case for <figure> in 
many minds.)

I ask because I wonder if you think that <figure> is simple/useful 
enough for the much and long [1] talked about need for a caption for 
<img> elements.

If <figure> is not simple/useful enough for the normal use of <img>s, 
then I think we should ask ourselves why we are solving the issue of 
figures in academic books first and foremost - in these Web application 
times.

I too checked some books today - so far without finding tables or code 
examples labeled as figure. 

The 2nd book I checked had many figure labels attached to screen shots 
from browser windows/dialogs. I wonder if you would have called these 
"images" ... The *code examples* of the same book had a title - 
effectively a caption - informing the reader about from which file the 
code was taken. These code sections was introduced with a colon in the 
preceding paragraph - figures are usually not introduced with a colon 
but with a reference to the enumeration inside the caption of the 
figure! But <figure> of course has the structure to mark these code 
examples up. As do <dl> (but HTML5draft doesn't allow <dl> for that). 
The colon and the fact that each caption did not contain a unique 
reference (the same filename reference appeared in several code 
examples) were the only thing that doesn't make these code examples a 
"figure" in the HTML 5 draft's sense ...

This shows that captions is necessary not only for a figure that can be 
moved to another end of the document, but also for "figures" that must 
appear in the text flow.

A third book I checked did label /some/ screenshots as "Figure x.y.z". 
While other screen shots - with accompanying explanative text and a 
border surrounding both the image and the text (usually step by step 
illustrations) - did not have a label at all. The book also has 
"Listing x.y.z" for code examples. More commonly: Many computer books 
starts with a section called "conventions in this book", where they 
describe the symbols and layout used to separate "tips and tricks", 
"extra info", "warnings", "best practises". 

What are these units? HTML5 Asides? No. HTML5 Figures? No. Do they need 
captions? Yes.

You know: When the HTML 5 draft says that the clue, when deciding if 
something is a <figure>, is whether it can be moved to another end of 
the document or not, then the draft really have the caption of the 
figure in mind. 

Because, how else, can it be moved to another end - removed from the 
context - unless there is a way to link (in the mind, when reading) 
from the context to the location where the <figure> is kept? If you 
don't find the reference, then you don't find the figure, and thus it 
can't be moved. The enumeration of the figure/table/listing, which is 
often found inside its caption, clearly has the purpose of making it 
possible to refer to item regardless of whether the item appears on the 
same page or not.

And yet: the draft makes the caption optional ... 

Therefore, more than we need <figure>, we need 1) a standard way to add 
captions - to whatever we want and 2) an enumeration/reference element 
- which would typically contain text such as "Figure 1.2.3", "Table 
1.2.3" or even "Page 100".

As to the latter, perhaps we have that: <a id="Figure_1_2_3">Figure 
1.2.3</a>. Except that the draft, in is boundless wisdom, says that we 
should not use the anchor element that way ... 

> If the content model of <figure> is 
> restricted as Shelley suggests, then it will be unsuitable to contain 
> the kinds of content that writers actually put in figures. The 
> suggested workarounds of converting tables or text in a <figure> to 
> an image or putting it in a separate document in an <iframe> seem 
> clearly bad to me.

Unclear what you refer to. But please note that I have not proposed to 
use <object> as the body of a <figure> as a workaround for anything - 
unless you are also willing to look at the current body element of 
<figure> - <dd> - as a "workaround" as well. 

I proposed it because I think is is more proper. (I realize that I have 
a bug to file w.r.t. <object>.) I see <object> as an element not only 
for embedding an external source, but also as a container for mark-up 
which - together - constitute an object/figure. Thus we don't need to 
use whether <figure> or <dd> for that. We can separate the task of 
collecting something into a unit/object from the <figure> element. We 
can further separate the task/problem of adding a caption to some 
element, from <figure>. And we can separate the function of being able 
to refer to the "figure" outside of the current context, from figure.

[1] http://www.w3.org/Style/Examples/007/figures
-- 
leif halvard silli

Received on Wednesday, 2 December 2009 00:48:11 UTC