What is preventing widespread use of XSLT for webp

问题:

Why aren't more webpages written using XML with an XSLT stylesheet? For separating content from presentation, this combined with CSS would be even more powerful. Right now, for things like outputting a navigation menu, people often hand-copy the navmenu code from page to page or do something like

<?php include_once('myheader.inc'); ?>

on every page, which not only puts more demand on the server, but results in duplicated data transmitted.

When I was introduced to it, I was told that all major browsers back to IE6 support XSLT 1.0... are there unresolvable bugs between implementations? Are there others showstoppers or severely lacking features that are inhibiting the spread of XML+XSLT? The only website I've seen lately that is XML+XSLT is starcraft2.com.

回答1:

1. It is extremely verbose
2. It is hard to trace (in a complex system) how/where/why/when a template is called
3. Since the output must be well-formed you can't have a template that "opens" the HEAD or BODY tag that you'll then worry about closing somewhere else later. This sucks when you want to be able to queue up bits of code to go into the HEAD when you are processing what will be in the BODY.
4. It isn't as easy to navigate the code as following method calls is
5. Outputting something like an IE conditional comment is very confusing with all the escaping needed
6. Building a string of HTML by appending bits just doesn't work. This can be overcome by building the HTML string bit by bit in XSL code, but it becomes quite complex.

However most of all (IMHO) it adds an extra layer to the process that doesn't "buy" you much.

e.g. typically you have:

DB > SQL > [JAVA|PHP|ASP|Python|Ruby] > HTML

but if you throw XML and XSL in, you've added steps that (can be) hard to justify

DB > SQL > [JAVA|PHP|ASP|Python|Ruby] > XML > XSL > HTML

having the data in a handy dandy universally exchangeable XML format is great-n-all, but unless you need it, all you've done is add steps.

Now I shouldn't knock XSL too much because, well I use it all the time and do appreciate some of the powerful options it provides. However to anyone deciding if they want to use it, be sure you have a need before diving in.

回答2:

Blizzard Entertainment seems to like XSLT. Their World of Warcraft Armory site is completely implemented using it. Look around the site using view source.

回答3:

I think part of the issue is that programming in XSLT has some of the attributes of a functional language (see this answer for why it's not fully functional).

As such it requires a different approach from the 'usual' imperative mindset, and that will deter some people from fully investigating it (I'm not dismissing functional programming, btw, but in the web client/server world it's not the most common paradigm).

In the Java world it used to be perceived as being slow and memory hungry. I'm sure some of that was anecdotal, and perhaps partly the effect of early VMs. I note, however, that hardware XML accelerators are available and sit behind the JAXP interface, so perhaps there's still a speed issue ?

回答4:

There are a few issues regarding the adoption of XSLT, browser issues among others. For instance, the Firefox plugin NoScript, designed for blocking malicious JavaScript, also blocks XSLT on unknown pages. Don't forget that switching to a subdomain or different protocol will make IE respond to it as a violation of the same origin policy. Still, XML+XSLT, even though it's just for a limited number of cases, is quite useful. See WoW's website as an example of well-implemented XML+XSLT.

回答5:

XSLT isn't easy.

回答6:

XSL in the browser is also a problem because of search engines. Currently, they only look at the underlying XML and ignore the XSL stylesheet. That seriously hurts your ranking, I suppose, since they can't make any sense of your content that way. Like, they wouldn't even know where the headings or links are for example.

回答7:

Simple, XSLT is far too complicated.

回答8:

XSLT in the browser is right out because the smallest mistake in generating valid XML input could cause your page to show up blank, but there's a product called deliverance that runs on the server to make different web applications in a site share the same theme.

XSLT is surprisingly fast. It will be much faster than a typical interpreted templating language on the backend.

回答9:

XSLT is an ugly, ugly template language. It has some advantages, but is also missing some critical features. Django features a template language for designers to give them simple access to data elements. They have considered XLST before, but consider it simple to change out. PHP users may prefer something like Smarty.

Obviously your question focuses on moving this to the browser, where the choices are basically XSLT, CSS or Javascript. I'm guessing the people who are in charge of CSS are not the same as those in charge of Javascripting.

回答10:

Browsers do a piss poor job of rendering XSLT... meaning that to get it to render properly across browser, you need to render it on the server, negating any advantage you had for using it in the first place.

This means that you end up doing two conversions on the server side instead of one: data -> XML -> HTML instead of data -> HTML.

回答11:

XSLT was one of the few XMLish technologies that I actually liked. Especially for report generation the concept of XSLT with its set-based feel and ability to target all kinds of output formats (not just html) it deserves to be used more than it is today.

The reason I personally never used it was because at the time one of the browsers (I believe IE7) did not support rendering XSLT in the browser and we did not have the option of XSLT processing on the server side.

The second reason is that while its great for reporting and data presentation it wasn't really practical in terms of general purpose use.

回答12:

People who didn't live under a rock for the last ten years don't copy and paste header code or use PHP includes for layout anymore. They separate presentation from the actual code and use templating systems (eg. Smarty, a popular one for PHP) which have syntax that is easier to comprehend and reason about than XSLT.