- From: L. David Baron <dbaron@fas.harvard.edu>
- Date: Sun, 13 Jun 1999 21:29:29 -0400 (EDT)
- 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 UTC