SVG Plugin for IE
Project SVG Plugin for Internet Explorer
Situation and Background
SVG is coming of age in the web and web-application eco-system. Three major browser projects/vendors (Opera, Mozilla and Webkit) are steadily improving their native SVG support. At the SVG Open 2008 in Nuremberg, all three browser projects and/or companies were present and confirmed their intention to fully implement their SVG support towards SVG 1.1 Full and selected SVG 1.2 Tiny features useful for web-applications and the HTML5 environment. The fourth big web browser, Internet Explorer, is still lacking native SVG support, despite the fact that vector graphics support is the most critical and requested feature for the Ajax developer community (see Open Ajax developers poll). The most widely used SVG plugin, the Adobe SVG viewer, is not being supported any more and is falling behind from a technical point of view and standards support. There is also the risk that upcoming Internet Explorer versions or MS Windows service packs will prevent the Adobe SVG viewer plugin from working, due to incompatibilites and lack of support. Examotion's Renesis plugin is not yet mature enough and does not implement a large enough subset of the SVG specification for many SVG applications. It also lacks the support of a larger company or organization behind the product, which may be a problem for the distribution of the plugin. At the SVG Open 2008 conference, Examotion stated that it's customers' needs come before testsuite conformance (i.e. interoperability). Having a mature plugin alternative for Internet Explorer would also allow Examotion to concentrate on developing better SVG authoring and animation tools and workflows. It would free Examotion from the large burden of being the only company actively developing an Internet Explorer SVG plugin.
While the market share of Internet Explorer is still decreasing (somewhere between 50 and 80% market share, depending on the country), it is still the predominant browser in many corporations and government organizations. While home users are quicker to adopt more powerful and standards-compliant web browser technology, many corporations or government organizations are still reluctant to adopt to alternative browsers, despite the fact that they are technically superior. There is a common perception within the SVG user and developers community that Internet Explorer will remain an important web-browser platform at least for the next couple years. If SVG wants to succeed on the open web, a mature SVG plugin solution for Internet Explorer has to be provided within the next couple of months. This would bridge the gap until Microsoft decides to natively implement SVG and would also increase the pressure on Microsoft to act. If no mature SVG plugin solution is provided for IE in the upcoming year, SVG will remain a niche-solution that mainly lives within intranet solutions, mobile or embedded devices, but not in the open web and the increasingly important web applications arena.
There is an increasing trend within the European Union and other countries towards open standards not controlled by individual corporations. Presentations and discussions at the SVG Open 2008 conference in Nuremberg showed that interest in SVG solutions is still high and rising, across all media, industry and within the academic community. There is also the fear that proprietary technologies such as Adobe Flash and Microsoft Silverlight might prevent the development of a dynamic and open web, where interactive web content can be developed on equal grounds, regardless of the operating system, user agent or workflow used to access the content or information. SVG, in combination with the XML ecosystem, (X)HTML, CSS and Ajax technologies, has the potential to guarantee an open web architecture and open access to visual information on the web and multimedia content. However, the success of the above mentioned technology combination, is also closely tied to the ability to deploy it on all major web browsers and user agents. Tim Berners-Lee only recently announced that he is disappointed about the lack of SVG support in Internet Explorer, which is holding back the use of SVG on the open web. This was even published on MSNBC. A SVG plugin solution for Internet Explorer has therefore to be found in the upcoming months.
A SVG plugin for Internet Explorer has to be developed which implements the SVG 1.1 Full specification as completely as possible. The plugin must feature good performance and tight integration with the other web technologies implemented natively within Internet Explorer. It must be possible to access the SVG DOM from the HTML DOM and vice versa. Ideally, the rendering of HTML or other web content would be supported inside the SVG canvas using the foreignObject technology. The plugin should be tested (QA) and maintained for the upcoming years until Microsoft implements SVG natively. It would also be nice if a mixed HTML/SVG document (inline SVG) could be supported, though is not strictly necessary for the first versions of the plugin. The Adobe Plugin supported this mode through "binary behaviors".
A solution should be found ideally by the end of the year 2008, but at the latest until spring 2009. The vendor or project implementing the plugin should have the ability to provide support for the upcoming years or until Microsoft provides native SVG support. It should also provide updates, especially if the underlying framework makes significant improvements toward better standards compliance, performance or integration.
The Different Options
There are three economic solutions. All of them build on existing SVG rendering technology.
Use of the SVG rendering technology present in web-browsers with native SVG support (Opera, Mozilla or Webkit) Use of the SVG rendering technology present in SVG mobile User Agents such as the Bitflash or Ikivo SVG viewing technology Use of the Apache Batik toolkit
Licencing issues would have to be investigated. Some implementations potentially rely on components or libraries where the licensing situation would prevent re-use for the use in an SVG plugin for IE or as an ActiveX component. All three options have the advantage that the SVG rendering component would potentially not only be available for the IE browser, but also for other Windows applications.
Following, the advantages and the disadvantages of the different approaches and projects are discussed.
Use of the SVG rendering technology present in web-browsers with native SVG support
- Renderers are already targetting SVG 1.1 Full, which should also be the medium term goal in IE
- SVG technology is already designed to interoperate with other web technologies present in a web-browser
- Many of the alternative desktop web browsers are already present on the Windows desktop. They could register themselves as an ActiveX component and Internet Explorer plugin in parallel with the browser installation.
- Could potentially not only improve SVG support, but also support other web-technologies, such as Canvas2D (Open Graphics plugin)
The Opera option
- The most complete SVG 1.1 support available on desktop browsers
- Already implements some SVG 1.2 Tiny features
- Supports SMIL Animation
- Supports SVG Fonts
- Supports External References
- Opera is committed to Open Standards
- Opera is the SVG technology leader and the most active supporter of SVG among the desktop browsers
- Opera is active in the SVG working group and very supportive towards SVG content developers
- Opera has extensive know-how and experience in cross-platform development - supports the largest number of platforms and devices of any webbrowser on the market
- Not an Open Source Solution - does it matter?
The Webkit option
- Strong support of OS developers (KDE)
- Webkit increasingly used in many (web)-projects and supported by major companies such as Trolltech/Nokia, Apple, Adobe, etc.
- The fastest DOM implementation of the three web browser alternatives
- Supports SVG Fonts
- Supports External References?
- Integrated with Trolltech technology which already has options for developing browser plugins
- Not as mature as Opera
- SVG standards compliance not yet as complete as Opera
- SMIL still under development
- Filters still under development
The Mozilla option
- Already has large install base on Windows
- Good reputation in the public and the press (even my grandma knows about Firefox!)
- Good financial support from Google
- Mozilla proved it is possible to embed the Gecko rendering engine in Internet Explorer - see MozIE
- From the three desktop browsers, the least advanced regarding SVG support
- SVG standards compliance not yet as complete as Opera
- SMIL still under development
- Filters still under development
- No SVG Font support
- Hasn't been a strong SVG supporter in the past, but improving
Use of the SVG rendering technology present in SVG mobile User Agents such as the Bitflash or Ikivo SVG viewing technology
- Renderers are usually well optimized regarding the use of memory of CPU, because they target mobile devices
- SVG mobile viewers are quite fast
- Good multimedia support (audio/video)
- Already implement SVG 1.2 Tiny features
- Would have to improve towards SVG 1.1 Full, adding missing features
Use of the Apache Batik toolkit
- Very standard compliant
- SVG fonts support
- SMIL support (not 100% complete)
- Support for External References
- Requires presence of a recent Java Runtime Environment (JRE)
- Some problems with element references when source changes (changes not re-applied to instances)
Use of the rendering technology present a widely deployed plugin (Flash)
See the SVG Web shim project.
- Requires no user download (I think it is safe to say that most IE users will have Flash installed)
- Using technologies like IE Binary Behaviors, it is possible to 'shim' SVG DOM support into IE
- In some cases, the Flash plugin might not be available (Linux platforms). In these cases, the native SVG should be used
- There are some limitations in Flash (for instance, Flash does not support stroked text)
The benefits of Providing an SVG IE plugin
For the web
With a more widespread support of SVG in current web browsers the open web would benefit and SVG would really have the chance to come of age and play a more relevant role regarding graphics and multimedia content instead of being pushed back to niche applications in controlled environments. Internet Explorer, still having a market share of 60-80 percent, is an important target for SVG support. If no good solution can be found for viewing SVG content within IE, the overall adoption rate of SVG will suffer or the project of establishing SVG as a core web technology might even fail, providing more room for proprietary technologies, such as Adobe Flash or Silverlight.
For the Project/Vendor supplying the IE plugin
The project or vendor who supplies a mature SVG plugin for IE would not only have to invest resources, but would also benefit from the plugin development and a more widespread deployment of its own SVG viewing technology. Their SVG viewer technology would receive more widespread testing by the SVG content developer community since IE is still an important deployment target of web content and web applications, especially in the corporate and some government environment. As a result it can be expected that the overall quality of the SVG product used as the technological basis for the plugin will increase, because of the more widespread use of the respective SVG viewing technology on the web. The project or vendor supplying an SVG IE plugin will receive positive press, will be regarded as a technology leader and will be regarded as an important player when it comes to enabling and promoting open web standards and securing an open future of the overall web. The project or vendor supplying the IE SVG plugin may use the increased momentum and awareness level around its products or software projects to advertise for other SVG or web-application related products, such as SVG authoring systems, conversion tools, publishing workflows, debugging or other (content)-development tools.
For the SVG community
The SVG community benefits from an increased availability of SVG viewing support. It can again offer SVG based solutions for IE based intranets and the open web. If an already established SVG viewing technology can be re-used as a base for an IE SVG plugin, it also benefits because it has one implementation less to test against. If browser or viewer XY is also used as the base for the IE SVG plugin, it can be expected that it behaves at least very similar inside IE as well, except maybe a few integration issues within the IE browser, where the SVG viewing technology may behave slightly different than in the original platform.
Ideas for Financing the project
It is expected that the plugin development would require a 100% developer position over several months in order to ensure proper integration with the rest of the web standards and the DOM in IE. Many corporations, organizations and individuals have a strong interest in the availability of SVG in the IE browser. It can be expected that a large enough momentum can be gained to financially support the plugin development if the organization or company that does the implementation cannot bring up enough financial resources for the development of the plugin. Large companies that have an interest in the open web, such as IBM, Google, Yahoo, HP, etc. can be sponsors. Small and medium size companies that have a strong financial interest in SVG, because their product relies on a wide availability of SVG rendering in browsers can be expected to financially contribute. Microdonations of individuals would complement corporate sponsoring. Individuals and open source projects could also potentially contribute time resources for testing and marketing the plugin. A list of sponsors and contributors would be made public at a prominent SVG website, such as svg.org or the W3C SVG website. The SVG interest group can help to raise financial funds and raise awareness of the project.