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