- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 2 Dec 2009 01:47:35 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Shelley Powers <shelley.just@gmail.com>, HTMLWG WG <public-html@w3.org>
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