Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Client-side XSLT. Re: Bad News on IE6 XML Support
 > 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 ? Well, I've tried both 'version 6' browsers on my poor computers at work and ... Those lost souls who upgraded version 5 to version 6 look helpless to me. I mean, in could be that version 6 of both browsers has some CSS or XSLT, but both IE 6 and Netscape 6 are just ... crushing all the time ... But that's 'aside'. > I don't understand what you are saying about "a small percentage of > immaculately configured machines"? Isn't 99% of what people use for > browsers today far less "fat" than what is required for client-side > XSLT? ??? Yes!!! To use XSLT client-side one has to install either Netscape version 6 or IE version 6. Both are too fat, comparing to NS version 4 and IE v 5. I don't know about 99%, but from the logfiles of my website, the percent of v 6 browsers is not more than 10%. > I have noticed a ton of CSS on the Internet. Quite common amongst > blogs, for example. Some even go so far as to detect what form of > browser you're using and send appropriate content. 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 ??? 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* ??? I'm wondering when those constant speculations about client-side XSLT will stop and we'd just discuss the *particular* client-side XSLT solutions that people implement ( *if*any*). The Chris Bayes' URL provided by you is accessible by a fraction of people. It is interesting for those 10% who've installed version 6. Are you talking about the intranet? If yes - why you're jumping to 'blogs'-are-detecting-the-type ? Are you talking about the *Internet* ??? If you do talk about the *Internet* - nobody builds the Internet apps on client-side XSLT. Period. Nothing to discuss. > Of course only time (and the actions of large companies such as AOL and > Microsoft) will tell, but I think there is fantastic potential for > client-side XSLT and it will be like other "modern" technologies such as > JavaScript (or do you use that yet?): detect whether they have it, and > if so, take advantage of it, within the limits of their implementation. This 'time-will-tell' mantra abour client-side XSLT is at least 3 years old. I think it will take at least 3 more years to get more than one person supporting it IRL. Chris Byes is the only guy who constantly plays with this client-side XSLT. Because of that, his website was *always* crushing my browser, every time I visited his pages for last *years*. And I've stopped providing him with particular bugreports after I realized that he does not care about such a small things like browser crashes. He has a universal excuse : "it is bleeding edge, it is OK to crash". Something has really changed with the software development. I don't expect the number of those 'clisnt-side XSLT' people to be more than, say, 100. '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 ). > The closer to compliance with a spec most implementations are the better > for everybody, but being ready for multiple bad implementations is > certainly nothing new in coding for the web. XSLT will flourish on the > client, now that there are at least two attempts at it out there. Mantras are good. I think XML Everywhere is right on this tiopic. When somebody wants you to apply a mantra or other religious construction for solving an engeneering task, the only reasonable answer could be : > Client-side XSL? > What are you smoking? <some other quote> The bottom line is: the server can determine is the user agent support XSLT or not. If yes, the process can occur at the edge or at the client site. Otherwise at the server side. As more client support XSLT transformation, less server load you'll have. Is using a 1 ghz client to perform dummy rendering a best way to use resources? What about distributed computing 101? </some other quote> This client-side XSLT business is a couple of years old. Show me the money, pelase? I mean where is this scenario implemented and what was the *reason* of implementing it *this* way ( because I don't see *any* practical reason ). If it *was implemented*. Maybe that 'dictributed XSLT' picture looks nice on paper, but where is it IRL ? Rgds.Paul. http://www.spafi.com - Smart Spam Filter for Windows 
|
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
|
|||||||||
