- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 03 Jan 2011 22:54:05 +0100
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- CC: John Cowan <cowan@mercury.ccil.org>, Norman Walsh <ndw@nwalsh.com>, public-html-xml@w3.org
On 03.01.2011 01:31, Benjamin Hawkes-Lewis wrote: > ... > If the root problem addressed by Use Case 4 is developers want easier > ways to generate views from models expressed in XML, maybe energies > should be redirected from fiddling with text/html parsing to > investigating how XSLT could be improved so it doesn't suck so hard. Why It doesn't suck at all. :-) But of course it would be great to make improvements. > don't more developers use XSLT? Why don't any popular browsers support > XSLT2 natively? How about adding convenience APIs to XMLHttpRequest to > pass XML responses through a transform? How about designing HTML > features to bind parts of an HTML page to be updated from an XML backing > model using XSLT? I'd love that; however I don't think *this* is the right place to discuss these. If we can find more people interested with this, we may want to move that discussion somewhere else. My thoughts on this: - get more UAs to implement a bigger set of exslt (assuming we won't get XSLT2 any time soon); there are patches for Firefox waiting to be included, and Webkit simply can white-list more of the exslt code already present in libxslt; IE doesn't need to participate because these extensions can be emulated using msxsl:script. - maybe more control over XSLT application using HTTP link header extensions (such as setting parameters) - as Benjamin said, more consistency in XSLT related JS APIs (I uave to admit I haven't looked at those for a long time) - maybe new declarative feature for client-side inclusion of XML fragments transformed by XSLT (this feature was recently requested on the WHATWG mailing list). - progressive rendering of the transform result (IE gets this right) > ... Best regards, Julian
Received on Monday, 3 January 2011 21:54:47 UTC