The "supercharged FONT tag": CSS vs. XSL

["L. David Baron" <dbaron@xxxxxxxxxxxxxxx>]

[ I originally posted this (plus a few typos) to www-style, where the
XSL vs. CSS debate didn't seem to catch on.  I was encouraged to post
it here, since more of the people involved in the debate seem to read
this list. ]

On Thu, 10 Jun 1999 14:52:36 +0300, Michael Leventhal
(mlelist@xxxxxxxx) 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
the markup has clear meaning, 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 these transformations turn data into
their 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@xxxxxxxxxxxxxxx
Links, SatPix, CSS, etc.        < http://www.fas.harvard.edu/~dbaron/ >
WSP CSS AC                         < http://www.webstandards.org/css/ >


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list