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

At 01:59 PM 12/1/99 -0500, Leonard R. Kasday wrote:
>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?

That extension sounds logical to me; as logical as any I have been able to
think up.

I wasn't quite ready to say "That takes care of it."  

Partly because we need to be clear that if one can ask the author, then all
guesses should be checked with the author.  And then reduced to hard code
(i.e. headers, scope, and axis notations) rather than simply leaving it to
the User Agent to repeat the guess algorithm.

The other part is that I would prefer to know what, if any, use has already
been given to nested tables out in the field.  I think that our brains are
logical, but if the consensus of everyone else follows a different logic, I
would like to know this first before putting on my shield and buckler to go
out and convert them to our logic.

Al

PS: Once we embrace that idea, that all headers pertaining to the enclosing
outer cell are pertinent to all cells inside the inner table, then SCOPE
does flow down into the inner table as well.  No need to treat it differently.

>
>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 16:52:59 UTC