RE: [#293] Summary for tables

[Michael -- please ignore the one I accidentally sent just to you.  This has
been updated and should supercede that message.  - Al]

Summary:

The ideal plan is to come up with the ontology that works for disability 
access,
get that implemented in the schema and syntax of XHTML 2.0, and retrofit those
categories in HTML4 derivatives for down-level compatibility by specializing
existing element types with 'class' values.

I would argue against Phill's device of using a reserved keyword in 'summary'
as the code for a subtype of TABLE.

I have vivid memories of Mark Hakkinen saying quite emphatically, "DON'T ask
us to parse attribute values!"  Well, I will make an exception for IDREFS
and CLASS because their type is "list of foo."  But looking in a SUMMARY for
words, and then for one of those words to be a reserved keyword, is the
sort of language extension that we would do well to stay away from.

CLASS is already in the language as a sequence of tokens.  We can work with 
that
if we want to mark subtypes of TABLEs.


At 09:21 AM 2003-06-11, you wrote:
>I'm not sure about using the "class" attribute to indicate layout tables.
>Class is used (and as far as I know primarily intended) to hook CSS to HTML
>documents, so we would be defining a CSS class that the author has to use
>and work with. What if they have two kinds of layout tables (maybe a
>navigation bar table and a content table) and want to assign separate CSS
>classes to them? In theory you can assign multiple class values to an
>element by using a space-delimited list, but last time I checked mainstream
>browser support for that did not exist.

Come again?  Where is the evidence?  Would be news to me.  Of course
I have to admit I don't mess with mainstream browsers much.

>Even if it did, it muddies semantics
>to have some class values for CSS and some class values providing a
>different kind of identification of the element. Also, unless the convention
>were to become extremely widespread it would not offer much practical
>benefit. I have the same concern about using the keyword "layout" in the
>"summary" attribute as well. It could be useful to some tools but, not being
>a part of the HTML spec, wouldn't be implemented widely enough to do much
>good.

Boy, do we need to have a good, long talk about this one.

The thinking at the time of the accessibility review of HTML4 was
that 'class' was for universal categories, and not screen-specific
categories.  Of course this is not how it is primarily used, but that
is true of all formats on the web and off.

In terms of 'separation of content from presentation,' 'class' was
supposed to give us a capability to express a universal category and
the style rule was to go from the universal category to a medium-specific
presentation.

The problem with 'class' it that it is an opaque token.  It comes with
no definition other than the stylesheet that uses it.  This is not
how it was intended to mean, but in practice without additional functionality
beyond the stylesheet dependency it doesn't get used for anything more.

But "muddying the semantics?"   No.  It is the visual presentation that
muddies the semantics.  'Class' was there to give you space to de-muddy
the semantics.  The visual presentation is not separate from the universal
semantics, but a blend of universal meaning and visual effect or metaphor.

If we want to cave on how to use 'class,' then the distinction between a
TD and a TH is in the same category.  Get used to it.

>I don't think we can make "class" or "summary" attribute values part of the
>HTML spec, and therefore we can't require them in WCAG. We can recommend
>them, and I'm ok with that, but I question its utility. As a tool developer
>I might be expected to favor any kind of easily machine-detectable
>differentiation, but unless I can expect that differentiation to exist on
>just about any page I analyze, I still have to fall back to other methods. I
>would love to see the invention of a <layouttable> element, or maybe a
>"type" attribute for <table> that defines two values, "layout" and "data".
>If those were part of the spec then we wouldn't have to worry about language
>issues, mixed semantics, inconsistent implementation, etc. (as much). But
>given the momentum behind current use of the <table> element I'm not sure
>that's a practical suggestion either.
>
>So in summary, I think we can suggest these uses of the "summary" and/or
>"class" attributes if we want, but I'm not sure what it gains us, and I
>don't think we can require them as part of WCAG conformance.

I do think that you can require them as part of WCAG conformance.  It
does not break a contract with the HTML specification.  I have recently
posted somewhere else stating that one needs "three good reasons" to
go into the domain of the specification and tighten it, but taking an
attribute that is defined to be a collection of tokens and defining
token values is an appropriate arm's length extension mechanism.

Al


>Michael
>
> > -----Original Message-----
> > From: John M Slatin [mailto:john_slatin@austin.utexas.edu]
> > Sent: Wednesday, June 11, 2003 9:00 AM
> > To: jasonw@ariel.ucs.unimelb.edu.au; Al Gilman
> > Cc: WAI GL (E-mail)
> > Subject: RE: [#293] Summary for tables
> >
> >
> >
> > Jason's proposal to use class="layout" to distinguish layout tables is
> > intriguing.  What implications does this have for user agents?
> >
> > John Slatin, Ph.D.
> > Director, Institute for Technology & Learning
> > University of Texas at Austin
> > FAC 248C
> > 1 University Station G9600
> > Austin, TX 78712
> > ph 512-495-4288, f 512-495-4524
> > email jslatin@mail.utexas.edu
> > web http://www.ital.utexas.edu
> >
> >
> >
> > -----Original Message-----
> > From: Jason White [mailto:jasonw@ariel.ucs.unimelb.edu.au]
> > Sent: Tuesday, June 10, 2003 8:19 pm
> > To: Al Gilman
> > Cc: WAI GL (E-mail)
> > Subject: Re: [#293] Summary for tables
> >
> >
> >
> > Al Gilman writes:
> >  >
> >  >
> >  > This comment from Phill Jenkins:
> >  >
> >  > The summary attribute was not discussed in the June 9th
> > proposal.  It
> > is  > the one attribute unique to layout and data tables that could be
> > used to  > help confirm that, in fact the should's and must's
> > have been
> > followed and  > in fact this table is or is not a layout table.  The
> > convention I have been  > proposing is to use the keyword "layout" in
> > the summary attribute text.
> >
> > Problems with this proposal:
> >
> > 1. It is language-specific (ie., English only).
> >
> > 2. The contents of SUMMARY are meant to be presented to the user, not
> >    interpreted by the user agent and we shouldn't violate this
> >    expectation.
> >
> > 3. There is a feature of HTML/XHTML designed exactly for the intended
> >    purpose, namely the CLASS attribute.
> >
> > Proposal: CLASS="layout"
> >
> > Some have argued in the past that we shouldn't attempt to establish
> > conventions for the use of the CLASS attribute, as its semantics are
> > intentionally left open by the HTML and XHTML specifications.
> > A parallel
> > case can be mounted, however, with respect to SUMMARY - the original
> > proposal would partition the set of SUMMARY values into two subsets
> > according to whether or not they contained the word "layout",
> > and would
> > then attach specific semantics and behaviours to summaries in
> > which the
> > word appeared. If we are going to set expectations for developers
> > regarding the semantics of attributes of the TABLE element I would
> > prefer to constrain CLASS than to constrain SUMMARY.
> >
> >

Received on Wednesday, 11 June 2003 09:59:33 UTC