[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Client-side XSLT. Re: Bad News on IE6 XML Support
- From: Max Dunn <maxdunn@siliconpublishing.com>
- To: 'Paul Tchistopolskii' <pault12@pacbell.net>,'xml-dev' <xml-dev@lists.xml.org>
- Date: Sat, 08 Sep 2001 14:47:41 -0700
>> So he should shut down http://www.bayes.co.uk/xml/ ?
> This URL actually points to something??? Sorry, my IE v 5
> and Netscape v 4.7 don't work on that page. I suspect that
> I should use Netscape 6 or IE 6 ?
IE 5 or greater with MSXML in "replace mode" will work. Yes, that
particular site is aimed at a browser that supports client side XSLT and
was developed when IE 5/MSXML 3 were the only real option for client
side XSLT. I don't think it will work with Netscape 6 yet. Here's a
more polite site for you to get less upset about:
http://www.jenitennison.com/
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!
> 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.
> 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.
> That "support for multiple browsers" happens all the time, not
> only with CSS. I don't understand - you *really* think that in
> the situation when the task is to support both HTML-only renderer
> and XSLT-capable renderer at the same time, some architect may
> provide a client-side XSLT based solution *and* HTML-only
> solution, *not* providing *just* HTML-only solution based on
> server-side XSLT ???
It certainly would be nice to use a client that has the computing power
prerequisite to *any version* of IE/Netscape (none are particularly lean
by application standards) as something other than a dummy terminal.
I would hope that over time non-XSLT-supporting clients are treated the
way Text-only/Frameless browsers are treated Today. Give them a version
of the site they can handle.
> 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.
> 'Client-Side XSLT' ??? What are we talking about?
> There are millions, who *use* JavaScript. And see how
> fast JavaScript was adopted. Compare it to the growth of
> this 'client-side XSLT' stuff ( which *was* availiable in the
> browser for *years*, even in the crazy MSIE form of it ).
There I completely disagree. The "crazy MSIE form" was *not* XSLT.
That never should have been released as anything other than a technology
preview, and should absolutely not be cited as some sort of evidence
that XSLT has been around for years.
Regards,
Max
http://www.siliconpublishing.com