XSLT虽然名字中也有Stylesheet，但是它其实不是为设置文档的表现样式的目的而设计的，用来替代CSS的是XSL-FO。然而XSL-FO目前还没有浏览器能够支持（其复杂性造成了其可能很多年以后才会被应用在浏览器之中，这是“委员会驱动”设计方法的通病），所以我们在这里就不讨论了。XSLT的主要作用是将XML由一种格式转换为另一种格式，例如：由XML的一种词汇表转换为另一种词汇表；或者由XML转换为HTML或者XHTML，便于在浏览器中显示。后面一种应用（XML->HTML/XHTML）是目前XSLT应用最为广泛的领域，被应用在一些J2EE表现层框架中（例如，Cocoon是一个典型的代表。其他的J2EE表现层框架也可以通过集成Jakarta Taglibs来实现类似的功能）。这些框架在服务器端做XSLT转换，将生成的HTML/XHTML发送给浏览器。基于这种技术的框架可以非常方便地支持各种瘦客户端，例如：具有无线上网功能的PDA或WAP手机（这时候是XML->WML，也就是由XML的一种词汇表转换为另一种词汇表，WML本身也是XML的一种词汇表），无非就是另外再写一套XSLT转换规则。有一些需要定期生成静态页面的网站也在服务器端采用XML+XSLT来定期生成静态页面（这类进程一般是以后台方式来运行的）。

在IE 5.0中就可以支持XSLT了，不过当时采用的不是XSLT的正式规范，而是这个规范的一个草案（namespace为http://www.w3.org/TR/WD-xsl）。IE 6.0支持XSLT的正式规范（namespace为http://www.w3.org/1999/XSL/Transform）。Mozilla也在2001年就可以支持XSLT了。既然IE和基于Mozilla的浏览器（Mozilla Suite、Firefox、Netscape、etc.）都可以很好地支持XSLT，这就引起了一种思考，究竟是在服务器端做XSLT转换好还是在浏览器端做XSLT转换好呢？我的考虑是尽管在服务器端做XSLT转换更加灵活，功能更加强大，我却更愿意在浏览器端做转换。因为XSLT转换是非常耗费资源（内存、CPU）的操作，如果在服务器端做大量的转换操作必然会极大地影响服务器的性能（设想有100个并发连接，同时在服务器端做100个XSLT转换的情况）。必须要在服务器端做转换的更好的方案是以后台方式定期生成静态的HTML页面（一些新闻网站就是这样做的）；或者在服务器端通过软件实现某种缓存机制，而不必重复做相同的转换。这也符合我们的一贯思路：浏览器其实能做很多事情，而且现在主流PC机型（P4 2G、256M 以上内存）的处理能力已经非常强了，所以在浏览器力所能及的情况下应该将尽量多的工作交给浏览器去做。
然而，目前除了IE与基于Mozilla的浏览器之外，其他的浏览器（例如Opera和Safari）目前仍然还不支持在浏览器端做XSLT转换，因此如果计划支持这些浏览器，必须要提供在服务器端做XSLT转换的对应功能，使得应用在这些浏览器上也能正常运行。

XSLT目前已经达到了实用的阶段并且被广泛采用。我们做Ajax开发有的时候也会用到XSLT。Google Maps的那个可爱的弹出式小气球就是使用客户端的XSLT（至少在IE和Firefox上是这样做的）来生成的。在《Ajax实战》（Ajax in Action中文版）第12章：使用XSLT的动态搜索，也通过一个完整的实例演示了客户端XSLT的威力。使用XSLT的好处是可以将很多界面生成的工作自动化，减少错误的发生。当然XSLT也有一定的复杂性，需要花一些时间来学习，带来了额外的学习成本，因此需要在做设计之前做一些权衡。在适当的场合使用XSLT，无疑会成为Ajax开发者的一件利器。

虽然XSLT在IE与基于Mozilla的浏览器中都可以支持XSLT，然而它们的调用语法差别很大，这又为我们带来了头疼的跨浏览器不兼容问题。不必担心，解决之道就是使用一些成熟的跨浏览器库，例如 Sarissa。Google支持的一个开源项目 Google AjaxSLT，代码基于Google的工作，用来执行XSLT转换，以及XPath查询。《Ajax实战》第12章中同样对这些差异做了很好的封装，代码可以直接拿来使用。

附：推荐的XSLT相关书籍。

1. 《XML高级编程》，Didler Martin著。
2. 《Ajax实战》（Ajax in Action中文版），Dave Crane、Eric Pascarello、Darren James著。