transform-origin for SVG elements

Firefox has supported transform-origin on html elements since version 16 (even earlier if you count -moz-transform-origin), but it’s been a bit hit and miss using it on SVG elements.

Percentage units on SVG elements did not work at all, neither did center of course since that’s just an alias for 50%.

Fortunately that’s all about to change. Firefox 41 and 42 have a new pref svg.transform-origin.enabled that you can use to enable transform-origin support for SVG elements. Even better, Firefox 43 will not require a pref at all, it will support transform-origin straight out of the box.

New SVG/CSS Filter support in Firefox

There’s a new specification for filters that replaces the filters module in SVG 1.1. Firefox and Chrome are both implementing new features from this specification.

Firefox 30 was the first version to support feDropShadow As well as being simpler to write, feDropShadow will be faster than the equivalent individual filters as it skips some unnecessary colour conversions that we’d otherwise perform.

Firefox 35 has support for all CSS Filters so for simple cases you no longer need any SVG markup to create a filter. We’ve examples on MDN showing how to use CSS filters.

We’ve also implemented filter chaining, this is we support multiple filter either via URLs or CSS filters on a single element.

As with earlier versions of Firefox you can apply SVG and CSS filters to both SVG and HTML elements.

As part of the rewrite to support SVG filters we’ve improved their performance by using D2D on Windows to render them thus taking advantage of any hardware acceleration possibilities on that platform and on other platforms using SIMD and SSE2 to accelerate rendering so you can now use more filters without slowing your site down.

Restrictions on SVG used as an image

SVG images are uncommon compared to png, gif and jpeg so when we implemented support for them we wanted to keep to the mental model that people have for raster images.

If SVG images work just like raster images then websites that support raster image upload can allow SVG images to be uploaded too without having to worry about implementing additional security or privacy checks.

So let’s see what we expect from raster images:

  • Comprise a single file
  • Are not interactive i.e. for example they can’t react to you moving the mouse over them
  • Should display pretty much the same independent of the operating system you’re running
  • Cannot change to display something else depending on the time they are viewed
  • Behave like a raster image to the containing document i.e. they don’t have a DOM
  • Cannot have areas that work as hyperlinks
  • Will not render differently depending on whether particular sites have been visited
  • Cannot send or receive data
  • But they can be animated

If we omitted one of these restrictions, allowing hyperlinks to be displayed in visited colours for example, copying the image to canvas via drawImage would then allow a web page to determine whether another site had been visited by the user unless we made the canvas write-only. As we don’t make the canvas write-only when a raster image is copied to it, we don’t want to make it write-only when an SVG image is copied to it either.

So if you’re going to use SVG as a background-image, border-image or via a html <img> or SVG <image> element and your image needs to do something that a raster image could not do then it’s unlikely that will work for you. Having the image on the same domain as the host document won’t make any difference.

Some workarounds for common problems:

  • If you want to use a stylesheet, you can encode the stylesheet contents as a data URI in the image file
  • If you want your SVG image to contain other images then you can encode the embedded images as data URIs
  • While hyperlinks in images are disabled, you can make the whole image a hyperlink by wrapping a hyperlink tag round the image element itself in the container document
  • If you need anything that images don’t offer then perhaps you should be considering putting the SVG inline in the document or using an <iframe> or <object> tag instead

New SVG filter pseudo inputs for Firefox 17

Firefox has supported all SVG 1.1 filter primitives since Firefox 3, however until now it has only supported SourceGraphic and SourceAlpha pseudo inputs. Fortunately these are by far the most common.

Firefox 17 includes support for an additional two pseudo inputs – FillPaint and StrokePaint. The SVG testsuite has an example showing how they can be used.

Even though HTML doesn’t use the SVG fill and stroke CSS properties, you can still set them in Firefox to have StrokePaint and FillPaint filters with HTML.

SVG Fragment Identifiers

An SVG feature appearing for the first time in Firefox 15 is support for SVG Fragment Identifier linking. This feature allows authors to display different parts of an SVG image by specifying a different fragment identifier on the end of the URL.

The Firefox 15 implementation also includes support for the view element which is basically a predefined fragment identifier. It does not however, support XPointer style fragment identifiers.

One use case for fragment identifers could be an SVG document with a set of sprites arranged in a grid. Fragment identifiers could then be used to display one or more of those images on another html or svg page.

Here’s an example that shows Fragment Identifier Linking in action

Hyperlinking semantics for SVG animation

One of several new SVG capabilities in Firefox 15 is support for triggering animations by clicking on hyperlinks.

If a link target is an animation element then the animation will begin when the user clicks on the link such as in this example.

This completes SVG 1.1 animation support in Firefox, apart from the deprecated animateColor element and wallclock timing, both of which are likely to be removed in SVG 2.0. Therefore from Firefox 15 we’re also enabling the feature string.

SVGTests interface implemented

Support for the SVGTests interface has just landed in Firefox. It’s currently available in Nightlies and all being well, should make its release appearance in Firefox 12.

The SVGTests interface allows scripts to check whether additional functionality is supported by a browser. There’s no strict definition of what extensions mean but Firefox currently uses element.hasExtension(“;) to suggest that foreignObject elements support html content and element.hasExtension(“;) to suggest they also display mathML.

The SVGTests interface also allows the requiredFeatures, requiredExtensions and systemLanguage attributes to be manipulated as if they were arrays using the SVG DOM.


Get every new post delivered to your Inbox.