Any reason not to use client-side XSL?? (was: Preferred tool for folding XML into HTML)
Cameron Laird
claird at starbase.neosoft.com
Thu Jan 10 11:12:08 EST 2002
More information about the Python-list mailing list
Thu Jan 10 11:12:08 EST 2002
- Previous message (by thread): Any reason not to use client-side XSL?? (was: Preferred tool for folding XML into HTML)
- Next message (by thread): Closed-source considered harmful (was: JavaScript considered harmful)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
In article <mailman.1010522352.9999.python-list at python.org>, Paul Prescod <paul at prescod.net> wrote: >Russell Turpin wrote: >> >> It seems clear that XSL is the way to go. I have heard that >> Internet Explorer supports client-side style sheets, i.e., >> your webapp returns the XML with reference to stylesheet, >> and IE will retreive the style sheet and apply it on the >> client side. I haven't read the details of this yet, but it >> seems slick, and raises some other questions: >> >> Wouldn't this be simpler than applying the translation on the >> server side? > >Not usually. :( > >> Is this standard? Do/will other browsers support this? > >Yes, it is somewhat standard. I think that some builds of Mozilla >support it but not all. "Netscape Navigator" seems to: > >http://developer.netscape.com/evangelism/docs/articles/xslt/ > >The docs there do not seem to say how to actually include the XSLT file >but I presume it is the same as with IE. > >Opera does not support client-side XSLT. > >Lynx does not support client-side XSLT. > >I would be surprised if hand-held computer browsers supported XSLT. > >> Are there disadvantages to applying the style sheet >> client-side? > >Well, there is compatibility with minority browsers. > >There is compatibility with older versions of browsers. > >There is the risk of small differences between the XSLT handling in >major browsers (just speculating...I haven't done client-side XSLT). As >usual, write once test once per browser version. > >Server-side XSLT can use extensions to a particular XSLT engine to pull >in (e.g.) Python code or SQL statements etc. > >If none of these are a concern, client-side XSLT might be the right >thing for you. . . . It's even more complicated than this. Gecko and Opera actually support CSS quite well, and *sometimes* that's what people want when they start to talk about XSLT. Also, IE supports scripted client-side XSLT processing. This is ... well, my view on a lot of this stuff is that it's solutions in search of problems. The original question was something like, "Wouldn't client-side be simpler than server-side XSLT?" 'Depends. The argument for client-side: Microsoft has already put all of XSLT in IE, it's there, it works (in recent versions), and you don't have to do anything. The argument for server- side: do all your users rely exclusively on recent IE, with preferences set for your convenience? If not, server-side is FAR easier to manage. This almost ascends to a question of *Weltanschauung*: is your client universe a homogeneous sea of modern browsers, or is the point of your Web application that you do *not* want to involve yourself in the logistics of client deployment? There's also a bandwidth argument in principle pertinent to some style-sheet applications. I know of no instance where it has actually been consequential. -- Cameron Laird <Cameron at Lairds.com> Business: http://www.Phaseit.net Personal: http://starbase.neosoft.com/~claird/home.html
- Previous message (by thread): Any reason not to use client-side XSL?? (was: Preferred tool for folding XML into HTML)
- Next message (by thread): Closed-source considered harmful (was: JavaScript considered harmful)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list