W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: Bug 8404 -- taking it to the lists

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 1 Dec 2009 15:38:03 +0100
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Shelley Powers <shelley.just@gmail.com>, HTMLWG WG <public-html@w3.org>
Message-ID: <20091201153803880973.ffbd48a2@xn--mlform-iua.no>
Tab Atkins Jr., Tue, 1 Dec 2009 08:19:06 -0600:
> On Tue, Dec 1, 2009 at 8:03 AM, Shelley Powers:
>> Bug 8404 reads as follows:

>> This is counter to understandings about figure in other businesses and
>> environments, where figures are a graphic of some form. In addition, this
>> provides a confusing parallel in functionality between figure and 
>> aside, enough
>> so that people are going to have a difficult time knowing which is 
>> which, and when to use one over the other. In fact, with this
>> parallelism, we don't need both.
> 
> As I stated on the bug, this last paragraph is false.  I provided
> three examples directly from Google Books results, obtained after a
> bare minimum of searching, of both code and tables.  A good 15 minutes
> of effort would have provided tens of more examples.  I also made
> reference to the first coding book I pulled off of my shelf, which is
> full of dozens of code figures (not illustrative, actual code) and
> literally hundreds of table figures (again, where the contents are not
> just illustrative, but are actually necessary for understanding the
> text that refers to it).  In all of these cases the figures match
> exactly with what the spec says - they are part of the document, but
> could be moved away, perhaps into an appendix, without affecting the
> meaning or flow of the document.
> 
> It takes only a modicum of effort to thoroughly disprove your
> assertion.  It is simply incorrect, and cannot be used as a valid
> reasoning for anything in this bug.  Please stop attempting to use it
> as justification.

What you did not prove anywhere, is that people will *not* have a 
difficult time understanding what <figure> is about.

Shelley, as a solution, suggests refocusing <figure> to only allow 
graphics, media elements and foreign content (svg/math) and some more.

I support Shelley very much, with the possible exception (depending on 
her view of it) that I think HTML4 already has an element that wraps up 
a figure, namely <object>. Thus, I think whatever you want to add a 
caption to, if it is not a media element or foreign content, needs to 
be wrapped inside an <object>: 

<figure>
	<p>Caption	
	<object><table>...</table></object>
</figure>.

But I think that <figure>, which has been touted as a solution to 
adding captions to <img>s (Flickr ...), will fail even more badly for 
that, very obvious use case. Simply because  no one perceive a photo of 
their mom and dad as a "figure", just because it has a caption. 
Conversely, they will not wrap that photo inside a <figure> just 
because they would like to add a caption.

Therefore, in addition to specifying very clearly what the content of a 
<figure> can be, we should also realise that the purpose of <figure> in 
reality is to add a caption to something. A renaming of <figure> is 
therefore due:

<cap>
	Caption
	<img src=img alt=txt >
</cap>.

(I outlined this more in the bug report.)
-- 
leif halvard silli
Received on Tuesday, 1 December 2009 14:38:44 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:54 UTC