Re: techniques for tables (clarifying how to handle nested tables for the ER group)

Regarding nested tables

I agree that scope doesn't cover case of nested tables.

However, each cell has a "headers" attribute which is a list of 
id's  (separated by spaces).  Since an id can be anywhere on the page, it 
allows a cell in a nested table to refer to a cell in an outer table.

Also, regarding algorithms, there is already an algorithm

http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.4.3

to deduce what would have been done by scope or headers.  This algorithm 
can be extended by recursively including the deduced headers of the 
enclosing cell.

Does that take care of it?

Len


At 01:30 PM 12/1/99 -0600, you wrote:
>[Distribution note:  I am sending this separately to ER-IG, GL, UA, PF, and
>CG lists because it touches all their turf.  That is too many to
>cross-post.  Consult your chairs for how we coordinate follow-up.]
>
>At 10:23 AM 11/29/99 -0500, Wendy A Chisholm wrote:
> >hello,
> >
> >in the Evaluation and Repair Tools working group we have been discussing
> >how to evaluate and repair tables.  Particularly, nested tables.
> >
> >if nested tables are used to present data, is there a way to associate the
> >cells in the inner table with header cells in the outer table?  I would
> >assume that axis and headers could work  across tables (if a UA was built
> >that way).  However, in HTML 4.0 the only values for "scope" are row, col,
> >rowgroup, and colgroup.  so, it seems that "scope" could *not* be an inner
> >table.
> >
> >Nested tables seem less of a problem for layout tables. I propose that the
> >evaluation and repair is to handle each table separately, like Mark Novak's
> >HelpDB tool.
> >
> >--wendy
> ><>
>Cool!  This raises all kinds of dust.
>
>First, we need to distinguish the authoring scenario from the repair
>scenario where one can't take guesses back to the author for confirmation.
>
>Second, it seems to me that the ER community, that is to say people
>actually implementing authoring tools and accessibility-aiding gateways
>(communicating among themselves via the ER groups) should take the lead in
>refining guessing algorithms.  This should be done based on what pages on
>the web are actually like, and what form of prompting authors actually
>respond well to.  So: for guessing algorithms, ER should lead and UA WC
>etc. should follow.
>
>Now for some details:
>
>In the authoring case, where guesses are used to propose interpretations
>for the author to confirm, it should be clear that the end result is
>explicit header-linkage markup using headers, scope, and axis attributes
>until there is not room left for the user agent to have to guess at
>anything.  The header associations should be presented to the author in a
>prompt something like what Len is talking about coding.
>
>The optimization criterion in the authoring scenario is least author effort
>to get to an agreed definiton of what headers go with what data.  If you
>don't guess at all, the author has to work too much.  If you guess lots of
>wrong stuff, the author has to work too much.  The happy medium takes
>testing with authors and in fact is probably good that this should be
>policies that are trainable or settable by the author so that they can be
>bent to the author's interpretation of how to use tables.
>
>In the pure repair case, the guessing rules are popssibly different from
>the rules used if one can ask the author to confirm.  The problem is how to
>put the user in control of how much guessing gets applied to what table.
>
>Warning:  There is a big issue here where I have been asleep at the switch.
>  This is that RDF is indeed already a W3C recommendation, so the use of RDF
>as the medium for annotations which are:
>
>a) advisory in nature, because they are
>b) from a third-party source and not the document author
>
>
>is technically superior and hence support for some such encoding should be
>on our list of things we want UAs to implement and future content
>guidelines to explain.
>
>Small GL issue:  Do we have examples of how to use header-threading markup
>together with nested sub-tables?  How to interpret the markup?  I guess
>that the latter is UA stuff.  But they should agree.  Authoring tools
>should produce explicit header threaded markup without reliance on guessing
>algorithms.  User agents should at minimum interpret the explicit header
>threading markup and for extra credit should implement guessing algorithms.
>  The question is the status of implementing RDF which may contain
>third-party advisory interpretation of the usage.
>
>Larger GL issue:  Deciding between RDF annotations vs. using the
>change-tracking markup available in HTML to indicate what markup is changes
>introduced by guessing in the gateway, vs. other options which people may
>think of.
>
>Large UA issue:  What support for RDF do we ask for?
>
>Al
>
>

-------
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP, and
Department of Electrical Engineering
Temple University
423 Ritter Annex, Philadelphia, PA 19122

kasday@acm.org
http://astro.temple.edu/~kasday

(215) 204-2247 (voice)
(800) 750-7428 (TTY)

Received on Wednesday, 1 December 1999 13:56:47 UTC