Now that Firefox 1.5 has been released, I thought I would follow up this entry with my corresponding entry for Firefox. I decided to limit my scope of items to things that Firefox claims it supports on their status page (even if they have acknowledged certain caveats).

In no particular order they are:

1) Support svg:a target attribute. See Bug 300868.

2) Support text selection. See Bug 292498.

3) Local SVG files (not online documents) sometimes fail to load up in Firefox. See Bug 303581.

4) Support SVG documents as targets in svg:image. See Bug 272288. This is particularly frustrating as the only other way to do this is by using XMLHttpRequest and then inserting the SVG document into the DOM.

5) Allow the use of CSS background-image to include SVG into an HTML page. This would be great for rounded corners in HTML <div>s. See Bug 231179.

6) Gradients in text don’t work very well. See Bug 303584.

7) <use> elements should be allowed to reference external documents. See Bug 269482.

8) <svg> width and height should be overridden when embedded. See Bug 288276. Ironically up until I learned of this bug via this page, I thought Mozilla’s behavior was correct and that SVG authors should just use width=”100%” height=”100%” and an appropriate viewBox attribute. Now I know better – but I still prefer Mozilla’s approach 😉

9) SVG should respect xml:space=”preserve”. See Bug 319786.

10) Improved speed and performance. Currently the Mozilla SVG implementation is pretty slow and memory-heavy (especially when compared to Adobe). For instance, I was using the DOM methods to add and remove elements repeatedly in my SVG Tetris Clone and it was causing the memory used by Firefox to increment without bound (I eventually changed my implementation to a more sensible approach – I have yet to investigate this and write a bug against Mozilla).

Well that’s about it. Of course there are many pieces of the SVG 1.1 spec that still need to be implemented, but I put my vote firmly in the camp of those people who think Mozilla did a good thing by releasing this implementation in partial state so people can start playing with it at larger levels than perhaps a browser plugin could reach. Combine this with Opera’s and Safari’s efforts and the picture for SVG looks a little less bleak lately.

§187 · December 13, 2005 · Firefox, Software, SVG, Technology, Web · · [Print]

2 Comments to “Top 10 Things To Fix for Firefox’s SVG Implementation”

  1. Jim Plush says:

    Nice list, I’m currently trying to get SVG running on Moz and noticing some glaring differences in the Adobe plugin rendering and the Moz rendering. You mentioned your perfomance tweak. What did you have to tweak to fix the DOM scripting performance in Moz?
    thanks again

  2. Jeff Schiller says:

    Oh, I was doing something rather silly that I hesitate to even mention out of sheer embarassment.

    Every time a Tetris block fell, I was removing it from the DOM (removeChild) and adding it to a new cell in the grid (appendChild). This was horribly inefficient and seemed to trigger some Moz memory leak after some time (though I couldn’t consistently reproduce it).