- From: Robert Burns <rob@robburns.com>
- Date: Tue, 14 Aug 2007 01:53:28 -0500
- To: Ian Hickson <ian@hixie.ch>
- Cc: Ben 'Cerbera' Millard <cerbera@projectcerbera.com>, HTMLWG <public-html@w3.org>, Stephen Ferg <ferg_s@bls.gov>
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, Rob
Received on Tuesday, 14 August 2007 06:54:00 UTC