Firefox 2 continues to make progress toward a broader implementation of Scalable Vector Graphics (SVG) functionality. The only new feature added above the support in Firefox 1.5 is <textPath>, though a number of specification and bug fixes have also been encorporated -- see below.
Firefox SVG is a subset of SVG 1.1, but not any of the official profiles (Tiny, Basic, Full). A full list of the elements and whether they've been implemented for Firefox 2 can be found at the end of this document. The rest of this document attempts to provide you with information about our implementation's limitations.
We realize that the pecularities of our implementation can be bothersome when developing content, but we ask for your forbearing as we work towards a full implementation of this large specification.
Reading through this document, you might be wondering when these implementation details might change. Unfortunately the current roadmap puts the public release of Firefox based on the next version of Gecko a fair ways into the future, in the first quarter of 2007. However if you want to start experimenting with the new functionality, nightly builds of the current development are available.
All platforms that Firefox ships for use the same rendering backend, cairo, so their performance characteristics will generally be similar. Performance on Linux is the hardest to predict, as it will vary due to various X servers' implementation of the RENDER extension.
SVG rendering in Windows is considerably faster than on other platforms.
If your content has geometry with a large coordinate range, you need to watch out for problems caused by cairo's internal use of a 16.16 bit fixed point representation for calculations. Cairo doesn't clip primitives before rasterization, so final coordinates after transformation that exceed the range -32678 to 32677 will cause rendering errors and possibly very slow performance.
Text on Windows 98
An unfortunate side effect of using cairo as the rendering backend on Windows is that text rendering does not work on Windows 98 machines. In fact, it's even more serious than that: once any text is encountered during rendering of SVG content, all further drawing will stop.
If you're familiar with CSS you probably know that it allows you to specify fallback fonts for the font properties in case glyphs are unavailable in particular font. The current SVG rendering backend will only try using the first font specified, and if it doesn't exist will use a platform font. The fallback fonts are never used; so, for
font-family="Arial,LucidaSansUnicode" won't result in LucidaSansUnicode being used if Arial is not available.
Currently printing is unfortunately not done using the vector properties of SVG to generate extremely crisp output, but instead rendered at screen resolution and then output as an image.
Font sizes when printing on Windows will be much larger than specified for SVG.
The group opacity property
opacityallows SVG container objects to be treated as a partially transparent layer, and is separate from the
stroke-opacity properties. The current implementation of
opacity is fairly expensive, so should be used sparingly.
stroke-opacity are much faster, and depending on your content can yield the same results.
Group opacity is currently only implemented for
<g> and not for
On the Microsoft Windows and Mac OSX platforms, the stroke of the text doesn't exactly match the fill. The error is typically quite small, and can be covered by using a slightly thicker stroke. An example of this difference:
<image> does not support SVG images in Firefox 1.5; instead, it only the raster image formats handled by Firefox.
All instances of
<image> have a separate copy of the image being used, which is something to keep in mind if your content is using multiple copies of an image for an icon or such. Unfortunately
<image> content counts as another copy in this case.
Additionally, heavy use of raster images in SVG can badly degrade performance in Firefox 1.5.
We support the SVG event attributes with the exception of
onload handling is currently somewhat nonstandard, but hopefully not in a way that hurts its use. While the code specified by the
onload attribute is called for each element, an
SVGLoad event is only fired for the root
<svg> element. Some DOM methods will return garbage or an error if called before the corresponding element has been rendered, which you may need to take into account when writing
onload code. Such methods are
We do not support the Adobe specific key events (
If you're working with current SVG content, you may encounter problems loading it into Firefox. Most of the problems tend to be fairly trivial, and are the result of Firefox being a stricter implementation. Jonathan Watt's SVG Authoring Guidelines explains the common problems.
SVG usage situations
Firefox 1.5 handles SVG as entire documents or when referenced by
iframe. It cannot currently be used as source for an HTML or XHTML
img element or for CSS properties that take an image reference.
Bugs fixed in Firefox 2
Firefox 2 fixes some bugs in its SVG implementation. This section provides a quick overview of the most interesting ones.
- A problem filling and stroking text in which the drawing position isn't reset correctly between the two operations has been fixed (bug 333615).
- Radial gradients now properly clamp the
fyattributes to ensure that they're within the circumference of a circle (bug 330682).
- Text spans' and text elements' lengths can now be computed using their
getComputedTextLength()methods, which improves compatibility with certain web sites (bugs 311031 and 264380).
<tspan>elements now properly support the
dyattributes, and work if the
yattributes aren't specified (bug 311063).
- Improved invalidation logic on redraws, which prevents dropped pixels in certain cases (bug 312269).
- Fixed a bug that prevented events from being handled properly for objects exposed by the clip path of another object (bug 315861).
- Fixed a bug that would crash if a
<path>element had a
dattribute with an empty string (bug 318379).
overflowattribute now works for the
markerelement, using the syntax
overflow="visible", which did not previously work correctly (bug 320623).
- You can now access the
markerelements without throwing an exception (bug 323589).
- You can now use percent values for the radius of a radial gradient (bug 323669).
documentElement.createSVGAngle()method is now implemented (bug 327437).
- Making a
<stop>element a child of another
<stop>element no longer asserts (bug 328137).
- Changes to the height and width of markers, as well as to the orientation of the marker, now work (bug 325728).
Element implementation status
|Conditional Processing Module|
|Color Profile Module|