Digital Web Magazine

The web professional's online magazine of choice.

An Introduction to Client-Side XSLT: It's Not Just for Server Geeks Anymore : Comments

By Ken Westin

November 17, 2004

Comments

Mark

November 18, 2004 12:34 AM

Thx Ken, it’s about time.
we were thinking about using client-side xslt for a cms-gui, where you can confine browser-support.
any ideas about browser support, anybody?
maybe some pretty link to a pretty table with browser implementation and bugs?

BugTomek

November 18, 2004 1:24 AM

Client-side XSLT is now supported only by Mozilla browsers. Safari (and Konqueror) will have it with next release. According to this article Opera will not support it. But this article is 5 years old, so who knows, maybe something changed in their camp by the time. Anyway it’s seems we’re have to leave it on a server-side, which isn’t in my opinion so bad idea. Actually it’s the only option if we want (and we want) our pages to degradade gracefully in older browsers.

Benjamin Lupu

November 18, 2004 1:31 AM

Bonjour,

First, Ken thank you for this article. It is simply clear. I have used client side XSLT for almost 2 years now and what you wrote reflects exactly my experience.

Regarding compatibilities, I rely on IE6 (which comes with MSXML4) and Mozilla 1x based browsers.

However, please remember that at least with Mozilla, it is difficult to build a complete site with XSLT notably because sometimes Javascript has problem to follow (eg. browser’s history management).

A useful tip : Microsoft provides extensions to IE in order to see results of the XSLT transformation (as view source gives you the XML tree).

http://www.microsoft.com/downloads/details.aspx?FamilyId=D23C1D2C-1571-4D61-BDA8-ADF9F6849DF9&displaylang=en

At last, here are 2 other great things related to our topic : – Client side XSLT transformations done with Javascript. It allows to generate XHTML fragments from XML (let’s say a div for example). – XML Sockets which allows to send and retrieve XML from the web when the page is already loaded.

Special note to Mark : using XSLT for CMS is what I have done for my company notably for previews.

Best Regards.

- Benjamin Lupu

Phil Baines

November 18, 2004 2:37 AM

[Just posted this on the front page, but I realise that it is more apt here. Sorry for the double posting.]

It’s good to see DW drawing some more attention to XML/XSLT. I have been using it on and off for years now, and my company are now using it as the backbone to a new templating engine that will run on our new site.

I have believed for a while that this is the next logical step in the seperation process. As can be shown in this entry on my site.

Iva Koberg

November 18, 2004 3:57 AM

+1 that it’s a pleasant surprise to see an XSLT article on DW. I’d probably fall into the “server geek” category as we prefer server-side XSL transformations (due to the limitted client-side XSLT browser support), but regardless of how you get started – XSLT is worth learning.

In addition to the power and flexibility XSLT gives you, storing content in XML allows you to add more semantic meaning and enables optimal content reuse.

So for example, you could break up author into first and last name elements and choose to display “LastName, FirlstName” on one page and “FirstName LastName” on another. We usually transform the needed rich semantic markup into (X)HTML replacements like div class=“author” or span class=“last-name” to end up with clean (X)HTML and cleaner, more meaningfully marked up, completely divorced from presentation XML source.

Richard

November 18, 2004 4:18 AM

The penny has finally dropped for me. Especially after reading the article linked to in Iva Koberg’s comment. I’ve been wondering what the point in producing a website in XML using XSLT is. Having gone from HTML:no CSS to HTML:CSS to XHTML:CSS I can see the benefits of taking it one step further and separate content from structure from design, rather than just content/structure from design. This will help cut time spent redesigning the site in future years when the need is called for by the company. A useful and stimulating article.

Joshua Porter

November 18, 2004 4:36 AM

Thanks for the good introduction, Ken. I’ve used server-side xslt for a couple years now, and I’m anxious to start on the client side. Can you say anything more about the current pitfalls of client-side design? (like why we might not move over yet?)

Small Paul

November 18, 2004 6:06 AM

Very cool article. The client-side perspective did give me a jolt. ‘Tis true: IE6, Mozilla and Safari a) are very pervasive, and should totally dominate the browser space within a few years, and b) support client-side XSLT. The advantages of storing content as XML are, as you clearly communicate, significant.

As mentioned above, in answer to Joshua’s question, client-side XSLT isn’t supported by IE5.5 and earlier – still a pretty large proportion of the browser market, I think. Plus, I suspect screen readers wouldn’t be too keen on it either, so accessibility’s out of the window – for the moment.

However, as stated in the article, you can do all your XSLT on the server-side, just like on the client-side. It should definitely a priority for client-side web developers to get familiar with XSLT, and do it now – cos in a couple of years we’ll all be busy learning XAML and whatever the WHAT WG comes up with :)

Seth Thomas Rasmussen

November 18, 2004 8:20 AM

“cos in a couple of years we’ll all be busy learning XAML”

Uh… why?

Mark

November 18, 2004 8:55 AM

BugTomek: Thx and +IE6 as we learned here.

Benjamin: Thx for the link and yes that is what we’re up to here: php-xslt for the actual site and client-side xslt for preview.

Joshua Porter

November 18, 2004 12:53 PM

If Safari supports client-side xslt, could someone suggest how to view the example in Safari? It’s not working in version 1.2.3.

Ken Westin

November 18, 2004 1:32 PM

Can you say anything more about the current pitfalls of client-side design?(like why we might not move over yet?)

Joshua:
Yes there certainly are pitfalls in using XSLT on the client side. The main one would be that there is no easy way to support those users who have older browsers, or using other devices. In order to do this you have to use some sort of browser or device detection. With the move to XHTML/CSS based design we had methods established taking advantage of hacks etc in older browsers to get around them so our content can at least be displayed.

What can be done is to build pages using XML and XSLT, then attempting to sniff out the clients browser, if you can succesfully detect the correct browser, you feed them the XML, if not you do the transformation server side. This sort of arrangement can also help you future proof the site, as older browser trail off in your log files and finally reach a threshold you can remove the server side transformation altogether…or if a new markup (XHTML 2 anyone?) comes along you can quickly alter your XSLT file to spit out the new format without altering the content in your XML file. This has the potential to save quite a bit of money and time.

I would not use XSLT client side just yet for sites designed for the masses, unless it is in an environment you have control over the browser environment. An intranet would be a good example, if your company has a policy to only support a handful of browsers, as most do, this is where you will start to see this occur first.

Harry

November 18, 2004 3:26 PM

Re: browser support

Here are the ones I’ve tested using my site’s RSS feed (processed with client-side XSLT) as an example:

Working:
IE/Win 5+
Mozilla
Firefox
Camino

Not working:
IE/Mac
Safari (although Dave writes that he’s working on this)
Opera

Another reason you may not want to make the switch to client-side XML-XSLT for your public web site is that Google does not support .xml as a readable file extension yet. That means, Google won’t index your XML files, and therefore, those files may not turn up in a search unless others point to it. See the list of supported file extensions in Google and then, if you like, read “Google Can’t Read This.”

Yahoo, MSN, A9, Teoma, Dogpile, and many others simply treat it as text. That is, the bots don’t parse the XML. In their search results, everything is text, which means XML tags are interspersed with data. So, while the text in the XML file is searchable, the summary blurb in the results may be unreadable (and appear unprofessional) to the folks trying to reach you. That is, you may see things like:

My Search Result Linked Title
<mynamespace:instruction>
  <mynamespace:number>3</mynamespace:number>
  shalt be the number thou shalt count, and the number of the counting shalt be
  <mynamespace:number>3</mynamespace:number>.
</mynamespace:instruction>

Cheers,
Harry

patrick h. lauke

November 18, 2004 5:04 PM

unless you’re working on a resource where you can guarantee client support, this is obviously not a good idea. first and foremost, you’re potentially throwing accessibility right out of the window. secondly, you can’t guarantee that the client will have perfect transformation capabilities (maybe just a partial xslt implementation, or subtle difference – compare for instance the sort order in IE and Mozilla). it’s nice and easy to test your xslt client side during development, but why not take that final step and simply run the transformation server-side as the final delivery step? you still have the advantage that the separation of xml and xslt offer, just that it’s hidden away from the client, and the processing onus is placed on your server (which is a far easier environment to control reliably than the myriad of clients). if you’re particularly bent on the client side aspect, you could still write some logic that sends the xml + transformation instructions to capable browsers, and does server-side transformation to simple (x)html for clients which don’t support it, i guess…

Jack Lindsey

November 18, 2004 8:00 PM

I can confirm that Win IE 5.5 can handle XSLT scripts.

But when managing content by using the philosophy of separating data (XML) from structure (XHTML generated by XSLT) from design (CSS) and behaviour (ECMAscript), the XSLT need not wait for either server-side or client-side processing.

I have just created a soon-to-be-released site that presents information previously only published in PDF documents and re-organizes it using the Adobe Framemaker XML output with additional navigational linkages for the Web. This required multi-pass XSLT processing simply accomplished by grouping MSXSL command line calls in bat files. This guarantees that the content of the print and Web formats are synchronized for each release.

My content is complex but not frequently updated. Perhaps this approach is not as dynamic as some might need but because the XSLT is applied before anything is ever uploaded to the server, browser XSL capabilities are not a factor.

BTW, as Eric Meyer will quickly point out, structure and design are never truly independent. They are like twins joined at the head, i.e. bad (or a lack of) structure can cramp your style.

[Sorry my personal site is IE-specific but my Firefox T-shirt is in the mail, I swear]

Richard

November 18, 2004 10:48 PM

This article was my first exposure to XSLT. I was sorely tempted to get nekkid and run around screaming “Eureka!”.

The excitement wore off when I tried to make the separation of content and formatting a reality. Oh, I could make everything work except getting XSLT and CSS to work together.

I tested using Firefox 1.0 and IE-sux-I-mean-6. Neither one would let me “cascade”, regardless of the order of the stylesheets. I even tried using the tag in the HTML innards of the .xsl stylesheet, but that didn’t work, either.

Then . . . I spent about three hours trying to Google up an answer. This was fruitless labor, too.

Mr. Westin wrote:
“With some additional markup and an attached stylesheet, the final product could look like this.”

Prithee, how exactly do you add “an attached stylesheet”—a CSS one—when you are using XSLT, too?

Ken Westin

November 18, 2004 10:49 PM

Saying you can’t start working with XSLT because it is not accessible is like saying you can’t launch the space shuttle because it’s not wheel chair accessible. This article is to serve as an introduction to capabilities being built into modern web browsers, support for XSLT is not complete, it is still in its infancy, we are at the head of the Bell Curve in terms of XSLT being implemented client side, think of it as still in beta. XHTML and CSS didn’t just happen, it was an evolution that occured out of a need and a demand from the people who work and consume the web. So put the gospel of Nielsen down for a sec and think outside the browser.

In fact XSLT has the potential to vastly improve accessiblity as you could have the ability to transform your data into any format you like say SSML or VoiceXML, once devices finally support these formats. Instead of trying to make a markup language that was never intended to be accessible when it was originated be all things to all people, you can start fresh and provide the data in a format designed for a specific audience and purpose.

Google may currently not index XML files, does this mean that they never will? Don’t think so, I am sure this will change in the very near future. Since Google’s search appliance uses XML/XSLT already, indexing XML files does not seem out of reach.

Chris Hunt

November 19, 2004 4:16 AM

But Ken, what’s the benefit of processing XSLT client-side instead of server-side? As Patrick points out, server-side processing retains the key advantage of seperating data from design without depending on sometimes flaky or non-existent XSLT implemetations.

You can launch that Space Shuttle today, provided you’re not relying on everybody in the world having a launch pad in their back yard.

Accessibility barriers to client-side XSLT are a real issue. If by the “Gospel of Neilsen” you mean “making sites that everybody can use”, then sign me up for the choir. I’m not “setting it aside” just for the sake of adopting the latest browser-based gee-whizzery, especially since I don’t have to.

Jim

November 19, 2004 9:19 AM

Being new to this – the inclusion of
?xml-stylesheet type=“text/xsl” href=“books.xsl”?
in the xml file seems wrong – though I know technically correct.

If I have a lot of data; 100’s books author date ISBN etc surely I might want to look at this in many ways not just books.xsl.

Is there any way to do books1.xsl(books.xml) books2.xsl(books.xml) on the client side without “corrupting” the data with the explicit inclusion of a specific transformation file

Ken Westin

November 19, 2004 9:50 AM

// get the xml
var myxml = new ActiveXObject(“Microsoft.XMLDOM”)
myxml.async = false
myxml.load(“mydata.xml”)

// get the xsl
var myxsl = new ActiveXObject(“Microsoft.XMLDOM”)
myxsl.async = false
myxsl.load(“myxslt.xsl”)

// Run transformation
document.write(myxml.transformNode(myxsl))

Here is the Moz implementation

Here is one technique that uses quasi-browser detection to handle the differences.

Another issue you will run into is if you try to access XML files in a different domain. Windows users with SP2 installed will get a nice big security warning, thank you M$ for protecting us from those malicious XML files :-)

Since the scope of this article was just to serve as an introduction, we just the stylsheet instruction was added to make it easier on folks just getting started as it works in most browsers. The next version of Safari will support this as well and as I have been told Safari will follow the Moz JavaScript implementation.

Jack Lindsey

November 19, 2004 12:42 PM

Richard:

The “tag in the HTML innards of the .xsl stylesheet” approach should work. I dug out my old IE5.5 prototype that worked that way, i.e. the xml file referenced the XSL sheet which in turn began:

where LT = open angle bracket
and GT = close angle bracket

LT?xml version=“1.0” encoding=“UTF-8”?GT
LTxsl:stylesheet version=“1.0” xmlns:xsl=“http://www.w3.org/1999/XSL/Transform“GT LTxsl:output method=“html” version=“1.0” encoding=“UTF-8” indent=“yes”/GT
LTxsl:template match=“Cases“GT
LThtmlGT
LTheadGT LTtitleGTCase ReportLT/titleGT LTlink href=“Outliner.css” rel=“stylesheet” type=“text/css”/GT
LTscript type=“text/ecmascript“GT function clickHandler() {

.......

Joshua Porter

November 20, 2004 4:30 AM

Ken, thanks for your answer. This article and comment thread have been great.

Jim, if I am understanding your concern right, you don’t like having specific xsl stylesheets included in xml files. I wonder about this, too.

Ken, the javascript method you pointed to in response to Jim’s question, is that simply re-applying different stylesheets to a cached (on the client) of the xml file? If so, that’s very cool. (even though I refuse to use proprietary scripting)

This is almost backwards from the XHTML/CSS model. Instead of caching the styles and applying it to changing data, we can cache the data and apply changing styles!

Ken Westin

November 20, 2004 9:18 PM

Joshua,

Now we get into the fun stuff. I think the best way to explain the JavaScript method is with another example. Forgive me for using the IE 6 example, but I think it will make it a bit easier to see what is going on.

Here is a page I have setup as our example, with four links.

If you view source you will see this:

<html>
<head>
<script type="text/javascript">
function feedme(feed){ var xsl = new ActiveXObject("Microsoft.XMLDOM") var xml = new ActiveXObject("Microsoft.XMLDOM") xsl.async = false xml.async = false
xsl.load("rss.xsl") xml.load(feed) document.write(xml.transformNode(xsl)) }
</script>
</head>
<body>
<h4>Feed Me</h4>
<p>
<a href="javascript:feedme(‘bbc.xml’)">BBC World</a> |
<a href="javascript:feedme(‘bbc_tech.xml’)">BBC Tech</a>|
<a href="javascript:feedme(‘zeldman.xml’)">Zeldman</a> |
<a href="javascript:feedme(‘digital_web.xml’)">Digital Web </a>
</p>
</body>
</html>

So I create a function called feedme() that accepts an xml file as an argument. If you don’t have SP2 called you could actually put the URL in of the feed and it would work, but I have downloaded the feeds and put them in the same directory as the ie.html file for this example.

Now, when you click one of the links, it passes the xml filename to the function, and it loads the xml data as well as teh “rss.xsl” file I have loaded, which in turn loads “rss.css” which I have specified in the XSL file.

If you click the BBC link for example you will see the actual output of the transformation. This actually helps explain what is happening. Essentially the transformation takes place first, then the HTML you output is loaded into the browser. It actually will replace the existing HTML we have setup, almost like you loaded a new page…but if you look at the address bar you will see we are still on the same page.

The beauty of this is that not only can you swap out your XML data, but you could also swap out XSL. You can also pass parameters to your stylesheet…

Again, the bugger is that different browser are implementing this functionality differently. I actually prefer the Mozilla/Firefox implemenation as it allows you more control of the output so am hoping Safari uses this instead of coming up with their own.

Jim

November 21, 2004 4:35 AM

Ken,

Great – I now understand this thanks .... but maybe I could prompt you / inspire you a bit further …

Clearly it would now be trivial to write feedme(xmlfile, xslfile)

However, wouldn’t this be just great as a favelet (since the address can be javascript as well as http) ... as an example I use the following code saved as a favourite

javascript:FD983r={x:function(){var%20r,i,s=document.selection.createRange().text;if(!s)s=prompt(‘Find:’,’‘);if(s){r=document.body.createTextRange();for(i=0;r.findText(s);i++){r.execCommand(‘BackColor’,’‘,‘yellow’);r.collapse(false)};alert(i)}}};FD983r.x()

to do a simple find within a webpage.

So you might write a favelet that prompts for the xmlfile and the xslfile and then outputs the results or use your own default xslfile (for say accessibility) and just prompt for the xmlfile.

In this way we have action(data, style) and all three types are independent … seems more elegant to me.

Jim

Learning all the time ;-)

Small Paul

November 22, 2004 1:40 PM

Seth: because Microsoft is strong, IE is ubiquitous and we all gotta buy food :)

Matt Lundquist

November 26, 2004 9:29 PM

Great article! I heard about XSLT, but really didn’t understand what it was used for and there it was right under my nose with most browsers supporting it. Looks like I have some experimenting to do.

Robert Koberg

December 1, 2004 1:40 PM

Hi,

You might want to check out Sarissa (http://sarissa.sourceforge.net/) which is a cross platform javascript library for XSL.

However, as many have already stated, it is probably a better idea to control the transformation server side: – probably less bandwidth usage – not tying the XSL to the XML – use whatever processor you want (for example there is currently one good XSLT 2 processor out there – http://saxon.sourceforge.com — and Microsoft has said they will not support XSLT 2). – use an XML parser that can do XInclude

Even better, if you do not need dynamic sites, pre-generate and just serve static pages. You could use a tool like Apache’s Ant and its Xslt task – http://ant.apache.org/manual/CoreTasks/style.html

best,
-Rob

Pascal Opitz

December 7, 2004 3:28 AM

The pitfall about client-side XLST right now, when embedded with a link in the head of the XML, is the lack of variable-support.

XSLT, even if “only” a stylesheet for XML, has some powerfull posibilities to sort, use variables and do script-language like conditional processing.

The only thing really needed would be a way to get querystring variables in.

This is the reason why the JavaScript-way is an interesting alternative for modern browsers as well, especially if something like sarissa is used.

I already wrote a small article about dynamic tables with XSLT, where i pointed out the possibilities.

Steve

December 21, 2004 11:07 PM

Add the lines in bold type here to books.xml:”

Should be books.xsl, yes?

“” extra space before the closing angle bracket.

It’s also not clear where the sort line should go, as the surrounding lines don’t match the source of the previous listing.

Speaking as a novice, it might be helpful to have full source listings of the files at the end of the article to clear up any confusion.

Thanks again,

-S

Jens Meiert

December 23, 2004 2:42 AM

By the way, the ul element in the last code snippet (currently) misses the ID (‘id=“booklist”’).

Regards, Jens.

Ken

December 27, 2004 10:59 PM

Thanks, yes the reference to books.xsl is a typo. However, the full code is at the end of the article.

The id attribute was not added to the example as it refers to CSS and not the XSLT example.

Ryan Oswald

December 30, 2004 4:15 PM

This is stupid. I don’t know about other designers, but I have no desire in learning/researching yet another 3-letter buzz technology. Oh and I don’t have time to go through all the comments so if this has already been said, oh well. If I tried to follow up all the comments of blog entries I’d have to kill myself (something needs to be done about this commenting stuff). Anyway, we have the coding formats already… why don’t we learn how to use them properly FIRST before we try to implement 50 more technologies into the mix to solve 1 problem. “Reactionary technologies”- that’s what I call this crap. Case in point:

“edits and writes XML and uses XSLT to publish an HTML archive file, an HTML short list (for your index page) as well as an XML RSS 2.0 feed file.”

huh? I think my HXSMLT is about to explode.

smart

January 9, 2005 6:30 AM

Thanks for the good introduction, Ken. I’ve used server-side xslt for a couple years now, and I’m anxious to start on the client side.

Billy

January 28, 2005 8:39 PM

No offense, but what is the point in using yet another X-named technology that is only partially supported by browsers? Why not use a proven and reliable technique to separate content, logic, and design – php templates! Seriously, programmers seem to feel the need to build everything from the ground up all the time. Why not try to improve existing standards, instead of creating and touting new ones every 3 months? If you ask me, the W3 needs to spend more time pressuring browsers to support HTML and CSS in the same way. Even if you are a virtuoso in the latest X-this or X-that, you still have to go back and account for the fact that your stylesheet will look like shit in Mac-IE. :-P

dev

March 23, 2005 1:07 PM

can somebody help with client side pagination and sorting using this technology?

Ken Westin

April 4, 2005 11:34 AM

I would not call XML and XSLT reactionary technologies. I think the broad support of these technologies by small companies like Microsoft, Sun, Oracle, Google not to mention the open source community proves the case.

Ryan, in most cases the XML is generated automatically on the backend, if your data is in XML, generating and reusing that data solves the problem you say these technologies are creating, you may want to explore server side technologies a bit more to see how XML based technologies can help. If you are editing multiple XML files by hand with the same information, your design is flawed, not the technology.

I don’t see how this article is forcing XSLT on anyone, of course I believe the job market may be a motivator to learn these new skills in the future.

Billy, no offense taken, however I think you missed the point of the article. I don’t think I ever said this is the only way, but there are benefits of an XML based strategy vs. PHP templates, which I will leave to you to explore. I have solved problems using XSLT that would have been impossible using PHP alone, albeit the transformation took place server-side. You may want to take it easy on the profanity when commenting, although it does not bother me, when you are trying to make a case it can make you appear amateurish and unprofessional and does not give weight to your argument.

Dev, could you post more information on what you are trying to do?

Sorry, comments are closed.

Media Temple

via Ad Packs