Subject: RE: Microsoft extensions to XSL (was RE: how to call Javascript function in .xsl file) function in .xsl file) From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Tue, 10 Nov 1998 20:32:14 -0500 |
Hi Ray, This is, I think, a reasonnable proposition. So, for example, if the tag do not has a "language" property it is, by default, ECMAScript which should comes by default with all CSS/XML/XSL browser. If CSS/XML/XSL is used in an intranet context or on a server, we then may want to use an other script language. In that case, the tag should provide a way to specify which language in a standard manner. Is this OK? Didier PH Martin mailto:martind@xxxxxxxxxxxxx http://www.netfolder.com > -----Original Message----- > From: owner-xsl-list@xxxxxxxxxxxxxxxx > [mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of Ray Cromwell > Sent: Tuesday, November 10, 1998 6:44 PM > To: xsl-list@xxxxxxxxxxxxxxxx > Subject: Re: Microsoft extensions to XSL (was RE: how to call Javascript > function in .xsl file) function in .xsl file) > > > > > For client side scripting on the browser, I think that not choosing > a standard scripting language is a mistake. Sure, it's all well and > nice that you can plug in whatever scripting language you want. > But let's face facts -- web developers will use the language > that has the greatest reach. If I am forced to download and > install another plugin/COM object (and how do I do this crossplatform?), > I will not visit that web page. > > For server side, it doesn't matter, but for anything on the client, > I'd argue for making JavaScript and Java the defacto standards. > Specifically, JavaScript. > > > Sure, I love my perl, but I'd forgo the use of all my languages if > I can depend on the end user being able to view my > CSS/XSL/DHTML/JavaScript > page on multiple platforms and browsers without regard to their local > configuration. > > If instead, I tried to use client-side PerlScript in IE4/5, who could > actually display my page? And what would be the advantage anyway? > > > Isn't there an adage "things left unspecified have a way of specifying > themselves?" Why not spec ECMAScript as *required* for a conforming > parser? There are even free implementations of ECMAScript in Java > and C. > > My sincere wish is that 3 years from now, I can depend on DOM > being the universal interface to HTML/XML, and every browser/OS > has built in 100% compliant CSS/XSL/DOM/EcmaScript support. > > > > > > > > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Microsoft extensions to XSL (w, Ray Cromwell | Thread | Re: Microsoft extensions to XSL (w, Chris Maden |
RE: alternatives to XSL (was RE: Mi, Ed Nixon | Date | Re: Microsoft extensions to XSL (w, Tyler Baker |
Month |