- From: Shelley Powers <shelley.just@gmail.com>
- Date: Tue, 1 Dec 2009 10:33:20 -0600
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, HTMLWG WG <public-html@w3.org>
On Tue, Dec 1, 2009 at 10:29 AM, Shelley Powers <shelley.just@gmail.com> wrote: > On Tue, Dec 1, 2009 at 10:19 AM, Leif Halvard Silli > <xn--mlform-iua@xn--mlform-iua.no> wrote: >> Shelley Powers, Tue, 1 Dec 2009 08:50:43 -0600: >>> On Tue, Dec 1, 2009 at 8:45 AM, Tab Atkins Jr.: >>>> On Tue, Dec 1, 2009 at 8:38 AM, Leif Halvard Silli >>>>> 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. >>>> >>>> Indeed, and she used as justification a statement that figures are, in >>>> common use, only used for captioning illustrations. I showed that to >>>> be trivially false; it is very common to put code and tables in >>>> figures. >> >>> Actually, your examples did demonstrate that figure is almost >>> invariably used for illustration. The first two examples you gave were >>> illustrative, and I believe the third you provided was embedded in a >>> figure in the book because it was a scanned copy from another source >>> and added to the book as an image (typographical differences). Most >>> book company templates only allow external images within elements >>> designated as "figure". >> >> I have a book about Java. Its table of contents starts like this: >> >> * Table of contents >> * List of all figures [ Above 100 figures] >> * List of all programs [ Above 100 code examples ] >> * List of all tables [ Above 50-60 tables] >> >> All 3 - figure, program, table - could be labeled as "figure", >> according to the current HTML 5 draft. And they are also all laid out >> very much the same way in the book, with the same styling of the >> caption. So it would be quite logical to use the same wrapper for all, >> and the same caption element for all. >> >> If, instead of that confusing word "figure", we had a combined >> figure/caption element that one could add to whatever element one >> wants, then authors could themselves add classes to the caption >> element, to show what kind of unit the - ah - figure is. Then it would >> also be possible to - logically and simply - use it for images/photos. >> -- >> leif halvard silli > > > There is a reason that books separate out figures, tables, and > examples: because they are not the same thing. > > A table in a book is equivalent to an HTML table. The data is not for > illustrative purposes, it is a true data table. > > Examples are just that: code examples meant to be copied and used. > Typically they also have an equivalent format, in the form of contents > in a zip file a person can download. > > A figure is for illustration purposes, as Laura demonstrated with the > list of style guides. And as the style guides reflect, HTML tables > should no more be used for illustration purposes than they should be > used for layout. > > Now, there are more likely to be cases of people using HTML tables for > layout. Do we then incorporate this as an allowable function in HTML5? > If not, if we're working to prevent misuse of existing and new HTML > elements, why then we would we condone the misuse of HTML tables for > one purpose, but not for another? > > Your idea works for allowing all content, Lief, but it doesn't the > real problem of introducing bogus HTML tables into web pages. > > Shelley > I swear, there's something about gmail that brings out the worst typos in me. Normally I don't correct my typos since I was chastised in this list for doing so, but in this case: Your idea works for allowing all content, Lief, but it doesn't _address_ the real problem of introducing bogus HTML tables into web pages Sorry Shelley
Received on Tuesday, 1 December 2009 16:33:55 UTC