Very initial TABLE reactions

to follow up on what Dave Raggett said:
> 
> The most important issue for me now is getting closure on
> accessibility mechanisms for tables. I encourage people on
> this list to review:
> 
>    http://www.w3.org/TR/WD-html40/struct/tables.html
> 
> My goal is to ensure that both HTML4 and CSS2 provide effective
> support for rendering tables to speech and to Braille. Your
> expertise in reviewing the current proposals is essential.
> 

This is just a rapid response quick look.  But I want to expose
you these ideas before we lose you if I can.

There are several categories of functionality where I think we
might want to explore changing the table capabilities from
what we have in this draft.

Summary: is restricted to a text string.  would better allow a
hypertext block.  Guide to the table with jump possibilities.  We
can put the jump targets in the table by embedding A tags in the
cells.  But we can't associate a normally-hidden guide with links
with the table as is.  Very analogous to what I hear Jason saying
about sensitive maps.  I have to admit I have been wondering about
hiding more general resource definitions [normally hidden hypertext
blocks] in the HEAD.

Cell readout:  what one would really like is a "cell readout pattern"
which is a roughly-sentence-scaled text macro which has variable
substitution capabilities.  Variables would refer to the cell content
and to HTML elements the cell is associated with by semantic 
relationships.  Trying to do this algorithmically is bound to come
out less natural than letting the author state what a typical cell
tells you.  

Axis association: I haven't fully understood the proposal.  But
it seems that it allows a cell to be explicitly tied to
independent variables but not to a generic descriptor for the
dependent variable of which the cell content provides the value.
I think that in lieu of AXES we want two classes of link-to-ID
attributes to distinguish links to other TH and TD cells.  
One classic pattern is that the cell readout is 

	The $outnam of the $innam $inval is $outval.

	Here the typical tabular presentation is

		$outnam is a TH at the head of the column
		$innam is a TH at the head of column 1
		$inval is a TH or TD in column 1 and same-row-as-self
		$outval is the content of self, the current TD.

The link from self to $outnam is a qualifier link, to $inval is
a selector or key link.  Some other names for this distinction
from other disciplines:

	selector		qualifier
	abscissa		ordinate
	key			field_def
	covariant_axis		contravariant_axis
	whole(/part)		gen(/spec)

For efficiency, it is possible that some of the patterns of
association would want to be able to be declared in a COL or TR
and inherited into TH and TD.

SCHEME: In general one would like to be able to link a table to a
more-semantic layer and not just a less-semantic style of
presentation.  c.f. the SCHEME for META.  An ability to link a
specific table to a data dictionary or information model would be
a positive capability, and if we have to hide all the rest of
this there, so be it.

Explicit order-of-reading markup:  My kneejerk on this is that
it is desirable, and wondering if we should address this by allowing
LINK and META in the BODY where they would by default qualify the
immediately enclosing container.  Then we could put a

<LINK rel=read-after href=some-TD-ID> in a TD and it would be
known.

-- Al Gilman

Received on Friday, 26 September 1997 12:57:55 UTC