[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Client-side XSLT. Re: Bad News on IE6 XML Support
- From: Paul Tchistopolskii <email@example.com>
- To: Max Dunn <firstname.lastname@example.org>, 'xml-dev' <email@example.com>
- Date: Sat, 08 Sep 2001 15:22:52 -0700
> Note that it has a little link on the side for the adventurous. That's
> more what I was suggesting as a way to use XSLT on the client (i.e. one
> option with alternatives for other browsers). And look, it was less
> than 3 years!
And now let us explore what's written on this *really* nice and
I'm using these pages as a testbed and a demonstration of what you can do with web
technologies like XML, XSLT, CSS and RDF. I'm trying hard to stick within these standards
so that if your browser is compliant with these standards it will all work fine.
However, I admit this is a bit of a pipe dream. Browsers tend not to be compliant, tend
not to implement everything and tend to interpret things very differently. So while my
main browser is IE5, I've also tested the HTML + CSS used on these pages in Windows NT in
Netscape 4.7 and Opera 3.61. If you can't view something in your browser, then do let me
know; if it just looks a bit odd, then it's probably because I've had to reach some
compromise to make it viewable in another browser.
These pages are designed and tested for use with MSXML3 (July or later, but obviously the
full release is best). If you're using IE and can't view the XML properly, I recommend you
download the release version of MSXML from Microsoft. You will need to install MSXML3 in
replace mode, so download xmlinst.exe from the same site and follow the instructions about
changing the registry entries. See the unofficial MSXML FAQ for more details. The HTML is
all generated by SAXON from exactly the same source with the same stylesheet.
1. "I admit this is a bit of pipe dream".
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?
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???
> > To use XSLT client-side one has to install either Netscape
> > version 6 or IE version 6.
> No. IE 5 and MSXML 3 will actually let you view that site just fine.
> It isn't *convenient* to go track down MSXML and xmlinst.exe (and it's
> unlikely any non-programmer users would ever do that, though they will
> download IE 6), but it's quite possible, proof that even such a "slim"
> browser as IE 5 *could have* supported XSLT.
Are we talking iternet or intranet? *User has to change the
registry entries*. Shessh.
> > Both are too fat, comparing to NS
> > version 4 and IE v 5.
> It is not as if bloated programs are a prerequisite to XSLT (if these
> programs are fat, very little of that fat is due to their - limited -
> support of XML): you will find, however, that newer programs tend to be
> more bloated than old ones. You'll also notice that people tend to move
> towards the new ones anyway.
I'm not saying that it is XSLT, that turns version 6 fat.
> I would hope that over time non-XSLT-supporting clients are treated the
> way Text-only/Frameless browsers are treated Today.
I hope not. Are you talking about XSLT 2.0 ? That will be a nightmare.
Like Mr. Leventhal, I now hope CSS will get implemented everywhere,
it is *much* more important, than XSLT, because there is no way
to get 'server-side' CSS. CSS is *must have*, client-side XSLT is
'nice(?) to have'.
> > I understand that some people may buy the idea of client-side
> > XSLT in the situation when *no* 'pure HTML browser' has to be
> > supported, but if somebody needs *both* ???
> Once you're using XSLT on the server, it does not involve double the
> effort to use it on the client, and this can decrease server load and
> provided enhanced client-side experience.
Ideally, yes. I agree. It *can*. But there are plenty of other things,
(like security, portability e t.c. ) involved.
e t.c. When you drop yet another interpreter into the picture
( and XSLT is just yet another interpreter ) the resulting mess
will produce many problems. Too good that at the moment
client-side XSLT is not more than a 'pipe dream', but not a 'technology'.