W3C home > Mailing lists > Public > www-style@w3.org > October 2001

RE: How is it possible to devise such a feeble system?

From: Jeffrey Yasskin <jyasskin@hotmail.com>
Date: Fri, 26 Oct 2001 13:52:55 -0500
To: "'Sampo Syreeni'" <decoy@iki.fi>
Cc: <www-style@w3.org>, "'Jesse McCarthy'" <mccarthy36@earthlink.net>
Message-ID: <000001c15e4f$6c218d10$682d7481@bluejay>
> -----Original Message-----
> From: www-style-request@w3.org 
> [mailto:www-style-request@w3.org] On Behalf Of Sampo Syreeni
> Sent: Friday, October 26, 2001 4:27 AM
> To: Jesse McCarthy
> Cc: www-style@w3.org
> Subject: Re: How is it possible to devise such a feeble system?
> No. What I said is WAI is the only instance to formally state 
> that tables used for layout are bad. Hence, WAI did not come 
> out of the "clear blue sky", but is an unstated reference 
> whenever anybody raves about how bad tables are.

Yes. Everyone should read, understand, and implement WAI.

> Knowing WAI is important in another respect, as well: if you 
> haven't read their material, you won't really understand why 
> table based layout actually *is* so bad. If you think about 
> the accessibility reasoning behind the rule, you'll see that 
> it mostly applies to HTML tables, and not the CSS ones.

I don't think this is true. In my opinion, CSS tables are as bad as HTML
tables. See below.

> <snip/>
> >The bottom line is the properties we are talking about were _only_ 
> >intended to be used to establish table functionality in document 
> >languages that do not have predefined table elements, and 
> now that the 
> >XHTML Table module exists, they would only be intended to be used in 
> >non-XML document languages that do not have predefined table 
> elements.
> In that case the table properties should be augmented to 
> allow for layout-only tables, in CSS3. The reasoning: people 
> want to do two dimensional layout, tables make it possible, 
> the current table properties cannot be used for the purpose, 
> and after accessibility features are taken care of in the 
> document language, there is nothing wrong with doing 2D, 
> itself. Want to take that up?

I agree with this, but I think that's what the ultimate goal of the box
model is. See my other post for a description of the requirements I see.

> >Furthermore, according to W3, these CSS table related 
> properties DO by 
> >definition assign "actual table semantics to XML":
> >
> >"The following 'display' values assign table semantics to an 
> arbitrary 
> >element:" table, inline-table, table-row, table-row-group, 
> >table-header-group, table- footer-group, table-column, 
> >table-column-group, table-cell, table-caption.
> Not necessarily. This is text from the CSS specification, and 
> so it can be read to mean that we're simply talking about 
> making something look like a table. If it is indeed meant 
> that whatever is marked display:table is strictly equivalent 
> to an HTML table, why are not spans, heading scopes, table 
> summaries and the like included?

They should be. That sounds like a good extension for the CSS3 Table

From WAI: Using HTML tables for layout is bad for accessibility because
they confuse aural browsers, etc.

Now, assume we have an arbitrary XML grammar, with the following


I can use the following stylesheet:
rates {display:table}
title, amount, length {display: table-cell;}
title, length {speak-header: once;}
amount (speak-header: always;}
period {display: table-row;}
rate {display: table-cell;}

Now, if CSS provided a way to express axes for headers, this table would
be exactly equivalent to an HTML table to all CSS-capable browsers. The
browser doesn't have to understand the new XML dialect, it just has to
understand CSS. Without making CSS tables equivalent to HTML tables, an
aural browser encountering a new XML dialect would be lost. (CSS is
still a presentation language, by the way.)
If we accept that aural browsers can use CSS tables in the same way they
use HTML tables, it becomes clear why CSS tables shouldn't be used for
layout either.

Jeffrey Yasskin
Received on Friday, 26 October 2001 14:51:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:59 UTC