Improving XSLT in the browser, was: Use cases

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