Re: how to deal with TABLE heartburn

This is long.  It takes too long to write a short letter.
I am copying the HC distribution because Dave and Jason are
not the only ones here who have said they didn't see the problem.

to follow up on what Dave Raggett said:

> On Mon, 20 Oct 1997, Al Gilman wrote:
> 
> > I still have a heartburn over the AXES attribute.
> > 
> > I may have time to write up some examples between now and the end
> > of the month.
> > 
> > I don't want to represent this as an HC team conculsion, but I 
> > think that W3C may yet thank me if I can communicate the problem.
> > 
> > How should we proceed on this?
> 
> In the absence of something better, Jason White and I seem
> to be happy with axes together with scope for simpler cases.
> There seems to be two issues as far as I can tell.
> 
>   a) effective ways to associate headers with cells to
>      which they apply which may include other headers
> 
>   b) precisely what such associations mean
> 

100% agreed.

> (a) can be handled from two ends: from the point of view of
> the header cell and from the point of view of cell to which
> the header applies. Scope uses the former while axes uses
> the later perspective. Axes is good for headers which are
> positioned irregularly. Scope is good for common cases.
> 

There is another distinction which figures prominently in my
thinking.  This is the distinction between the dispay axes
and the axes of a conceptual model of the information, which
may have different, or more than two, axes.

The SCOPE attribute clearly operates in display coordinates,
in terms of the rows and columns of the tabular array.

The name AXES and the heuristic explanation about
multi-dimensional coordinate frames suggests a content model, the
abstract coordinates in which one would array the data without
regard for display media.  I visualize this coordinate frame
as living somewhere behind the HTML layer from the User
point of view.

> (b) is tricky in general, however a simple solution may be
> to use class values on either header or data cells, as this
> is possible with the current specification. An alternative
> would be to introduce 3 place tuples which label the association
> between two cells. If the set of labels is small, then it
> may also be feasible to represent such labelled associations
> by using different attribute names for each member of the
> set, where the attribute is provided either with the header
> in which case it names the other cell, or vice versa.
> 

Because of the input from Scott Luebking, I have pretty much
resolved myself to the idea that we will use one class of links
from body cells to connect them with headers that are critical
for that cell.  And yes, I think that CLASS markup can be
used effectively to refine this information and I would look
to try to make experiments done this way happen as part of the
more long-term program.

This leaves me with the objection that the AXES concept is being
stretched too far.  We need to refer to a concrete example at
this point.  In the "Courses in Bath" table, the body cells need
to be associated with the course name of the course they are
telling you about.  Agreed.  This link is needed and can be
marked up with SCOPE or AXES as I have illustrated.

On one level, in display axes, you can say that this defacto
row header is like a coordinate axis.  It is the anchor of
a subarray.  An axis anchors a dimension in a multidimensional
space.  On the other hand, if we construct a display-independent
multidimensional model for the course information, the 
course name is a point and not an axis in that representation.
In the conceptual frame of reference, AXES is a misnomer for
the link from the tutor's name to the course name.

Because I want to develop this notion of a display-free content
model, captured in the HTML markup, in the long-term WAI
engineering program, I see the use of the AXES name and the
hyperspace analogy as being trashed by this attribute which
is, if used correctly to support accessibility, rooted in
display coordinates and when viewed in content coordinates
being applied to things that are not axes.

If we could just rename AXES to KEEPWITH or some more neutral
term that didn't raise content-model expectations, I would be
happy to work with one [inter cell link] attribute in 4.0
together with CLASS and SCOPE and get on with life.

> I feel this is going over the top, and until we have had
> further deployment experience we ought to hang fire. The simple
> unlabelled assocations between headers and data cells have
> at least stood the test of the last 2 years and been shown
> to apply to a reasonable range of cases.
> 

First, I agree that the idea of putting tuples in the HTML
is not justified at this time.

On the other hand, I don't understand the reference to "stood the
test of the last two years."  To my knowledge the great majority
of Web tables have been unusable by blind individuals, not
entirely because of limitations of the HTML format.  I think that
we have too few success stories to point to to claim victory.  We
are at the present projecting what it is going to take to begin
an era of success.  We have reason for measured optimism.  But
the last two years don't illustrate a satisfactory bottom line.

> I hope this exposition will help you to make your ideas
> clearer. We have very little time left, to change the spec
> prior to Proposed Recommendation status, but there will
> still be a chance to introduce changes before it becomes
> a full Recommendation.
> 

Over the long haul it will be more effective to have two classes
of inter-cell links roughly equivalent to what I called TYPE and
CONDS.  I am quite willing to let that be over the long haul
(i.e. not in HTML4).  This still leaves a conflict between
connotations that I perceive in the AXES name and the usage
practice that will make this HTML4 attribute effective as an
access aid.

-- Al

Reference:

Courses in Bath, with SCOPE

http://www.access.digex.net/%7Easgilman/web-access/TABLE/crsbath.htm

Courses in Bath, with AXES

http://www.access.digex.net/%7Easgilman/web-access/TABLE/crsax.htm

Received on Tuesday, 21 October 1997 12:32:54 UTC