You'll still need CSS for fine control over presentation. You could embed the style information in the XSL but I'm sure you can see the maintenance problems with that. When I built websites via XML/XSLT I just used the XSL to convert it to XHTML and referenced separate CSS/JS pages.

Yes, XSL is a sucky language. Designers generally can't grok it.

XML/XSL is possibly the worst templating system - it's both complicated AND requires a lot of obfuscated code to do anything. Generating XML is complicated, it performs very badly, and your designers cannot write decent HTML.

I've been there and seen it.

Mark

Quote:Original post by markr
XML/XSL is possibly the worst templating system - it's both complicated AND requires a lot of obfuscated code to do anything.

Yeah, it seems to have emerged from the "XML is good for representing almost anything" mindset, which XSLT ended up disproving quite effectively. Unless your native data format is XML it seems pointless, as there are usually 101 better ways of injecting data objects into XHTML without the XML step. (I use Kid or Genshi in Python, for example.)

Hmm, I quite like the XML/XSL approach, but of course, 1) I'm a programmer, not a designer so it doesn't scare me so much, and 2) I work on the assumption that web development is always going to suck... Compared to all the other sucky approaches, the XSL one isn't bad at all. So far, it's the least sucky of all the sucky approaches I've seen.

If you do the XSL transform on the server, I can't think of any problems to be aware of. At least, other than the obvious, it requires extra processing, which may or may not become a bottleneck at some point.

I use XML + XSL + CSS for some of the smaller websites I maintain. This has some downsides although I don't think they matter that much. You won't get a designer/content-creator to write XML just like you won't get him/her to write HTML. That's not really an argument against XML though.

Also, XSL is not a sucky language at all, it's just "different". Once you get the hang of it, you can be quite productive with it. I'd even go so far and say that I'd choose XSL over let's say Smarty anytime.

The main reason why I use XSL is because it's so easy to have it output all sorts of different formats like for example RSS/Atom.

And lastly, if you cache the results of the XSL transform, an XML/XSL website can be just as fast as a website that is entirely made up of static HTML files.

Quote:Original post by Spoonbender
Compared to all the other sucky approaches, the XSL one isn't bad at all. So far, it's the least sucky of all the sucky approaches I've seen.

Really? For generating XHTML? I have done it both ways and the XSL way was just extra effort for an additional step giving you absolutely no gain, unless making life harder for designers is a gain (which I could accept!) I just use XHTML templating stuff which gives the designers, or indeed myself, a very accurate representation of what they'll be seeing, without any esoteric declarative transformation phase.

I use templates like these:

That outputs a list of paragraphs. And it can be viewed in a web browser as-is, very easily. Why waste time translating your data into XML, just to have to have something else translate it to something else in turn?

Quote:Original post by Harry Hunt
I use XML + XSL + CSS for some of the smaller websites I maintain. This has some downsides although I don't think they matter that much. You won't get a designer/content-creator to write XML just like you won't get him/her to write HTML. That's not really an argument against XML though.

But you will get them to generate XHTML, which you can plug into. You're never going to get them to generate useful XSL transformations. XSL is a declarative programming language for programmers to change their XML into something pretty. It's the wrong tool for pretty much anything else.

Quote:I'd even go so far and say that I'd choose XSL over let's say Smarty anytime.

That's because Smarty is crap. You can justify pretty much any method you choose if you compare it to PHP.

Quote:The main reason why I use XSL is because it's so easy to have it output all sorts of different formats like for example RSS/Atom.

A decent templating system will support that out of the box. If it can generate XHTML, it can generate RSS or Atom. I'd rather pull the data straight from the objects and put it into the output, rather than build a parallel XML representation out of it and then have to transform it.

Quote:And lastly, if you cache the results of the XSL transform, an XML/XSL website can be just as fast as a website that is entirely made up of static HTML files.

Yet that would also apply to absolutely any other technology you choose to use.