The XSL Challenge

Friday May 21st, 1999

C. David Tallman has news of an interesting article at In it, Michael Leventhal of CITEC (the group creating DocZilla) takes off the gloves and challenges XSL to best XML/CSS/DOM in a competition of functionality/usability in the web application space. Interestingly, Mozilla plays an important role in the contest. From

"Anything XSL can do in the Web environment, I can do better using technologies supported by current W3C Recommendations. Of course, what is 'meaningful' in the Web environment is open to a variety of interpretations. Therefore, the subject of the challenge should be one that the XSL camp and I agree is meaningful. I am also ready to make this bet a little bit more than an academic exercise. If I lose, I will pledge that I, and my crack mozilla development team, will assist in implementing XSL in the mozilla open source project. If my opponents lose they will agree to desist from XSL advocacy, vote against an XSL Recommendation if they are members of the W3C, and will join me in calling for full, flawless, and unequivocal vendor support of CSS1 and CSS2, DOM Level 1, and XML 1.0 as the very first and top priority of the web community."

#29 Re:The XSL Challenge

by JavascriptDOMIsTedious

Tuesday May 25th, 1999 4:06 PM

You are replying to this message

Well, it happens that for people who's native language is primarily oriented left-to-right and up-to-down, that having smaller columns is easier to read. Our words are primarily oriented horizontally and it is easier to read a sentence if your eyes don't have to travel very far left to write.

If you were right and multicolumn text isn't easier to read, then why does every print publishing house in existence use multicolumn output, OR, fonts or page sizes smaller, that you are effectively looking at a single column (ala paperback)

Consider the following reductio ad absurdum: Imagine an essay that is printed out on a wall chart so that sentences are 2 foot wide. Now imagine one where sentences are 2 inches wide, but the wall chart is 2 feet high. What's easier? Reading very long sentences left to right, or reading small sentences up/down?

Even if you don't personally think it is needed, the fact remains that *you* are not the audience. The audience is everyone else, the real world, that still uses multicolumn.

Furthermore, my argument doesn't just rest on multicolumn output. I personally, don't know much more amount XSL's flow objects. I am more interested in transforming documents. I was just using multicolumn as an example of why XSL's flow objects alone are something people should consider adding to CSS3, even if you don't like the transformation aspects.

CSS lacks transformation abilities. It can only display or not display something and change the way it looks. It cannot reorder the structure of a document.

It cannot even do something simple like generate a table of contents or glossary. To do that, you would need to write Javascript to scan the whole document and build them in a DOM tree, which is tedious like I said. It also means everyone reinvents the wheel for what should be a very common operation. (scaning and matching nodes)

Finally, the whole debate assumes that XML documents are being published in the structure that they will ultimately display in, with just CSS window dressing.

I beg to differ, and if that is the class, I fail to see the point of XML. I think XML's real value is not reinventing HTML, but in encoding human knowledge: buying decisions, ecommerce, supply chain, medical records, knowledge management, ontologies, mathematical expressions (MathML), CAD, gene sequences, etc etc

These types of documents won't work with CSS display at all.

Even RDF won't, and the fact that Mozilla needs a specialized Widget to handle it is a testament to the problem.

XSL would have no problem turning a flattened RDF graph into a tree for display.

IMHO, CSS display is low hanging fruit. CSS needs to work, it needs to be perfected and laid as a foundation. CSS flow objects need to be harmonized with XSLFO. But, CSS alone is not enough to do all the work of displaying XML, and using Javascript is just a hack to accomplish it.

I really sense something else at work here. I sense backstage politics. I sense that CSS is Hakon-Lie's baby, and XSL is not. In fact, XSL is more Microsoft territory and MS was first out of the gates with an implementation.

So is not some of this anti-XSL hysteria related to Microsoft?

Consider the statements: "XSL has set the web back 2 years" How can something which is not used BY ANYONE, and not supported by any browser that ordinary users have, set the web back?

Sheesh, it hasn't even been released yet and people are proclaiming the end of the world.

Maybe MozillaZine feels that Mozilla will be upstaged by MS in the developer mindshare by using XSL to do an end-run about CSS. For example, Mozilla will proclaim "Our browser has the only compliant CSS implementation..." and by that point, web developers will be saying "who cares, XSL is where it's out now. CSS is legacy. " Is that what is driving this fear and hysteria?

If anything, Gecko will have a head start on any XSL implementation, since they can map most of XSL's style objects directly to CSS blocks. Then all they'd have to do is figure a way to extend the engine to handle the additional ones.

I would hope that Mozilla ends up supporting more W3C/IETF standards than IE. Like P3P, XSL, OSD, SVG, MathML, WebDAV, SMIL, CSS2, etc.

I feel this is the better scenario, rather than crying "wah! please don't let MS create any more standards that we have to support"

If Open-source is so great, Mozilla should be able to support more than IE5 does.