XSL Has Nothing New for the Web
May 20, 1999
The major justification for XSL is that it will support better specification of printed page layout than is now possible with CSS. In other words, XSL has little or no relevance for virtually all types of documents on the web today. The web is not about paper documents. Page composition will not even occur on the Web as it is a notoriously computationally-intensive process. There are many solutions to page composition available today; the sole advantage of XSL would be that it allows the handful of people that design page layout processes to use the same language both for producing printed pages and for producing web pages. However, the nature of the layout discipline is dramatically different. Frankly, people that design page layout processes will have no difficulty creating a CSS stylesheet for the Web and an DSSSL stylesheet for paper, one of the solutions which is already in place today.
A more important point is that XSL, as a web page style language, is an enormous unknown in terms of processing efficiency. It is relatively straightforward to write down on paper a specification that not only slices and dices but also cooks the turkey and sends out your dinner invitations. But ... will it work, can it be cleanly implemented and maintained, how much memory is it going to use, how fast will it be? These things are not known for XSL and good professional opinion says it is going to be a dog. CSS is trim and has been shown to be efficient.
Other than printed page layout, XSL has very little to add to CSS formatting capabilities, perhaps a point or two which would justify a few modest additions to the next revision of CSS, but surely not an entirely new language. Improved selectors on the element hierarchy and attribute values are the major items in this area.
The fact is that the powerful styling capabilities of CSS, including hierarchical and element selectors, floating, absolute and relative positioning, generated content, counters and autonumbering, and table formatting, have not been experienced either by the general web community or the XML community. I know this because some of these features have only appeared in the mozilla browsers as recently as two weeks ago. We just now have the ability see what CSS can do - and it is going to change the world view of a whole lot of people. May I be so bold as to ask how much real world experience with CSS2 the working group designing XSL has? Is this not a reasonable prerequisite for designing a new language which better addresses the needs of web developers?
XSL is not, of course, just a style language. It also supports tree transformations, the mantra of XSL community having been that transformation and styling were inseparable processes. In fact, they are not inseparable and even some XSL advocates have begun to call for a clean separation between the proposed transformation language and the formatting language. The fact that interests us here however is that there already exists a way to do tree transformation that adheres to a W3C Recommendation today. It is called the Document Object Model (DOM) and can be used in browsers now through its binding to JavaScript and other languages (Java, C++, Perl, Python).
In effect the XSL advocates are setting up a straw man when they compare XSL to CSS. The valid comparison is between XSL and CSS+DOM, the environment in W3C Recommendation compliant browsers today. The DOM allows full access to and manipulation of the document tree. There is no operation which can be accomplished in XSL which cannot be accomplished in the DOM. This is a fact which no XSL advocate can deny. XSL advocates, of course, will state that they "like" their language better. But the critical fact to retain is that XSL transformation does not add a single capability beyond what can be accomplished without XSL in DOM-capable browsers.
When compared to the DOM+CSS, XSL does not solve any Web-related problems that the current W3C Recommendations do not adequately handle. What is the Big Deal indeed?