The lastest Webkit nightlies and Safari 3.1 claim they do not support SVG: <script type="text/javascript"> alert(document.implementation.hasFeature('http://www.w3.org/tr/svg11/feature#SVG', '1.1')) alert(document.implementation.hasFeature('org.w3c.dom.svg', '1.0')) </script> Both return false. Earlier versions of Webkit (and Safari 3.0.x betas) return true (at least on the second check) as they should.
These particular checks return false now because we don't support all of SVG. Is there a specific site this is breaking?
Well, a few thoughts: This is a change from Safari 3.0.4, which returned true. Why would 3.1 now return false? This change did break our site, http://www.mapbuzz.com. We use hasFeature to detect whether a browser supports SVG or not. If it does not, we assume the browser is IE and we switch to VML. Safari 3.1 broke that, so now we have to add in an extra kludge to see if the browser is safari, check the version, and act accordingly. That seems like much more of a kludge then using hasFeature. Also, from what we can see, Safari supports as much SVG as Firefox and Opera and both return true for hasFeature, so it seems reasonable for Safari to do the same. Last, the SVG spec does allow browser makes to describe in detail what parts of the SVG spec they do support. As I'm sure you've seen: http://www.w3.org/TR/SVG/feature.html It does seem like this is what hasFeature is meant for... Thanks for the help.
Any additional thoughts or progress on this?
The link you gave (http://www.w3.org/TR/SVG/feature.html) lists precise requirements a browser should meet to claim support for each feature. My understanding is that we need to fully support org.w3c.svg.static (which we don't do) to claim support for org.w3c.dom.svg. Are you saying that we actually meet the requirements, or that we should ignore the spec, as other browsers may do?
SVG's feature strings are awful. They require you to implement the 400 of the 405 pages of the spec before you can claim any one of the more useful feature strings. This is at least the 3rd bug we've had filed about our feature strings. We used to claim to support SVG static until someone filed a bug after 3.0 shipped arguing that we shouldn't claim to support static if we don't support fonts, filters, etc..... which was true at the time. Currently our filter support is broken and we're missing a few other tiny parts, so we don't claim svg static support yet. See: http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/dom/DOMImplementation.cpp#L102 I suggest you test against a couple of the individual strings for now. if a browser claims to support hasFeature("http://www.w3.org/tr/svg11/feature#BasicShapes", "1.1") you can probably assume it supports enough SVG for your purposes. *** This bug has been marked as a duplicate of 10297 ***
Oh... also, if FireFox is ignoring the SVG spec and claiming hasFeature when they shouldn't please report a bug to http://bugs.mozilla.org/ That makes hasFeature even more useless if they violate the spec.
I'm saying that Webkit ignore the spec and do as Opera, Firefox and previous version of Safari do. There are two reasons for doing this. Most importantly, a comparison of http://webkit.org/projects/svg/status.xml and http://www.w3.org/TR/SVG/feature.html shows that although Webkit does not meet the letter of the specification, it supports a large portion of the SVG spec and therefore returning true from hasFeature seems reasonable (particularly since Firefox, Opera and earlier versions of Safari have set that precendent). Second, it makes life easier for developers. I think most people would agree it is more robust for Javascript code to check the availability of the features it wants to use as opposed to guessing based on browser detection. Currently, both Firefox and Opera advertise their support for SVG via hasFeature, although debatably both implementations are not as complete as WebKit's. The alternative, is to take a hard-line and say that no browsers support SVG (and that Firefox and Opera are wrong). But in the real-world, that would force developers to use browser detection, check the version number, and act accordingly. That seems like an uglier approach, and just adds to the differences between browsers that make Javascript development more difficult than it should be. In addition, because of the complexity of the SVG specification, you could end up in a situation where browsers could never claim to support SVG, although they implement the vast majority of the spec. I don't see how that helps anyone in the end. Thanks again for looking into this....
To follow up on Eric's point - I think its a lot more useful for hasFeature to return true, then having it return false for the forseeable future. However, his idea to check BasicStructure (there is no BasicShapes that I see) is a good one and does work. Previously, we had checked the 1.0 strings and a few of the 1.1 strings but hadn't found one that returned true. That one does, so it will be good enough for our purposes. However, I stick with the original point that Webkit/Safari/Opera should align themselves on what they are saying, ignoring the spec if needed.