# [web] XML + XSL instead of XHTML + CSS

This topic is 3848 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

My web page generates dynamic web pages. In order to better separate content from appearance, I intend to have the web page generate XML output, and then use XSL to transform that output into an XHTML web page. This way, the entire formatting would be placed into an XSL stylesheet, so I wouldn't need the CSS stylesheet anymore. The transform would be done server-side to circumvent browser incompatibility. Are there any foreseeable issues with this that I am unaware of?

##### Share on other sites
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.

##### Share on other sites
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

##### Share on other sites
Thank you for the input.

My designers output PSD, anyway [wink]

##### Share on other sites
Quote:
 Original post by markrXML/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.)

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
Quote:
 Original post by SpoonbenderCompared 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:
<p py:for="paragraph in paragraphs">  <span py:replace="paragraph">Lorum ipsum dolor sit amet. Contents of the paragraph will go here.</span></p>

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

1. 1
2. 2
Rutin
24
3. 3
4. 4
JoeJ
16
5. 5

• 14
• 29
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631774
• Total Posts
3002274
×