W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Stephen Ferg's Table Research

From: Leif Halvard Silli <lhs@malform.no>
Date: Wed, 15 Aug 2007 04:26:42 +0200
Message-ID: <194d1bc094245a61ae576dc27066ae4f@10013.local>
To: Ian Hickson <ian@hixie.ch>
Cc: "Ben 'Cerbera' Millard" <cerbera@projectcerbera.com>, HTMLWG <public-html@w3.org>, Stephen Ferg <ferg_s@bls.gov>

On 2007-08-14 05:23:56 +0000 Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 13 Aug 2007, Ben 'Cerbera' Millard wrote:
>> 
>> I've been having off-list discussions with Simon 'zcorpan' Pieters about 
>> header association in tables. "Nested row headers" [4][5][6] seem difficult 
>> to do in HTML with scope="" unless one re-arranges the cells to use 
>> rowspan="" or applies the headers+id technique. As such, I think Ian's 
>> conclusion may need revisiting for this case.

> Some of the tables I've seen discussed in these threads 
> are so complex that I don't understand what they are supposed to represent,

Please back it up with a link, so we know what tables you refer to.
 
> and I'm not blind 

You are not alone.

> -- we probably don't want to encourage authors to write 
> that kind of table in the first place!

You mean, like we should not recommend the FONT element? 

As the FONT element (perhaps) shows: We cannot forbid all that one do not recommend. (And we might not even recommend the same things.)

To specify how one should make tables seems ... _very_ restrictive. We are writing a spec - not a law.

> We have to balance the usability of 
> the language and the ease of implementation with its expressiveness. Our goal 
> isn't to make anything expressible in HTML, our goal is to hit the 80% mark 

80% - again. I don't find 80% in any design principle. 

And you should really try to bring new arguments to the - eh - table.

> that helps most authors while keeping the language simple and approachable, 
> and while making it really easy to Do The Right Thing to make pages that are 
> accessible to everyone. We want to design features that are inherently 
> accessible, not features that require an explicit step to "add 
> accessibility", since most authors won't do that, leaving that kind of 
> feature pretty much dead in the water.)

You «explicit step» what is that? _That_ is a very inaccurate description of what HEADERS is. And it paints and image of what we have in HTML4 that says: it is stupid. Which it isn't.

HEADERS= is no more an explicit step than FOR=.

1. Even in HTML4, we don't need any explicit step. We have the HTML4 algoritms which steps in if we have used TH cells and so on.
2. HEADERS= like FOR=, is being used when containership or the algoritms isn't enough.
3. As well as for compatibilty reasons - like FOR=. 

It is the third variant which constitute an «explicit step».
-- 
leif halvard silli
Received on Wednesday, 15 August 2007 02:27:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:48 UTC