Apple Sees XSLT Light, Adds Javascript Invokable Client-side Transforms to Safari 3

by M. David Peterson

Update: In a follow-up comment, Dave Johnson provides us with our quote of the day,

If only all browsers had the same XSLT support as IE ... and IE worked like other browsers in every other respect ;)


I'll just let that one speak for itself ;-) :D

[Original Post]
Todd Ditchendorf's Blog. XML, Cocoa, JavaScript, Java. � Blog Archive � Safari 3, JavaScript, and XSLT

Safari 3 for Windows and Tiger is truly awesome news.

Just a feature note: Safari 2 has always supported client-side XSLT. But Safari 3 includes and implementation of the Mozilla-style JavaScript XSLT API... so now you can programatically execute XSLT transforms on the client via JS in Safari. Great news.


SWWWEEEEEEEEEEEEETTTTTTTT!!!! :D :D :D

Let's see, so that just leaves Opera left holding the "why is there no support for [fill in missing Client-side XSLT feature, in this case the document() function ;-)" bag**, but something tells me that within a reasonable distance of time, Glenn will *FINALLY* get to see the light of day. ;-) Poor guy must be getting antsy, huh?!

Hang in there, Glenn! There's hope still yet, and as I alluded, I have an itchin' suspitchin' the company behind my most favorite browser on the planet is going to pull through for us.

** Though I wonder if Safari has migrated any of the EXSLT functionality from libxslt, in particular the node-set() function? Anyone know off hand? If no, then Opera still has one leg up on Safari. Of course they still have one leg down on Safari as well. ;-)

12 Comments

David Carlisle
2007-06-20 04:28:27

still no exslt:node-set in safari I think. At least it didn't appear to be in the windows version that I tried.


no xslt2 either :-(



M. David Peterson
2007-06-20 04:36:18
Hey David,


>> still no exslt:node-set in safari I think. At least it didn't appear to be in the windows version that I tried. <<


Drat! Well, it's still early alpha code, and progress is progress, so there's definitely still hope.


>> no xslt2 either :-( <<


I wouldn't be surprised if MSFT were to pull through on this one first over the rest of the pack. I mean, they're traditionally 7 years ahead of the pack, and its been, what, just over 7 years since XSLT 1.0 was realeased?


Uh, oh... Clocks tickin', MSFT! ;-) :D

Sjoerd Visscher
2007-06-20 10:00:02
Safari doesn't yet support params (I mean to the xsl, not templates) with XML values, only string values.


And MSXML is still the only implementation that supports user-defined functions.

Dave Johnson
2007-06-20 18:20:16
It is about time!


If only all browsers had the same XSLT support as IE ... and IE worked like other browsers in every other respect ;)

M. David Peterson
2007-06-20 19:05:02
@Sjoerd,


>> Safari doesn't yet support params (I mean to the xsl, not templates) with XML values, only string values.


I assume by this you are referring to the ability to use inline XML inside of a variable and to treat it as such? If yes, then yeah, that's the one missing feature that all of the other browsers provide in one capacity or another via *:node-set(). The cool thing about this is because Safari uses a subset of libxslt, and because libxslt provides support for exsl:node-set(), integrating support should be pretty straight forward. Hopefully they will do just that!


>> And MSXML is still the only implementation that supports user-defined functions. <<


Yeah, this is definitely one part of EXSLT/XSLT 2.0 that I wish the browser vendors would embrace. But, one step at a time. :)


Thanks for your comments!

M. David Peterson
2007-06-20 19:06:17
@Dave,


>> It is about time!


Amen to that!


>> If only all browsers had the same XSLT support as IE ... and IE worked like other browsers in every other respect ;)


:D :D :D I think we have ourselves the quote of the day :D

Sjoerd Visscher
2007-06-21 00:55:30
Actually I meant proc.setParameter(null, "test", xmlNode), see
http://bugs.webkit.org/show_bug.cgi?id=14101
M. David Peterson
2007-06-21 02:15:34
@Sjoerd,


>> Actually I meant proc.setParameter(null, "test", xmlNode) <<


Ahh, got it. Thanks for the clarification and the link!

Jess Holle
2007-06-21 04:14:45
Firefox doesn't have node-set either yet - nor XSLT 2. Without either of these it's utility for client-side XSLT is rather limited at this point.
M. David Peterson
2007-06-21 04:56:15
@Jess,


>> Firefox doesn't have node-set either yet - nor XSLT 2.


That's true about Fx 2.0, but Fx 3.0 (available now as code name GranParadiso) provides fairly extensive support for EXSLT, including node-set(), so while the support isn't a part of a released version of Fx, the support is not too far in the future.


> Without either of these it's utility for client-side XSLT is rather limited at this point.


I agree that w/o support for node-set() things are a bit limited, but a lot of power still exists in XSLT 1.0, and in the context of the browser and at this stage of the game, I would *MUCH* rather see the browser manufacturers rally around providing extended support for EXSLT than having fragmented support for XSLT 2.0. In other words, it seems to be a much more likely scenario to find the browser manufacturers willing to extend their existing 1.0 processors with EXSLt that it would be to expect all of them to jump on the XSLT 2.0 bandwagon. I'm not suggesting I don't want them to, just that these kinds of things have to be looked at from a "what's the most likely avenue to achieve consistency across browsers" as opposed to a perfect world scenario where gaining wide-spread support for XSLT 2.0 would obviously be the ideal situation.


Thanks for taking the time to provide your comments!

Kurt Cagle
2007-06-26 17:49:48
Good to see that you included the reference to the node-set() functionality appearing in FF3. While I like XSLT2 a lot, the node-set() functionality that lets you create intermediate XML for processing within a transformation made a great number of things possible in XSLT1. Without it, XSLT1 is too underpowered.


I suspect that extension function support will likely be the next major nexus of support for Firefox, and given that Safari has had a tendency to follow Firefox's lead, I suspect this will push that capability into Safari as well. Lack of extension functions is one of the big limitations in the Mozilla XForms implementation, though this can be partially overcome with bindings.

M. David Peterson
2007-06-26 23:44:47
@Kurt,


>> Good to see that you included the reference to the node-set() functionality appearing in FF3. While I like XSLT2 a lot, the node-set() functionality that lets you create intermediate XML for processing within a transformation made a great number of things possible in XSLT1. Without it, XSLT1 is too underpowered. <<


Could not agree more!


>> I suspect that extension function support will likely be the next major nexus of support for Firefox, and given that Safari has had a tendency to follow Firefox's lead, I suspect this will push that capability into Safari as well. <<


That would rock! I agree, extensions functions are the next logical step for browser-based transforms. With them you can obviously make up for a lot of the things that would be *GREAT* to have natively but can just as easily be implemented as an extension, so can be lived without. Of course, consistency in both language support as well as implementation is obviously critical, though JavaScript is an obvious given, and EXSLT provides the consistency model, so it seems that this is really where the focus needs to be placed.


Thoughts?