RE: [#293] Summary for tables

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. 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.

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.

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:22:11 UTC