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

Re: Stephen Ferg's Table Research

From: Ben Boyle <benjamins.boyle@gmail.com>
Date: Thu, 16 Aug 2007 00:08:58 +1000
Message-ID: <5f37426b0708150708r3f24379o70fe7cd7fc709725@mail.gmail.com>
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

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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC