mutiple class tokens and intersection selectors -- what's the issue?

** summary

The HTML capacity to have multiple super-classes cited in the 'class' 
attribute of an element
is something that would make sense to advocate in accessible 
web-design techniques.

Authors may not be eager to use this capability if the implementation 
is uneven.

Information is sought on

- current live web content systematically using multiple 'class' tokens.

- any work-around techniques to deal with known broken 
implementations while preserving some
of the value of multiple-class markings as would be available from 
up-to-spec functionality.

** background

The HTML 4 language is designed with an extension feature known as 
the 'class' attribute.
http://www.w3.org/TR/html401/struct/global.html#adef-class

Because CSS selectors can select on attribute values, and there are 
no limitations on the [CDATA]
tokens used in this list of tokens, this is widely used as a place to 
put information that
controls the application of classes.

A test to ensure that implementations do the right thing when the 
'class' attribute contains
more than one (space separated) tokens is given by
http://www.hixie.ch/tests/evil/mixed/multiclass.html

A somewhat out-of-date compilation of test results is available at: 
http://www.hixie.ch/tests/tesremas/listresults.pl?ID=WBT&mainSortV=-127&mainSortH=&mainMinTests=1&mainPivoted=&mainTrimmed=on&legendSort=

This shows that there is some shortfall in the support for this 
capability in CSS implementations.

** analysis

For software acting after the author has left the scene to make good 
decisions about how to re-style some
content, it should have the content classified under some system that 
it understands.  If the original styling is based on selectors that 
key off terms understood by both the author and the re-styling 
processor, then it
is easy for the re-styling processor to understand how to adjust for 
the user's preferences or needs while still being sensitive to 
distinctions in the content.

A re-styling processor may be fully automatic in middleware or be an 
interactive process combining the user's mainstream and AT user agent 
software initializing the interface binding, followed by interactive 
techniques to deal with weak spots in that initial binding.  The 
initial binding could be based on rules of thumb and general user 
preferences.  The 'try harder' techniques could then involve the user 
interactively drilling down into occasional ill-styled content, or 
re-tuning the current formatting preferences to make this patch of 
content work better.  In any case, the author is gone, and the 
ability to set alternate policies, that is to say systematic patterns 
of re-styling, depends on how much can be inferred from the markup in 
the content.

For the class vocabulary to be understood by the re-styling 
processor, it should be comprised of widely and frequently used 
terms, perhaps standard.  For this, it helps if there are fewer 
terms.  It is much easier for a vocuabulary of a few 
widely-recognized terms to generate enough different sub-classes to 
control the many variations of styling if term combinations, and not 
always single terms, are used to key the styling decisions.

** specific questions

- are people aware of multiple-class use in production content?  Where?

- are people aware of techniques developed to use multi-aspect 
classes and at the same
time work around bugs in browser implementations of the multi-class capabilty?

Received on Monday, 19 July 2004 16:22:19 UTC