David Hyatt has posted in the Surfin' Safari blog that Safari nightly builds now have partial support for SVG 1.1. You can see the status of the Safari SVG implementation here. This marks the third browser that allows you to integrate HTML and SVG and script it via an XML DOM.
I don't have the ability to test Safari builds since I have no Apple machine. However, looking at the Status page, currently BIG things are still missing/borked:
- No SVG <text> support (Bug 4883). No SVG <font> support.
- JavaScript bindings are broken. Bug 4249. Looks like this means that all scripting is currently broken.
- Declarative Animation is mostly unimplemented and/or broken.
Oddly, they support a hefty chunk of SVG Filters, a fairly advanced feature in SVG. I hope the status page is out of date, but I won't be surprised if it is. In my mind, SVG text is an absolute must. Next, I would hope they get JavaScript fixed, since you can work around missing declarative animation with the help of scripting. If they can get these two major pieces implemented and fixed before the Safari release, I would be much happier. Yet I still cheer on the WebKit team for doing fantastic work.
In an ideal world, browser vendors would be first targeting complete support for the SVG Tiny profile as an initial implementation, just like Opera 8 did. Unfortunately in the open source environment of Mozilla, Konqueror and Safari, this is not always a reality. Open Source projects have to take what they can get... Up to this point, the Safari SVG effort has been one of integrating the KSVG Konqueror plugin with WebKit platform, so really Safari inherits whatever flaws the KSVG plugin has. As the KSVG2 plugin is deployed and improved the updates should flow smoothly into WebKit/Safari and hopefully we'll see cooperation back and forth between the Konqueror and Safari projects in terms of SVG improvements.
That said, I'm one of the folks that thinks incremental SVG support can be a good thing, not a bad one. I think there enough cool things in SVG that lots can be done with even primitive features like shapes, paths, text, grouping, gradients, opacity, transformations and raster graphics. SVG also includes the <switch> element so that web developers can provide fallback content for partial implementations. In other words, SVG was designed such that partial implementations can still be useful.
Providing fallback content may be more work for web developers now, but ultimately it lets more people get their feet wet with the technology which is important in capturing mind share. The more browsers that get involved with implementing SVG, the more web developers will get involved with it which will have a positive feedback effect in the SVG web support space.
Unfortunately, where there's software, there are bugs. In my opinion, buggy implementations of SVG features can be much worse than not supporting the feature at all (depending on the bug severity of course). So if you're going to ship a scattershot/partial implementation, the best thing you can do is fix your bugs on those supported features and ship updates as often as possible (ideally in an automated fashion a la Firefox 1.5). I am very disappointed in the fact that Mozilla will not be shipping a product with any SVG fixes (for bugs like these) until 2007 - I hope that policy will be changed as time marches on, but if not I will be relying on Opera 9 when it is finally released.