Implementing SVG in a Web Browser

Past, Present, and Future of Mozilla SVG

Keywords: Mozilla, Gecko, SVG

Timothy Rowley
IBM Corporation

John "Scooter" Morris
University of California, San Francisco

Jonathan Watt
University of Strathclyde

Alex Fritze
croczilla.com

Abstract

Table of Contents

1. Introduction
2. Brief History of the Mozilla SVG Project
     2.1 Early attempts at implementing SVG in Mozilla
     2.2 First Generation Mozilla SVG
     2.3 Second Generation Mozilla SVG
     2.4 Third generation Mozilla SVG
3. Current State of the Mozilla SVG Project
     3.1 SVG 1.1 Completeness and Conformance
     3.2 Compound Documents
     3.3 Renderers
     3.4 Performance and Code Size
4. Opportunities and Challenge
     4.1 Opportunities
     4.2 Challenges
5. Why Release Mozilla SVG Now?
6. Future Directions
     6.1 Next Release
     6.2 SVG 1.2
7. Getting Involved
8. Conclusion
Bibliography
Footnotes

1. Introduction

The Mozilla foundation is the home to a number of open-source projects, the most well-known being the Mozilla Firefox browser, the Mozilla Thunderbird E-Mail client, and the Mozilla Application Suite. The recent release of the 1.0 versions of the Mozilla Firefox browser and Mozilla Thunderbird E-Mail client have created a great deal of momentum as alternatives to the dominant browser and e-mail client. Mozilla Firefox has been downloaded over 60 million times, and Mozilla Thunderbird downloads have exceeded 2 million [7]. While downloads don't translate directly into usage numbers, many analyses of web site statistics report substantial movement to Mozilla Firefox, which combined with the Mozilla Application Suite has increased its market share to somewhere between 6% and 37%, depending on the survey, audience, and locale [8].

The Mozilla applications mentioned above are all built on 'Gecko', a common core which provides rendering, layout, networking, and other common services. Key to this common core is the presence of parsing and layout modules that provide one of the most standards-compliant implementations of an Internet browsing environment. In addition, the Mozilla core provides standards-based support for important and common scripting capabilities such as the DOM and JavaScript (ECMAScript) specifications. Through the release of Mozilla Firefox in particular, millions of users have migrated to a browser which provides more complete support for many of the key technologies and specifications released since the last update of Internet Explorer in 2001. One area where the Mozilla core has not provided good support is in the presentation of non-bitmap graphics -- i.e., SVG.

SVG is an XML specification that can be used to describe graphical displays in terms of objects and graphical transformations of those objects. From the SVG 1.1 Specification [12]:

"SVG is a language for describing two-dimensional graphics in XML [13]. SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), images and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects. The feature set includes nested transformations, clipping paths, alpha masks, filter effects and template objects."

2. Brief History of the Mozilla SVG Project

2.1 Early attempts at implementing SVG in Mozilla

The Mozilla SVG project dates back to 1999. The first implementation was by an external contributor and had a partial implementation of <path> without styling. This work never made it into the mozilla source tree for reasons lost to history.

The next attempt was in early 2000, by two Netscape engineers. This implementation was capable of rendering unanti-aliased polygons and polylines and implemented just two attributes - stroke and fill - and didn't have any support for the SVG DOM. The implementation was restrictive in two ways that would have made it very difficult to progress beyond these features. First, SVG elements were rendered using the Mozilla rendering context, a least-common-denominator abstraction of the rendering APIs on the different platforms, such as GDI on Windows or GTK on Linux. The Mozilla rendering context was neither capable of providing support for the stroke/fill model, nor the set of affine transformations required for an SVG implementation. Second, this early SVG implementation was not scalable to a DOM implementation since it consisted of XML elements whose rendering had been "hacked up" in Mozilla's layout engine. Since the implementation did not utilize the standard frame construction mechanism, and did not provide the necessary DOM "hooks", adding a DOM implementation to these parts or adding CSS support would not have been an option.

2.2 First Generation Mozilla SVG

In late 2000, the company Crocodile Clips [1] become interested in using Mozilla as a platform for a new educational geometric modeling software, Crocodile Mathematics [2]. What attracted Crocodile Clips to Mozilla (apart from Mozilla's XUL [3] user interface capabilities) was the possibility of using extensible binding language (XBL [4]) to create an XML serialization format for Crocodile Mathematics' content files. The idea was to leverage Mozilla's inherent compound document functionality and use SVG, HTML and MathML as rendering primitives for CROCML, a new XML language of interactive graphical shapes and parts.

One of the main missing pieces needed for this idea to materialize was a significantly enhanced SVG implementation. In particular, Crocodile Mathematics required a proper implementation of the SVG stroke and fill and transformational model, support for all basic SVG shapes, alpha-blending, anti-aliasing, as well as a subset of the SVG DOM and CSS support. No text support was planned as it was felt that this could be provided by HTML via the compound document paradigm. Likewise it was decided that declarative animation would not be necessary, since most dynamic manipulation would be achieved through JavaScript.

In 2001, Crocodile Clips decided to devote development resources to the Mozilla SVG project to implement these required features. At that point the SVG project had been in a state of no development for several months and it became apparent that the code would have to be rewritten from scratch. During the following years, development was carried by one core developer and several other volunteers contributing features, bug fixes and builds for several platforms.

After evaluating several rendering libraries capable of the SVG stroke/fill and transformational models, Crocodile Clips decided to use the Libart renderer [5], for several reasons: it was light-weight, it was relatively portable across the initial target platforms (Windows, Linux), and its licensing terms (LGPL) were broadly compatible with the Mozilla Public License (MPL). Another interesting feature of Libart that made it attractive to an SVG implementation was Libart's Microtile arrays (UTAs): data structures that allow relatively fine-granularity, fast, space-efficient calculations of damage areas, making it interesting for the implementation of SVG in a non-hardware accelerated setting. Unfortunately, integrating the LGPL code into the Mozilla codebase spawned an ongoing debate on whether this code could ever be distributed with Mozilla because of the Mozilla Foundation's commitment to the MPL. As a result, cairo [8] and platform-native APIs have since been chosen to replace Libart.

The first usable version of the SVG code rewrite using the Libart rendering backend and implementing parts of the DOM as well as CSS support was completed within the first few months of 2001. This rewrite was checked into a branch in the Mozilla CVS repository in late 2001, and later moved to the Mozilla trunk but not enabled by default in Mozilla builds. This first "proper" implementation of SVG in Mozilla consisted of 35,000 lines of code and was capable of rendering all of the basic SVG 1.0 shapes, paths, beziers, and curves with support for stroking and dashing (albeit with some syntactic differences to the published SVG standard). Most of the SVG DOM interfaces for these parts were implemented although some of the various element attributes and DOM interfaces were missing. For example, while event listeners could be attached to SVG elements using the XML DOM (addEventListener), event attributes were not supported yet.

2.3 Second Generation Mozilla SVG

After gaining some experience with the SVG implementation, XBL, and compound-document model of implementing CROCML parts, it soon became apparent that the compound document model as implemented in Mozilla did have some significant limitations. Foreign content, such as HTML text, would still be rendered in the normal Mozilla rendering content. Although it could be correctly composited with Mozilla SVG content with correct Z-ordering in most cases, because of the limitations of the Mozilla rendering architecture, it could not be rotated or scaled in the same way as other SVG elements (work is underway to change the Mozilla rendering architecture to allow this). Also, since rendering compound documents involves two different rendering frameworks, the implementation was quite inefficient for some configurations, e.g. Libart's native 24bpp image format doesn't match the pixel formats supported by the Mozilla rendering context and the whole bitmap buffer has to be converted back and forth between pixel formats for every occurrence of foreign content in an SVG document.

These problems and others led to the conclusion that for Crocodile Mathematics to progress, text support for Mozilla SVG had to be implemented. At first this was done by hard-coding fonts as SVG paths, with the obvious limitations in terms of performance and availability of font faces and styles that apply to this approach. It soon became apparent that there was no unified approach for integrating text support on all platforms with the Libart rendering backend and that it would be better to take advantage of native APIs where they were available on the different platforms (e.g. GDI+ on Windows, Quartz on Macintosh). It was also felt that moving over to platform-native APIs where these were available would enable the SVG implementation to take advantage of 2D hardware acceleration where this was available.

A redesign of the rendering backend architecture was hence embarked upon, again with one core developer. The backend architecture consisted of a set of XPIDL (Mozilla's Cross Platform Interface Description Language) interfaces that could be implemented by 'plug-in' rendering engine modules (Figure 1). Two different rendering engine modules were coded as part of this effort: a cross-platform Libart-based backend (the primary renderer for the Linux platform and a fallback for other platforms) and a GDI+ backend for Windows. The major feature addition in this generation of Mozilla SVG was support for SVG text (<text> and <tspan> tags). For the GDI+ backend this was supported natively by GDI+; for the Libart backend it was added by leveraging the Freetype 2 library.

Figure 1: Renderer Plug-in Architecture

After a long spell of on and off development on a CVS branch, this code was finally committed to the Mozilla trunk in early 2004, but, like previous versions, not turned on by default.

2.4 Third generation Mozilla SVG

Mozilla SVG is now entering its third generation. In 2004 a new team of developers (supported and volunteers) joined the development effort. As part of this renewed development effort, support for many new features was added, including markers, gradients, <use> elements, inner <svg> elements, <switch> elements, clip paths, viewboxes, <script> and <style> elements as well as event-attributes, SVG images, and proper group opacity. While previous iterations of development of Mozilla SVG were mainly driven by the requirements for a single commercial application, the emphasis of development shifted more towards standards compliance with the ultimate goal of a complete SVG 1.1 implementation shipping in standard Mozilla builds. The next section will discuss the current state of the Mozilla SVG project in some detail.

In some cases, enhancing Mozilla SVG's standards compliance was a matter of eliminating syntactical quirks. For example, previous Mozilla generations required a stroke dasharray to be given in single quotes (as in stroke-dasharray="'2,2'"). In other cases, inconsistencies of the SVG specification with existing standards such as CSS, prevented a fully compliant implementation. For example, the SVG standard allows a text sizes to be specified without a unit identifier whereas CSS explicitly forbids this. The SVG specification also leaves undefined significant parts of the implementation. For some of these areas clarification is being sought from the SVG working group (for example - [6]); for others, Mozilla's implementation behavior has been changed to fall in line with other implementations. For example, the Mozilla SVG code was changed to render asynchronously, whereas previously any change to an SVG element's relevant properties or attributes triggered an immediate screen update. While immediate updating could be suppressed by bracketing code in suspendRedraw()/unsuspendRedraw() calls, this was not immediately obvious to script authors, leading to complaints about poor rendering performance. One drawback of the asynchronous approach is that dynamic manipulation of SVG objects from mouse event handlers can now seem sluggish if the author doesn't take care to force a refresh with forceRedraw() in appropriate places.

As a condition of shipping Mozilla in default builds, an alternative to the Libart renderer had to be found, because of the licensing incompatibilities between Libart (LGPL) and Mozilla (MPL/GPL/LPGL tri-license). The cairo renderer has since been chosen for this purpose, and a cairo-based backend was implemented in early 2004. While this gave the licensing and portability desired, performance thus far has been disappointing.

3. Current State of the Mozilla SVG Project

The Mozilla SVG Project has now reached an exciting milestone: current Firefox and XULRunner nightly builds are SVG-enabled by default, and it has been announced that Firefox 1.1 will include support for SVG. This is a significant departure from the past where testers either needed to "build their own", or download an SVG-enabled build provided by someone who did build their own. While there are still significant parts of the SVG specification that have yet to be implemented, this new exposure has generated some much needed interest and attention.

One of the outcomes of this commitment by the Mozilla Foundation has been that some key Mozilla contributors are now much more available to provide help and assistance with those working on the SVG codebase. Their experience and attention has already provided significant benefits to the overall project in general, and to address the lack of Gecko experience within the SVG team. The new exposure will also prompt new testers and developers to get involved with more complete testing of the codebase and with the development of missing SVG features.

3.1 SVG 1.1 Completeness and Conformance

The current goal of the core Mozilla SVG Project contributors is to implement the full SVG 1.1 Specification. Having made much progress recently in implementing scripting, CSS styling, intrinsic (attribute style) event handlers, gradients and other features, base support for much of the specification is now in place. Nevertheless SVG is an extremely large specification, and there is much still to be done.

An SVG implementation's completeness is typically measured in terms of the SVG Modules it supports. In this respect Mozilla's native SVG implementation does moderately well (see Table 1). It provides good support for the Structure, Conditional Processing, Image, Style, Shape, Marker, Gradient, Clip, Hyperlinking, Scripting and Extensibility Modules. Although there remain known (and undoubtedly as yet unknown) issues with their implementation, they are largely feature-complete. Other modules such as the Text and Cursor Modules are either partially completed or have cross-implementation workarounds. The major missing SVG modules are the Filter, Animation and Font Modules. Some thought and planning has gone into the design of these modules, but little code has been written.

Table 1: SVG 1.1 Support in Mozilla

There are some limitations of the current implementation that content developers should be aware of. First, elements that refer to other elements (such as <use>) can only refer to elements in the same document. Second, <image> can only refer to raster image formats at this point. Third, <foreignObject> can only handle translations, not arbitrary SVG transforms. [1] Lastly, SVG content can only be handled by the Gecko engine in the context of the HTML/XHTML embed and object elements, in a compound document situation, and as standalone documents -- not by the HTML/XHTML <img> element or by css properties that accept images.

3.2 Compound Documents

Perhaps one of the most interesting of the possibilities presented by native SVG support is the ability to mix SVG with other XML content in a single mixed namespace/compound document. Mozilla provides support for a number of other XML dialects including XHTML, MathML, XUL and XBL, and a number of Mozilla specific examples combining these dialects with SVG have been published on the Web. Perhaps the most exciting examples are those that combine SVG and XBL to implement an XML dialect not natively supported by Mozilla. For example, the CML (Chemical Markup Language [11]) might be implemented as a series of XBL bindings that utilize SVG objects to render molecules as described by CML.

While the compound document possibilities in Mozilla are of considerable interest, the development work carried out so far has focused mainly on pure SVG content. Mixing SVG with content from other XML namespaces can work, but there are many caveats. In general, SVG content as children of other namespaces works fine, but other namespaces can only be included in SVG content using <foreignObject>. Part of the reason for this is technical; the mozilla SVG implementation uses a different rendering system than other content, so once rendering starts working on SVG it cannot switch easily back to normal Gecko system. The other problem is lack of guidance from the specification about how documents with multiple markup formats (e.g. compound documents with both XHTML and SVG markup) without <foreignObject> should behave.

3.3 Renderers

In its current state Mozilla's native SVG implementation can use three graphics libraries to act as its renderer backend. We can select which library will be used, based on platform and preferences. Cairo and Libart can be used for all tier-1 platforms (Microsoft Windows, Unix, and Macintosh), while GDI+ is a third possibility for Windows.

The two fastest renderers available on the platforms are Libart and GDI+. However, both have distribution issues for Mozilla products caused by their licensing terms. As GDI+ is so much faster than cairo on Windows and Microsoft provides a small GDI+ download for pre-XP versions, we have decided to go with that renderer for the official Windows releases from mozilla.org. [2]

Cairo [8] currently doesn't have the performance required for intensive use, but the authors were kind enough to change the licensing to be compatible with mozilla.org requirements. Antigrain [10] might have been another possibility, but cairo is also already being used for Mozilla's <canvas> implementation and we plan on making more use of it in the future. The cross platform nature of cairo also saved us effort in supporting the Macintosh. There is ongoing work to improve cairo's performance.

3.4 Performance and Code Size

Mozilla's SVG implementation started as a small scale project by a variety of developers not fully familiar with the Gecko layout engine. As such, it doesn't take the best advantage of the Gecko infrastruture and uses some coding patterns that increase the code and memory footprint, and slow the implementation. We will work to address this as the project continues. However, performance is dominated by content loading speed and the speed of the backend renderer.

4. Opportunities and Challenge

4.1 Opportunities

Current standard web presentation technologies such as HTML and CSS are oriented toward structured textual presentation. While talented designers and programmers can produce graphically rich web applications, they are limited to what can be achieved with creative uses of CSS decoration and raster images. The widespread use of the Macromedia/Adobe Flash plugin shows that content developers are interested in providing richer graphics, and the draw of a powerful authoring environment. In addition to the use of plug-ins like Flash, many commercial and scientific sites generate images "on the fly" to present data graphically to users.

Using plugins to provide additional functionality poses problems. The designer is limited to the platforms that the plugin is available for, needs to convince the users to install the plugin, and plugin content appears "in a box" both in visual terms and from the point of view of the DOM. Depending on the plugin in question, your content may be locked into a vendor's proprietary format (Flash being an example of this, as the SWF format license only allows one to write software that exports the format). Additionally, some corporate environments forbid the use of plugins.

Server-side image generation has its own set of challenges. Depending on the desired resolution and features, image generation can be costly in terms of CPU cycles, bandwidth, or time. Like plugins, the graphical objects within the image are not available to the DOM, so image interaction is limited to client-side image maps, which often require round-trips to the server for processing.

With the growing success of Firefox, we feel that including native SVG support could lead to increased SVG content on the Internet targeted toward desktop users. Aside from the obvious artistic uses, SVG combined with other technologies could open up new web applications and user interface possibilities. HTML/CSS + SVG could be useful for graphics and diagramming type applications, and the addition of XForms could create a very capable business application platform. Alternatively the addition of MathML would be well suited to creating a scientific and academic content delivery platform.

SVG can be combined with XUL and XBL to provide developers more possibilities for user interaction, especially once <foreignObject> can handle full transforms (the current implementation only does translations).

4.2 Challenges

There have been very few efforts to implement SVG in a mixed-namespace environment along with HTML and CSS. In the process of implementation, a number of problems have presented themselves, some of which are just undefined areas in the specification and others where it seems that the various standards groups weren't reading each other's specifications with an eye towards compatibility. Some examples of the former are sizing of the outermost <svg> and how foreign elements such as those created by XBL should be handled in the absence of <foreignObject>. Two examples of the incompatibility problem are different interpretations of unit-less CSS numbers, and gratuitously different naming of the event object.

Implementing SVG within the Mozilla framework provided some unique challenges (see Figure 2). The Gecko layout engine has been designed around HTML/CSS and how to optimally render content and process notifications for changes which effect the layout. In HTML/CSS, everything that changes the visual appearance or layout is mapped to the style system, which is responsible for pushing update events, while with SVG most placement is only specified by geometric attributes which are mapped directly to the DOM. An SVG specific notification system was implemented, but we are reevaluating its design as we look towards declarative animation. The existing scheme has the graphical elements ("frames" in Gecko terms) as observers of their attribute values. This duplicates the existing Gecko notification scheme to some degree, and could have probably done without for an SVG implementation for SVG content that does not utilize declarative animation. However, the SVG specification defines the use of animated values for use in declarative animations. An animated value actually has two values associated with it: a base value (baseVal) that is set by the element (or DOM) attribute and an animated value (animVal) that can be set only by the actions of an animation. This separation between the value that is set by the element (or DOM) attribute and the value that is actually used by the code responsible for the layout requires a modification to the existing Gecko notification scheme.

Figure 2: Gecko/SVG Architecture

Full implementation of <foreignObject> has proved difficult both because the Mozilla SVG implementors are not fully familiar with some of the intricacies of Gecko, and because the Gecko layout code currently used for core rendering will have to be refactored before it can handle general transforms.

Early in the implementation of Mozilla SVG, it was rearchitected to support multiple rendering backends, most recently focusing on the cairo backend. While this provides the opportunity to support platform-specific backends to maximize performance, it also requires the backend portions of each feature to be implemented multiple times, often by different programmers. Currently, cairo is being used for both linux and OS-X, with GDI+ being the primary backend for Windows platforms. While cairo provides nice features and portability, its performance remains problematic. There are a number of large projects depending on cairo performance to increase (gtk+ and mozilla itself), so it is hoped these issues will be addressed, though their usage of the library is likely quite different than SVG's.

Although the goal of the Mozilla SVG Project is specification conformance, it has frequently been necessary to seek clarification from the SVG Working Group on ambiguous parts of the SVG specification and issues that it doesn't address. Unfortunately, some requests for clarification have received no response, and of those that have received a response, none have so far become official errata items. As a result it has sometimes been necessary for the developers to make an informed decision when deciding how a certain feature should behave. An undesirable consequence of this is the possibility that content written against Mozilla's native SVG implementation might break if we later change this behavior to conform with errata items as they are created. This seeming lack of interest by the working group in the problems raised by an implementor is disappointing, as such comments would appear to be valuable feedback as to the quality of the specification. For example, one issue that caused concern during our implementation was our confusion over exactly how getCTM() was supposed to behave. An email was sent to the working group on September 9, 2004 asking for clarification. Unfortunately, we never received any response, and were forced to research existing implementations to attempt to be compatible with those.

In addition to conformance to the specification, one of the goals of the Mozilla SVG Project is to create an interoperable implementation that could deal with content currently used with other viewers. Unfortunately this has proven to be difficult as existing viewers are not currently mutually compatible. The test suite offered by the SVG Working Group provides very sparse coverage of the specification and almost no coverage of edge cases. This makes it difficult to rely on the official test suite as an arbiter of the correctness of differing implementations. Furthermore, a number of implementations have chosen to implement portions of SVG 1.2, which is quite premature as the specification is not even in Candidate Recommendation status yet. Others have chosen to implement vendor specific extensions or behaviors, sometimes without clearly labeling or documenting them as such. Such behavior by implementors is damaging to the entire SVG community and should be redirected towards encouraging the W3C SVG working group to improve the specification and dramatically enhancing the SVG test suite to provide decent coverage of the entire specification, including interactions between various elements, attributes, and the DOM.

Although implementation and specification issues cause complications, probably the largest problem facing the Mozilla SVG project is lack of developers. For the majority of its life, the project has been the work of a single developer. We hope the increased visibility of the project will inspire new developers to become involved.

5. Why Release Mozilla SVG Now?

While Mozilla's current implementation of SVG has a number of limitations, as discussed above, we feel now is the appropriate time to turn on SVG support in Firefox. Web graphics needs SVG and <canvas> to move forward. Getting our SVG implementation into the hands of content and extension developers allows them to experiment with the technologies and offer feedback about bugs and features they desire.

It is also hoped that increased exposure will encourage more developers to help with the implementation. The full specification of SVG is much too large for the current pool of developers to fully implement and maintain, particularly in light of the changes to the SVG specification (and related specifications) as well as the ongoing architectural improvements to the Gecko core.

6. Future Directions

6.1 Next Release

Our current implementation can roughly be described as SVG Full 1.1 minus filters, declarative animation, and SVG defined fonts. Full SVG 1.1 is planned for the next major release of Firefox, which is likely to be released in mid to late 2006. Towards that end there is feature work to be done, along with architecture changes for performance and footprint, and bug fixing.

A number of the changes to decrease footprint and increase the performance will be linked to the changes necessary to implement SVG's declarative animation. Currently the content model used by Mozilla matches the SVG IDL exactly. We intend to do away with these heavyweight objects for the base types, and only create their DOM object on demand from the script engine.

Currently Mozilla includes three separate graphics rendering systems, one used for the UI and HTML/CSS, one for the <canvas> immediate mode surface, and one for SVG. On some platforms all three are actually implemented with different libraries. One of the major goals of the next version of Firefox is to simplify this from a programmers point of view by providing a unified graphics layer that all rendering will go through. The basis of this will be the cairo rendering library. This was chosen due to the large open source community interest in the library and its plans for hardware acceleration. Using a single graphics library for all platforms will eliminate the current need to reproduce graphics layer changes in all the mozilla platform gfx layers. With a unified graphics system, freeform compound documents with SVG and fully transformable <foreignObject> become possible.

6.2 SVG 1.2

The Mozilla SVG developers have been following the development of the SVG 1.2 specification with some trepidation. From our point of view it seems that the specification is being pulled in two directions - towards the creation of an all-inclusive environment for mobile applications, and features to placate the niche market developers (such as Graphical Information Systems) and graphical tools. We realize we're just one constituent user of the specification, but would like to see something more along the lines of CSS 2 to 2.1 - more focus on clarification, removing unused/unimplemented features, and improving the test suite to aid in interoperability - before the addition of major new features and functionality to support additional communities and their use cases.

There are comments regarding the future of SVG that we find disturbing. First, there is the idea that HTML/CSS should be abandoned for a "web 2.0" of SVG+XForms. While such a technology choice might be of interest to the mobile platform, browsers need to deal with the existing web, and we do not believe it is going to just go away.

Another problematic comment is "Don't worry about feature X, we'll deprecate it in 1.3". Deprecation does nothing to help implementors, as they still need to implement deprecated features. We would rather have the working group carefully consider what is to be added to 1.2 so that things don't need to be immediately depreciated.

There is also concern that the SVG working group is pushing the 1.2 specification through the W3C process when it is far from ready. Feedback on the last call drafts has been extensive and indicated a great need for clarification, internal consistency, cleaning up the draft, and addressing issues that have been uncovered in the process of implementing the 1.1 specification. The working group has also prematurely frozen parts of the 1.2 mobile specification by letting JSR226 publish parts of the specification as final. Despite the feedback, the working group seems intent on pushing for Candidate Recommendation status of the next draft, with the added misstep of not specifying appropriate exit criteria for that stage.

7. Getting Involved

Support for SVG within Mozilla has come a long ways and is entering an important phase of development. A great deal of work remains before the release of the 1.8 version of the Gecko core and the associated Firefox 1.1 release. The team working on Mozilla SVG remains limited, and we can use help on many different levels. If you are a software developer, there are many bugs and missing features that require attention. Some of these are excellent "starter projects" for a developer interested in getting involved. Companies who are currently implementing SVG in an application, or delivering SVG-based content have a vested interest in seeing SVG supported as broadly as possible. One way to help broaden SVG's support would be to dedicate development resources to the Mozilla SVG implementation. Mozilla SVG would not be where it is today without the commitment of Crocodile Clips of just a single developer, and the "third generation" discussed above was ignited to a large extent by the dedication of resources by IBM to the Mozilla SVG project. These have had an important and multiplicative effect on the overall effort.

If you are not a developer, or are a company that does not have sufficient development resources to devote to a project like Mozilla SVG, there are still opportunities for you to contribute. One of the ongoing difficulties with a specification as large as SVG is to get a sufficient breadth of test cases to ensure that the implementation behaves in a consistent, standards-compliant manner. Testing Mozilla SVG against your test cases, filing bugs when the implementation does not behave in a consistent, standards-compliant manner (or voting on the bug if its already filed), and providing access to the test cases that the Mozilla SVG team can use to test against can be of invaluable assistance to the overall effort.

Finally, if you are an end user interested in Mozilla, Firefox, and SVG, you can download nightly releases and test by simply using them and filing bugs on problems encountered. Alternatively, you could participate in a "bugathon", when Mozilla volunteers get together online for mass triaging of bugs.

More information about the status of the Mozilla SVG project and the ongoing needs can be found on the SVG project page at mozilla.org, on the Mozilla SVG developer's channel at irc://irc.mozilla.org/#svg, and on the Mozilla SVG newsgroup: netscape.public.mozilla.svg.

8. Conclusion

This paper has presented some of the history involved with the implementation of SVG in the Mozilla family of products. It has also discussed some of the architectural and political challenges associated with including the SVG specification into an existing browser infrastructure optimized for today's web content which is dominated by HTML marking with CSS styling. Firefox 1.1 will include support for XHTML, MathML, XBL, SVG, and <canvas>, providing a platform to view and interact with graphically and semantically rich web content for millions of end users. We believe that the SVG implementation in Firefox 1.1 will also provide and important development target for those graphically rich content and applications, and we are excited about the future directions for the Mozilla applications and their use of SVG.

Bibliography

[1]

Crocodile Clips

[2]

Crocodile Mathematics

[3]

XML User Interface Language (XUL) 1.0 Hyatt et. al.

[4]

XBL - Extensible Binding Language 1.0 mozilla.org

[5]

Libart

[6]

Bug 249263: Make W3C specify "liveness" of SVGTransform.matrix (example)

[7]

www.spreadfirefox.com May 30, 2005

[8]

CairoGraphics

[9]

BrowserNews Upsdell May 28, 2005

[10]

Anti-Grain Geometry The Antigrain Project

[11]

The Chemical Markup Language (CML)

[12]

Scalable Vector Graphics (SVG) 1.1 Specification World Wide Web Consortium

[13]

Extensible Markup Language (XML) 1.0 (Third Edition) World Wide Web Consortium

Footnotes

1. At the time of writing this, inclusion of even this limited <foreignObject> in the Firefox 1.1 release is under debate.

2. At the time of writing this decision was being reconsidered, as switching to cairo would give behavior consistency between platforms, fix some hard problems with GDI+, give more features (like <textPath>), and minimize support problems.

XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.