W3C home > Mailing lists > Public > www-style@w3.org > June 1999

Re: CSS vs XSL, what is going on

From: L. David Baron <dbaron@fas.harvard.edu>
Date: Sun, 13 Jun 1999 21:29:29 -0400 (EDT)
Message-Id: <199906140129.VAA04106@ice4.fas.harvard.edu>
To: mlelist@citec.fi, www-style@w3.org
On Thu, 10 Jun 1999 14:52:36 +0300, Michael Leventhal
(mlelist@citec.fi) wrote:
[ Stephen Deach wrote: ]
> > I refer you also to James Tauber's response to this issue: CSS tags ARE 
> > formatting objects. The 'display' property identifies the fundamental
> formatting 
> > behavior of the element, this is exactly what an XSL-FO does. I would add: 
> > XSL-FOs are simply more general (cover a broader scope), and defined in a
> manner 
> > that has fewer side-effects (interdependencies). If anything, CSS is the 
> > "supercharged FONT tag", XSL at least compartmentalizes the side effects.

I wish to respond in more detail to the charge that CSS, rather than
XSL, is a "supercharged FONT tag."

First, what is wrong with the FONT tag?  It conveys presentation
without saying *why* that presentation is specified.  It doesn't say
whether the enclosed text is a header, emphasis, or just in
my-favorite-color or my-cool-font (or preferred font size).  This
creates a serious accessibility problem by having document structure
that creates style.  Users with disabilities or users browsing with
small or audio devices need to override much of this information.  If
markup that conveys the meaning is clear, then the overriding can be
done sensibly.

This is what CSS allows.  By allowing the interaction of browser
defaults, user preferences, and author preferences, it allows
accessibility and portability.

An XSL stylesheet that uses XSLT and XSL formatting objects can
hopelessly confuse structure and style.  It would be impossible to tell
(if I understand XSL correctly) which style suggestions should be
ignored and which convey meaning.  For example, if the headers in a
document were turned into a table of contents (TOC) at the beginning
and formatting objects were used to give the font size both in the TOC
and as headers in the document, the user agent could not know that the
font size given for the TOC did not indicate meaning, but the font size
given for the headers did.

XSLT transformations to a type of markup that conveys meaning can be
very useful for many aspects of data presentation.  I am not saying
they lower accessibility, since they turn data into its intended
structure for display.  In fact, they could even be helpful, since
preferred structures for display could vary by media type (or be
selected by the user).  For example, MathML logical markup could be
transformed into MathML presentation markup for graphical clients, text
(possibly HTML) such as "1+x^2" for for text-based clients, and words
for aural clients ("one plus x squared").  Similarly, data could be
presented graphically for graphical clients (by transforming to SVG, if
XSLT is powerful enough), in tabular form for text based clients, or in
a linear form for aural clients or small screens.  User agents or users
could then override the style suggestions given in the document when
necessary, without loss of meaning.

However, if these useful transformations are mixed with formatting
objects instead of elements with meaning (such as HTML, possibly with
CSS), they are no longer useful for people using alternative devices or
disabilities.  There is no way, as I understand it, to apply the
transformation without using the formatting objects that it provides
(or throwing them away completely, which would often be even worse).

Maybe I am missing something about XSL.  Feel free to point out any
features that allow for the type of accessibility CSS already has.  I
just don't see them.  Unless these concerns are (or have been)
addressed, I agree strongly with Håkon Lie that XSL formatting objects
are a serious threat to accessibility on the web.  They can be a
problem not only because they can be presented directly (as Mr. Lie
describes) but also because they can be presented indirectly, through a
transformation, and thus make the useful results of that transformation
inaccessible.  It is XSL, not CSS, that is the supercharged font tag.

David

L. David Baron     Rising Sophomore, Harvard     dbaron@fas.harvard.edu
Links, SatPix, CSS, etc.        < http://www.fas.harvard.edu/~dbaron/ >
WSP CSS AC                         < http://www.webstandards.org/css/ >
Received on Sunday, 13 June 1999 21:29:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:59 GMT