[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Client-side XSLT. Re: Bad News on IE6 XML Support
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/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|