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

Re: Stephen Ferg's Table Research

From: Robert Burns <rob@robburns.com>
Date: Tue, 14 Aug 2007 01:53:28 -0500
Message-Id: <33AEE900-8525-4C94-9F23-FB4F99BADFC5@robburns.com>
Cc: Ben 'Cerbera' Millard <cerbera@projectcerbera.com>, HTMLWG <public-html@w3.org>, Stephen Ferg <ferg_s@bls.gov>
To: Ian Hickson <ian@hixie.ch>

Hi Ian,

On Aug 14, 2007, at 12:23 AM, Ian Hickson 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.
> I intend to study the issue of how to link header cells and data  
> cells in
> detail when I get to the relevant wiki page once I start going  
> through the
> issues in the wiki. So yes, I agree, this will definitely be  
> revisited.
> (There are many issues here beyond just whether any particular  
> table can
> be expressed in markup. 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, and I'm not blind -- we probably don't want to encourage
> authors to write that kind of table in the first place! 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 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.)

Just so its clear, its not just a matter of restricting tables to a  
certain level of complexity. Even if we did that, the current  
algorithm wouldn't work for many tables in the wild. In addition,  
much of what the current algorithm accomplishes should not even  
require @scope (except in rare circumstances). You might want to take  
a look at the HTML 4.01 algorithm to see what it does without @scope  
or @headers set (the basic algorithm that is). Keep in mind also that  
tables are often specialized and so being sighted may not be enough  
to understand the meaning of a table. There's a large body of  
literature that often lies behind complex table, so its not your own  
short-coming if you don't understand some of these tables.

On the other hand, the idea of trying to limit authors to tables of a  
certain complexity sounds to me like a recipe for disaster. For one  
thing, there's little control we'll actually have over authors. We  
could say things like users must not do blah. But then there will be  
so many other blah's we hadn't considered that authors will do  
instead (and as Ben's research reveals there's certainly a level of  
complexity out there beyond what the current draft algorithm can  
handle).. So authors will find a way to make tables complex whenever  
they need a complex table to do the job. Otherwise they would be  
forced to turn to multiple tables which often is a much more  
complicated exposition to follow than a single complex table.

Finally, from Ben's and my research into this, it should be possible  
to construct a better algorithm that covers many more cases than the  
current one. I would say this could be done even without needing  
@scope or @headers. However, unless we can come up with some better  
features for the language (and no one has suggested any or even  
offered some research leads yet), we will likely need @abbr, @scope  
and @headers simply to make some tables accessible.

Since these attributes are basically costless to maintain in the  
draft (and needed for backwards compatibility with existing  
implementations), it would make no sense to target HTML5 at a lower  
level of expressiveness than we currently have with HTML 4.01 Also we  
should be careful about focussing too much on ease of implementation.  
Nothing we've discussed here is rocket science. Sure implementation  
takes time. However, there are many open source community members  
that  will welcome the opportunity to  implement these and other  
features (as has already happened).

Take care,
Received on Tuesday, 14 August 2007 06:54:00 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:19 UTC