Re: Bug 8404 -- taking it to the lists

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