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

Re: Bug 8404 -- taking it to the lists

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 1 Dec 2009 11:02:18 -0600
Message-ID: <dd0fbad0912010902k2520ceb7xa1e9a4ad065515f3@mail.gmail.com>
To: Nick Fitzsimons <nick@nickfitz.co.uk>
Cc: Laura Carlson <laura.lee.carlson@gmail.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, "Michael(tm) Smith" <mike@w3.org>, Shelley Powers <shelley.just@gmail.com>, HTMLWG WG <public-html@w3.org>
On Tue, Dec 1, 2009 at 10:51 AM, Nick Fitzsimons <nick@nickfitz.co.uk> wrote:
> 2009/12/1 Tab Atkins Jr. <jackalmage@gmail.com>:
>>
>> (I also note that many of the guides forbidding using a table as a
>> figure are merely forbidding it from being *labeled* as a figure - I
>> doubt they're requiring that they not be styled and treated otherwise
>> as a figure.  Even in books that I own that do explicitly label
>> table-figures as "Table 1.2" or what-have-you, the styling and meaning
>> of the table is identical to that of other figures.)
>>
>
> How they are styled is a presentational matter, and therefore outside
> the scope of HTML5.

Indeed, but in traditional publishing styling is generally an
indication of semantics.

> Considering a table to be a figure in a semantic
> sense strikes me as either ignoring its existing semantics as a table,
> or extending the semantics of a figure to be a generic container for
> anything outside the normal flow of text.

That's precisely what the spec currently defines <figure> as (well,
not for *anything* outside the flow - it still has to be a *part of
the document*; things that are only tangentially related and can be
removed entirely without changing the meaning of the document are
<aside>s).

> Even though a graphic
> designer specifies the same fonts and so forth for the captioning of
> both figures and tables, that doesn't make them semantically
> equivalent.

True, it's not an automatic equivalence.  It is, however, a strong
indication of such.  It also indicates that slicing the semantics any
thinner than that may be counterproductive - if designers aren't
currently making any effective distinction between them, what makes
you think they *want* to make such a distinction in HTML?  Styling is
often a *very* good indication of the granularity of classification
for the average person, and it's a mistake to go strongly against this
unless there are strong technical reasons for doing so.

~TJ
Received on Tuesday, 1 December 2009 17:02:51 UTC

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