- From: Ben Boyle <benjamins.boyle@gmail.com>
- Date: Thu, 16 Aug 2007 00:08:58 +1000
- To: "Robert Burns" <rob@robburns.com>
- Cc: "Ian Hickson" <ian@hixie.ch>, "Ben 'Cerbera' Millard" <cerbera@projectcerbera.com>, HTMLWG <public-html@w3.org>, "Stephen Ferg" <ferg_s@bls.gov>
Looking at these tables a little closer, there is an interesting information structure. I'm not sure it can be captured effectively by HTML (I'm not sure it's needed either, just analysing the table): Look at the balance sheet (3rd table). It's like we have nested sections within the table. There's "net assets" that's broken down into "current assets", "non-current assets" and "liabilities", each either their own heading and totals (footer). It would be interesting to investigate table markup that could support complex relationships within tables like this. It may be a bit esoteric, and can probably be handled through classes for those that need it. In either case it's very important we can clearly associate the headers with the right cells. I think it would be useful to be able to identity the "totals" (footers?) in each section too. I'm going to through a crazy idea into the mix and suggest that <section>, <header> and <footer> may be useful within data tables for this very purpose. I have to confess I don't understand the rationale behind using td rather than th for the row headers. It's a fine line between "data" and "heading" perhaps. On 8/15/07, Robert Burns <rob@robburns.com> wrote: > > On Aug 15, 2007, at 6:46 AM, Ben Boyle wrote: > > > > > On 8/14/07, Ian Hickson <ian@hixie.ch> wrote: > >> ... 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! ... > > > > I agree -- I don't really understand them either. But I don't think > > this is relevant. These tables are designed to communicate with > > experts primarily (e.g. statisticians, accountants, etc.) and when > > they're from a government source accessibility is often a legal > > requirement. > > > > I've needed to publish tables like this and really am looking for > > support in HTML to accomplish this (and I've been pretty confident > > HTML4.01 could handle it, waiting to see where HTML5 goes on the > > topic). Here's an example: > > http://www.disability.qld.gov.au/budget/06-07/mps/financial.html (If > > you dig a little further you can see in 2007-08 the publishers opted > > to use pdf/rtf rather than HTML. You can draw your own conclusions > > from that.) > > These tables are very interesting I think. First of all they look > very straight-forward to me (maybe that's just because I'm an > economist, but they seem simpler than many of the other tables we've > looked at). However, they're interesting to me for several reasons. > They're created to be accessible using both @scope and @headers and > not in a redundant way. They use headers in a fairly simple way (not > a cumbersome way as some may need to do for backwards compatibility). > > If the left header cells were changed to data cells, and the @headers > attribute was removed, the proper associations would still take place > under the HTML 4.01 basic table algorithm. With the current HTML5 > data/header association algorithm, the data/header associations would > be incomplete (though mostly complete) but no @scope would be > necessary. Adding @scope and changing the left header cells to data > cells would create the proper associations in the current HTML draft > algorithm. > > With a sufficiently advanced HTML5 algorithm (not the one we have in > the current draft), the proper associations would take place without > either the @scope or the @headers attributes. Simply by treating the > THEAD cells as global header cells and moving the table segments into > separate TBODY elements (such as income and expense in the first > table and moving the operating surplus to a TFOOT). > > What's interesting to me then that even with an advanced basic > algorithm (one not requiring @headers nor @cope) it still requires > some author know-how and skill to structure the table correctly (not > that its incorrect now, just that it would be correct for the new > basic algorithm). In many cases, authors may find it easier and surer > to simply set the @headers and @scope to get the accessibility > results they want. Trying to give up on those attributes in this case > requires the author know even more than simply setting the @headers > accordingly. This example I think shows that sometimes @headers can > be the simplest way to accomplish the authors goals. > > Take care, > Rob >
Received on Wednesday, 15 August 2007 14:09:10 UTC