Re: SVG interoperability
Hi Eric, In general I think I have to agree with all of what Robin has said-- the state of SVG from the outside may look dismal but it is moving along very well and is in a usable state. Many people make a large deal about the partialness of implementations but it isn't like the Mozilla folks went off and built a partial subset of the most useless features-- they built the most commonly used (and agreed on) subset. And having that is a great advancement to having what we have now. So granted, there are limits on Filters and Animation (in FireFox), and there are a couple of unfortunate bugs-- but once you know them they can be avoided. Additionally, there are currently projects in affect that do page rewriting in the absence of SVG support (in IE) to utilize VML to accomplish a subset. Again, this is sub-optimal but can be used to accomplish a limited subset. The fact that several major players are using SVG in their web 2.0 apps successfully indicates that it is at least the basis for a short term strategy. In terms of detection in FireFox, my guess is that you could design your page to be embedded in HTML (using the description from the SVG Wiki) and insert a simple detection script. Adobe supports a lot of non-standard script functions so a detection script in a try catch would be fairly easy. In the case of a single SVG page-- UA detection is simple regardless (and is used fairly often when trying to work with some of the ASV3 bugs). I wonder if Robin has numbers somewhere that says that there are more Mobile Phones with SVG support than there are copies of IE in use. It seems the mobile players always have amazing stats like that at their fingertips :) All the best, Jeff Rafter Eric van der Vlist wrote: > Le lundi 19 juin 2006 à 15:51 +0200, Robin Berjon a écrit : >> On Jun 19, 2006, at 15:44, Mitch Amiano wrote: >>> Robin Berjon wrote: >>>> I haven't investigated but I think there may be a way of telling >>>> Firefox to use a plugin no matter what. >>> There is. See http://www.mozilla.org/projects/svg/faq.html#svg-plugin >> Sorry, that's not what I meant. I know about the about:config SVG >> enabling flag, it's nice for development and all. What I meant was a >> way of forcing the triggering of the plugin through *content*, so >> that you can know that anyone using FF1.5 will have to rely on an SVG >> plugin rather than on the native support. > > Or at least a way to detect whether a Firefox browser uses its native > SVG support or an Adobe SVG plugin. > > Even that doesn't seem to be obvious. All the scripts I have found > (inclusing the Adobe "auto install script)) are testing if there is a > plugin to support SVG. > > Unfortunately, this allows to check that: > > 1. SVG is supported > 2. The Adobe plugin is installed > > but not that the native support is disabled. > > Access to the configuration options (both read and write) is reserved to > privileged scripts (which seems reasonable) and it doesn't seem that the > svg.enabled flag can be tested. > > A hack could be to try to something that is supported only by the Adobe > plugin and check what's happening (maybe animate an invisible point > through smile and test if the the point has moved) but that would be > rather dangerous IMO. > > Eric
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format