According to the original SVG 1.1 specification masks in SVG always operated in the linear RGB colour space. That meant that Firefox always converted the graphic being masked to linear RGB and after that, applied the mask.
SVG 1.1 2nd edition changes the way masks work and a patch has landed for Firefox 10 to match that change. SVG masks now honour the color-interpolation property. This means that authors can choose whether the graphic is converted to linear RGB before the mask is applied.
The thing to watch out for though is that the default value for color-interpolation is sRGB so existing content may render slightly differently. If you want things to stay the same you need to add color-interpolation=”linearRGB” as an attribute of the mask element.
Opera has worked like this for some time now and a patch make this change also landed in Webkit recently so Chrome and Safari will render things this way at some point too.
In versions of Firefox prior to 4.0 there was an svg.enabled flag that you could set to false in about:config to disable Firefox’s SVG capability.
During the development of Firefox 4, UI changes took more and more advantage of SVG; for buttons for instance you can ship with fewer bitmaps – one scalable drawing can replace all the bitmaps for different screen resolutions and using SVG filters you can even derive the greyscale disabled state from the enabled button.
Eventually we discovered that the Firefox 4 UI had become so internally dependent on SVG that it would not start any more when you set svg.enabled to false so we removed the
flagfootgun. SVG is now a first class citizen just like html.
One consequence of this is that if you were using an SVG plugin such as the Adobe or Corel SVG viewers these will no longer function. To ease the pain, we have implemented more of the SVG specification in Firefox 4 than ever before and as you can see we’re up to a similar score to the Adobe plugin. There are still some things that the Adobe plugin does that Firefox does not, such as SVG fonts there are now things that Firefox does or does correctly that may in some way make up for that.
Daniel Holbert wrote a while ago in svg-as-image that you can use SVG in many new places in Firefox 4. Did you realise that that means that you can use SVG for cursors too?
For an SVG cursor it’s as simple as:
cursor: url(cursor1.svg) , auto;
Browsers that don’t understand SVG cursors should fall back to the non-URL value.
One caveat is that the SVG image must contain a length-valued (not percentage-valued) height and width on its root SVG node. The usual SVG as an image restrictions apply but animation will work so spectacular things should be possible.
For more information see the newly updated MDN article: Using_URL_values_for_the_cursor_property
In my previous post (SVG Glyph Positioning) I said that we now do individual glyph positioning for SVG text but that there were some gotchas.
Fortunately Takeshi Kurosawa stepped up to the plate and fixed inheritance of glyph positions so that <text x=”10 30″ y=”30″><tspan>HI</tspan></text> now displays correctly. His work on this will be in Beta 7.
We’ve made more animation progress too. Animated slideshows anyone?
- Event based animation by Brian Birtles allows animation to react to mouse clicks: Eventbase targets
- Then we have string animation which would allow the animation to change the slideshow image to move to the next slide.
- At the moment the slides would need to be based around SVG use elements however the ability to have slides as SVG images where each slide is an SVG document is not far off thanks to Daniel Holbert.
I think eventbase animation was early enough to be in Beta 6, String animation will be in Beta 8 and so should SVG images in the SVG image tag.
Meanwhile Jonathan Watt has been keeping his head down implementing a rather complicated patch for animation of path segments. Once that lands only lists of numbers e.g. text glyph rotation and polygon and polyline points will be left. Pretty much anything else should animate barring the odd and hopefully minor rough edge of course.
The Firefox trunk now has the ability to position individual text glyphs in SVG. That means that full-text-text-07-t.html mostly works, barring some glyph rotation issues on some platforms. If you see the glyphs unrotated on your platform, select the SVG frame and view it in its own tab which will force a different font size to be used.
Ken Stacey originally worked on this and almost had it in the tree at the end of 2007 so it’s been a long last 5 yards for this feature.
If you are trying to position individual glyphs you still need to ensure that the glyph positions are defined directly against the text or tspan element they are to affect as inheritance of glyph position data is still to be implemented.
For example <text><tspan x=”10 30″ y=”30″>HI</tspan></text> is fine whereas <text x=”10 30″ y=”30″><tspan>HI</tspan></text> doesn’t work yet.
Microsoft announced that IE9 will support a subset of SVG. They’ve even done a video about it: IE9 SVG Video
The IE9 developer preview already manages to pass just over 28% of the SVG test suite according to codedread’s SVG support table
So congratulations are in order for joining in and getting going. There’s more to come to according to this as markers, clipping and masking are all things to look forward to.
Last weekend, I landed a couple of fixes to improve the integration of SVG with existing Gecko functionality. (To be exact, Takeshi Kurosawa and I fixed bug 329212 and bug 374216) These improvements are both available in nightly builds.
In particular, we now support setting SVG element.style.property values e.g. element.style.fill=”green”. This feature was sufficiently popular that Google’s SVG Web project took the time to patch Firefox to implement this whenever it was loaded. It’s possible that this change may cause some pages written to target Microsoft Explorer filter implementation to display strangely since a test like if (element.style.filter) will now pass in both IE and Gecko. If you have such tests you may need to update them to ensure that they really do only catch IE.
We also display tooltips in SVG now by converting <title> elements into tooltip text so you won’t need to roll your own tooltips in future.