Subject: Re: XSL and HTML From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Thu, 14 Jan 1999 11:07:11 +0200 |
Paul Prescod <paul@xxxxxxxxxxx> wrote: >Guy claims that if XML does not directly support HTML developers will "do >their own thing" and that will hurt XSL and the W3C. The only problem with >that theory is that "doing their own thing" is exactly what the W3C would >recommend you do for server-side translations. Ah, but I'm running my XSL->HTML/JavaScript conversion on the client side :-) >Comparisons to the frames issue is not relevant. Frames are distributed on >the wire. ASP is not. And I am sending XML over the wire to be converted to HTML inside the recepient browser :-) >On the wire, translating to HTML+JavaScript makes no sense. Well, I'd love to see an alternative. Not only it reduces my bandwidth by a large factor, it allows me to generate HTML tailored to the extact browser version the client is using (without burdening the server with any extra CPU load), _and_ there's built in support for this inside IE5. Oh, and it will work _today_ inside any Java/JavaScript enabled browser. Still makes no sense? >Sure, we need >interactivity, but generating Javascript code is not an intelligent way to >do it. Since the W3C's mandate is to build a robust information system for >the future, I expect that they will continue to keep their priorities >clear. Delightful. So until they come up with something better - and I'm not saying they won't, just that it will take a year or two - until then, I'm expected to twiddle my toes and not distribute interactive applications on the Web? It isn't as if the technical issues in question require overhauling XSL, corrupting it with numerous tags which will compromise it forever. What we need is a very small number of tags, all of which are variants of <xsl:text>, are trivial to implement, and would get all these anoyying dHTML/JavaScript people of your back so you can work in peace on the right solution. For the record, I'm talking about <xsl:cdata>, <xsl:char-entity> (which arguably fall under the current intent), <xsl:not-xml>, and <xsl:ecmascript-string> (which don't). For all I care, name them <xsl:x-not-xml> and <xsl:x-ecmascript-string> so that people will know they are 'extra' tags and might be removed in the future, make it clear that if you use them you can't verify that the output conforms to any DTD, and so on. What possible advantage there is in _not_ providing these tags is beyond me. Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
XSL and HTML, Paul Prescod | Thread | Re: XSL and HTML, Guy_Murphy |
Re: GOTCHA!, Oren Ben-Kiki | Date | Re: GOTCHA!, David Carlisle |
Month |