Re: AXIS vs. CLASS

to follow up on what Dave Raggett said:

> On Thu, 16 Oct 1997, Al Gilman wrote:
> 
> > If the truth be known, what I really think about AXIS is that
> > it is just CLASS under another name and can be dropped.
> 
> There is indeed a similarity, but I am concerned that not all
> class names are appropriate for grouping headers into categories
> for the purpose of rendering tables as hierarchies etc. This
> would also screw up the simple application of style sheets for
> indicating how headers are to be spoken as you move from cell
> to cell.
> 

I am not sure this is a problem.  The rules about which companion
columns/cells are to be spoken on row-transition, for example,
are not dependent on all the CLASS values present but on the
presence in the CLASS list of tokens that they know they care
about.  The only problem comes when your favorite stylesheet for
table speaking is sensitive to class names that are being used on
the same cells/columns/rows/etc for other reasons because
different class-mark inventors accidentally using the same term.
That is when you have to start rewriting the names as assumed in
the foreign domains and explaining the relationship between the
new symbols and the old (symbol, application) pairs; that's a
local glossary in the current page using some dictionary format.

> This ties into another issue I would like to address, which is to
> provide an explicit way for authors to rank axes. This is important
> for rendering the table as a hierarchy as it determines which level
> of the hierarchy given header groups occur.
> 

On the whole I agree but I want the author to be able to indicate
a partial ordering.  The top priority for the user is that the
browser gives the user the ability to control the sorting
hierarchy governing the list-out.  Giving the author that
capability is nice, but not so important to accessibility.

> One solution is to add an attribute to the table element for listing
> the axes in decreasing order of importance. Lets call this "axes". 
> We now can safely use the class attribute on cells to say which axis
> or axes a given header belongs as we can use the axes list to tell
> which of the classes are axes names and which are not.
> 
> At this point we could even choose to rename the attribute on cells
> that lists the headers that are relevant to that cell, for instance
> "headers" might be a more natural name for this.
> 
> Any comments?
> 

The problem is I don't think we get to the right answer on this
without an analysis which is both broader and deeper.  My concept
of how we should do this is analyze requirements for object
capability, and converge on an object model.  Then determine a
systematic plan for migrating HTML to support an appropriate,
tailored view of that class system.

The kind of generic language construct that one could see wanting
is a DEFINE block -- doesn't have to be called that -- but it is
an invisible composite -- a container restricted to contain
nothing but other [normally-] invisible elements.  In it would be
assertions that get applied collectively as an atom to the
enclosing scope or some TARTGETed domain of appication.

The problem with CLASS values in HTML now is that they only have
spellings.  They have no declaration or ID one can hang further
information on.

In typeful languages like VHDL you have type-qualified references
such as CLASS'length for "the string 'length' were it appears
as a value of the attribute 'CLASS'."  I don't see where we have
that powerful a naming capability in HTML.

You could define [/refine] the semantics of a CLASS value in HTML
if there were the appropriate declarative mechanism.  If that
existed, you would want it to be consistent with declarations for
a variety of purposes.

That is sorta why I am suggesting that in the time available we
let CLASS values be dumb tokens and for those with the capability
to make them smart we give the option to link to an external
glossary that explains usage (defines the classes...).

-- Al

Received on Thursday, 16 October 1997 14:31:23 UTC