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."

#25 Re:

by JavascriptDOMTedious

Tuesday May 25th, 1999 2:19 PM

You are replying to this message

Michael, Please explain to me how I can achieve multicolumn output "newspaper" style using CSS/JavaScript only, that is independent of screen size and fonts?

The only way of currently achieving this is with Netscape's <MULTICOL> tag, which has no corresponding CSS model.

TABLEs don't cut it.

Right now, online magazines try to similate this with tables and chopping the article up by hand. It is not something web developers want, it is used by a *lot* of online webzines. Smaller columns are easier to read for people.

If I want to publish an article article in multicolumn format, ala LaTeX's multicolumn mode, or like I can in Word, or PDF, how do I do it?

In all of your responses, you still haven't answered the question as to how DOM manipulation will be editable by WYSIWYG editors.

CSS selectors aren't even powerful enough to generate a table of contents, index, or cross-reference. CSS also cannot handle XLINK.

So the question is, how will I edit my table of contents in an editor if it is nothing but a bunch of getElementsByTagName calls followed by script comparison statements?

There is a very real need on the web to generate multicolumn output, justified output, tables of contents, cross references, indexes, glossaries, sorted output.

Your assumption is that XML documents will be primarily tailored for display. That is, the flow of the structure will correspond mostly to the flow of blocks in CSS.

But this is clearly bogus when you look at CML, CDF, RDF, XMLEDI, OFX, OBI, OSD, and all the other XML formats that have been defined.

If all you have to display XML is CSS, you end up writing XML DTD's that are more like HTML with the tags renamed. Ho-Hum.