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. ;-)
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 :-(
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. > no xslt2 either :-(
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.
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 ;)
@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.
@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
Actually I meant proc.setParameter(null, "test", xmlNode), see
http://bugs.webkit.org/show_bug.cgi?id=14101
@Sjoerd,
>> Actually I meant proc.setParameter(null, "test", xmlNode)
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.
@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!
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.
@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. > 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.