Google To Host International SVG Conference
stelt writes "On Oct.2–4 Google will host the international conference on Scalable Vector Graphics at its campus in Mountain View, California. The SVG Open conference schedule shows developers and designers of various backgrounds. Major brands, open source projects, universities, and individuals are presenting on a variety of subjects like interactive scientific visualizations, mobile web animation art, internationalization and localization in print, geo-systems, etc. A couple of weeks back we discussed Google's adding SVG support to IE, and details of this project will be presented during the keynote 'SVG in Internet Explorer and at Google.'" Early-bird registration has already ended for this conference, but the pricing is not steep.
SVG is a stateful 2D scenegraph API while WebGL is (mostly) stateless 3D API. So are we going to see SVG obsolete a few years from now, when devs start coding their own scenegraph frameworks in javascript using WebGL? I personally am biased towards WebGL due to its Opengl ES 2.0 roots.
You may want to look up previous postings on /. regarding SVG.
Here's a quick list:
1) The complete SVG standard is huge. While every modern browser "supports SVG", they really only support certain subsets, and these are not consistent between the different browsers.
2) You need development tools for designers in order for it to take off. Since Adobe bought Macromedia (and thus push Flash like crack), few companies have the manpower/skill to create a dynamic (animation-friendly) design/development environment targeted at web *designers*. You need SVG to be adopted by graphic designers, not just programmers.
3) Flash.
4) Flash.
5) Canvas is a much simpler and smaller standard, and it's much easier to implement. Browsers that integrate Canvas usually implement it in its entirety, and then they can place the "supports Canvas" sticker on their list of features. To do so with SVG would take too long and would require a lot more resources.
The path of least resistance is not SVG. It's a very promising standard, and programs like Inkscape have done wonders with it (and so has KDE), but in browser-land there are simpler solutions that are more widely supported.
Entomologically speaking, the spider is not a bug, it's a feature.
Microsoft was one of the original working partners of the SVG specification. They were in a position to support it at the outset, and even published an article about SVG in their premiere magazine. I remember going to a Microsoft conference back around 2000 and, when asked about the long-term viability of ActiveX, the Microsoft reps (who were actual developers and not just talking heads) spoke enthusiastically about how they were working with Corel (another SVG author) on a fabulous new vector graphics technology.. ..and then it got iced. If I had to guess at a reason, I would point to the ascension of internal "vector" technologies like XAML, and of course they already had VML.
I'm seeing a few posts here complaining that Microsoft won't implement the SVG 1.1 standard in Internet Explorer.
I would argue that as long as Microsoft continues to push Silverlight (which is just browser-safe WPF) as their form of a vector graphics applet for their web browser, any alternative approach within MS is going to stagnate. Silverlight is their attempt to build a Flash-alternative with a SVG programming framework, which is (to Microsoft) a "best" of both worlds. To the rest of us coming from the WinForms world, it's a so-so product that's really awkward to use. I known that MS is pushing Expression Blend as an alternative to Adobe CS3's UI, but really, why didn't they just integrate it into Visual Studio for native editing instead of all this back-and-forth multiwindow crap.
For example, SVG Shapes vs WPF Shapes. It's no accident that the syntax is almost exact. But why would Microsoft embrace SVG directly, with its Javascript code triggers, when they can go the Silverlight route with .Net triggers.. it's basic product bundling, to get you to use Microsoft's approach to everything.