Client-side XSLT

Question

I converted my whole site to XML/XSL and I would like to know all of the current issues with performing Client-side XSLT.

Here are the ones i already know of (from first-hand experience):

• Cross-domain XSL files (this is a security issue and not cross browser)
• disable-output-escaping (this does not work in FF... they consider it a security issue)

Also as for browser support this is all i know of:

• Opera 9+
• FF 1.0+
• SF 2.0 + (i may be wrong on this)
• Chrome
• IE 6.0 +

Any others would be helpful too :)

Edit:

As for the 2nd pitfall there is a decent workaround that lets you pass xhtml to your xsl. It works by actually converting and making sure your XHTML is valid XML and placing it into your XML as XML. Then in your XSL you copy the xml ;) and output it as XHTML.

Answer 1

• Speed: The browser needs to apply the XSLT transformation before rendering the HTML, thus the user will have to wait longer to see the page. The XSLT engines used by the browsers might not be top-notch. On Mac OS X, the browser might freeze while the XML is transformed and cause the "spinning beach ball" cursor, thus the user might punch the screen and injure him or herself.

• Accessibility: What about the browsers not in that set, such as screen-readers? Do those users matter to you?

Answer 2

I found passing parameters to xsltfiles difficult to keep crossbrowsing able. I now support FF and IE but Chrome fell out because of it..

Answer 3

The XSLT file is another object which needs to be downloaded and the browser will only fetch 2 or 3 items in parallel. My experience is that the overall performance (download and generation) is noticably slower.

Also, depending on the complexity and redundancy of the data, you might be downloading much more than you really need to - ie. if the HTML had already been rendered.

Answer 4

On the performance front... consider that the majority of clients these days have 2 CPU's and 2 GB of RAM each, and that most servers don't... Have two CPU's + 2 GB per client that is. So it's certainly logical that offloading the XSLT transforms should improve scalability, and caching CSS + XSLT + JS should reduce overall traffic.

Having said that I've tried using XSLT to produce XHTML containing SVG in the past, and had an epic-fail. The largest page was simply too big (3,000+ entries in an index), and IE uses a DOM to do the XSLT transform, which causes it to start trashing. The same transforms done in xerces-j (on the server, on the same dev box) was about 1000 times faster.

It's high-time the browser-monkeys got with the program ;-)

An interesting discussion. Thanks for raising it.

Cheers. Keith.

Answer 5

i have worked about 1 year at a project where we used xslt+xml-> html (although server-side only)

the major drawback i encountered: there are no good tools for xslt generation which lean towards web developement. no previewing of html. no validation. the resulting xslt was a total mess noone could understand. that was not so much the xslt designers fault, but rather results from the xslt processing model.

the layering between xslt/xml/urls becomes more complicated than it should be. there is no way you could program component-oriented.

often multiple xslt files were needed, this would lead to many downloads on the client-side. otherwise it would lead to massive code duplication thoughout the project.

i would see this as a form of early optimisation. you shoud start by using a "normal" web framework like wicket, jsf, tapestry, gwt etc.., later if it turns out your servers preformance is cpu-bound you might ocnsider rewriting the most often used parts of the apllication that way.

otoh, it has real benefits if you need to provide both an xml api + a html interface.