Re: Bug 8404 -- taking it to the lists

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

Received on Tuesday, 1 December 2009 16:29:49 UTC