From time to time, I get e-mail from people who want to know which style language they should learn: CSS or XSL? As is often the case with simple questions, the answer can get complex. It can be boiled down to a few questions, though:
If you answered "yes" to any of those questions, then you should definitely give serious thought to teaching yourself XSL. Otherwise, CSS is probably the style language for you.
(As a side note, I'd like to exempt XSL Transformations from this discussion. XSLT is potentially very powerful and useful in some situations, and it's attempting to do something which almost requires a complex syntax. I wish that instead of trying to pretend that transformations are part of a visual styling language, it had been split into its own thing.)
I'm sure that more than a few of you are warming up your e-mail programs to send me hate mail right now. I just hope I'll be able to understand it when it arrives. If it's structured anything like XSL, though, odds are that I won't. I remember the first time I saw a presentation on XSL. The presenter took a fairly simple CSS construct, something like making a H1 element red and in a serif font, and showed the XSL equivalent. It was about fifteen lines long, composed mainly of markup, and was not at all easy to follow.
I went up to the presenter afterwards and I said," You know, I like the idea behind what you're doing here, but it seems like this is an awfully complex language. I mean, what you did for a demonstration could have been accomplished in one or two lines of CSS, and it would have been readable. How do you expect people to write XSL?" His response: "Well, we don't. We expect people to use tools to create their styles, not author them by hand, so the fact that it's complex isn't a big deal." Guess who he represented? I'm not going to name names, but it was a small deciduously-related company which specializes in creating tools for Web authors. And he was a member of the XSL working group. Nor was he the only tool vendor representative on that particular group.
People regularly accuse Microsoft of trying to complicate specifications so that only it will be able to support them. While there may be some truth to this, the reality seems to be that however much Microsoft may (and note that I say may) be attempting this, at least people are paying attention to the potential problem. Shouldn't we be more worried about companies which are adding complexity to specifications without anyone noticing?
The styling part of XSL doesn't have to be so convoluted-- CSS has already shown that a styling language doesn't have to be cryptic or even particularly complex in order to be powerful. Now I admit that we're starting to hit some limitations imposed by the simplicity of CSS, but there are plenty of ideas (even some good ones) as to how that can be resolved. I'll also grant you that XSL has more of a feature set than CSS, but I suspect that's largely due to the fact that it was able to use CSS as a jumping-off point. After all, it's easier to translate an existing work and add your own thoughts than it is to write an original work.
The same problems I have with XHTML hold for XSL. It's a cute intellectual exercise to take things like HTML and CSS and reformulate them (with some changes) in XML, but it is useful? More to the point, is it a step forward? I suppose it depends on your point of view. If you think complexity and academic purity is good, then XSL is a godsend. If you're more concerned with styling documents in the real world, then I suspect you're going to find XSL either really annoying, or really irrelevant.