Re: Client-side XSLT. Re: Bad News on IE6 XML Support

[Jeni Tennison <mail@jenitennison.com>]

Paul Tchistopolskii wrote:
> And now let us explore what's written on this *really* nice and
> honest site.
>
[snip]
> 1. "I admit this is a bit of pipe dream".

Actually, the pipe dream I was referring to there was that HTML+CSS
would look the same on all browsers rather than that everyone would be
able to use client-side XSLT. I agree that good CSS support on the
client is a lot more vital than XSLT support.

> 2. "The HTML is all generated by SAXON from *exactly* the same
> source with the same stylesheet". This means the only reason to make
> it 'client-side XSLT' was ... For fun?

Yep. For fun and and as a demonstration for people who are interested
in client-side transformations. This is also one reason that I don't
auto-detect -- I wanted to enable people to see how their own browser
reacts to XML and client-side transformations without having to keep
up with what supports what. For example, people with Netscape 6.1 can
view the XML side of the site (although I wouldn't necessarily
recommend it - it doesn't transform correctly and the CSS doesn't get
applied for some reason that I haven't figured out yet).

> Fun is good. I have nothing against fun projects. I just don't how
> it is applied to production? You mean thousands of coders first
> producing the client-side XSLT HTML ( that works everywhere ) and
> then placing the same stylesheets on client-side with the risk of
> client being crashed ? You really think somebody is gonna do *that*
> in production???

I think that most of the crashing problems come either from
stylesheets that would also crash if the transformation was carried
out on the server or from Javascript that would also crash if the HTML
was generated on the server. There's probably an interaction as well,
of course, but I think it's small.

The argument that I've heard for client-side transformations is that
they ease the load on the server. Presumably this is particularly true
with dynamic applications where the results of the transformations
cannot be cached. It would also be faster for the client if the same
stylesheet/XML were used as the basis of multiple pages - they would
only have to download the XML/stylesheet once, rather than accessing
multiple HTML pages.

Server-side engines such as Cocoon and XSQL simplify auto-detection,
so that you get client-side transformation when it's available and
server-side transformation when it's not. However, this is still done
through browser name/version rather than through a more general
mechanism such as the HTTP Accept request field, as far as I can tell.

To my mind, even when/if we have several browsers what implement XSLT,
we will still have a problem with client-side stylesheets because of
the question of how you pass parameters into the stylesheets. To do
this with IE, you have to write some Microsoft-specific Javascript in
order to create and populate DOMs. I haven't had a chance to
experiment yet with what you can do within Netscape/Mozilla.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/