Deer Park Alpha Test Suite Results

I'd planned to put together a big table of all my test results from Firefox, and I have that. Just it's in a spreadsheet, not a web page. If anyone really wants to see that, just ask and I'll send it along. I've decided that I'd rather summarize my findings here. I think that's a lot more useful than just another table of red and green - especially since that would imply something far more official than I intend to. So today I'll talk a little about my subjective results of looking at all the tests in the SVG test suite with Firefox Deer Park Alpha 1.1. I looked at features that should be supported according to the Mozilla SVG status page and features that are clearly documented as not supported.

Why bother looking at unsupported features? Failure mode analysis. It's one thing to say that a feature is not supported and it's another to know what will happen when that feature is requested anyways. I know this is bound to change before the final release of 1.1, but alpha builds are for testing, right?

Anyhow, the test suite prefixes and the modules described in the Mozilla SVG implementation status page don't clearly line up all the time, so I just made my best guess at where each test fits in terms of the primary features being tested and what Mozilla supports. The ones that should be supported are the ones I'll talk about first (and file bugs if it makes sense), the ones that shouldn't be supported I'll give some attention to another day if it's warranted.

Before going on, let me repeat that this is just my personal observation as an amateur SVG enthusiast. My point of view is, and has been, what I think is best from the perspective of an SVG developer. The fact that Firefox is my browser of choice is beside the point.

What Works Well

About half of the tests passed that test features supported by Firefox:

Mozilla Module (my guess)Test
conditional processingstruct-cond-01-t
conditional processingstruct-cond-02-t

What Works

These ones worked, but didn't render custom glyphs correctly. I felt that was outside the scope of these tests, so I still call that a pass:

Mozilla Module (my guess)Test

The hyperlinking test (linking-a-04-t) sort of worked. The test on the page worked but I'm not sure of the tests that were linked to.

One of the positioning tests - coords-units-02-b seems to work correctly, even though the reference PNG looks a little different. Actually, I think the PNG was probably generated with the wrong Z-ordering. The circles on the bottom should be drawn first, then the lines on top. This is how Deer Park Alpha 1.1 does it. The same SVG image is rendered by ASV6 to look exactly the same as the PNG.

In struct-defs-01-t, Deer Park Alpha 1.1 shows an error in the Javascript console that indicates an error in the colour value of one of the elements that's not to be rendered. That's great, but it also means the test is not valid. I fixed the value in a local copy of the test SVG file and Deer Park still passes.

What Doesn't Work So Well

So that's it for the good news. Most of the failures of features that look like they should be supported are due to incomplete text support, lack of SVG support from the img and svg:image tags in HTML and CSS and hyperlinking issues. Oh yeah, and Deer Park won't run script that's tagged as text/ecmascript.

The text module isn't marked as being completely supported on the status page, so some of the tests are expected to fail. I think the issues that I've seen in Deer Park with implemented text support have been filed as bugs. Specifically Jeff filed 292498 about text selection. It could be a couple of things, but it's documented. The text module seems to be coming along, from what I've been reading. It's something I'd really like to see it complete and worked out for the first release of SVG on Firefox. Selecting text along a path is a cool feature, something people can show off. It might have some practical use somewhere too, I suppose.

As far as rendering SVG for HTML img tags and SVG image tags, there are bugs open on these two issues. They also discuss referencing SVG in place of a raster image in a CSS stylesheet. Read about it in bug 272288 and bug 276431. The specification clearly says that you should be able to reference SVG with an img tag as well as CSS, and it also says that the SVG image element has to support JPG, PNG and SVG images as a minimum. That sounds simple at first read, but I imagine it gets rather complex to implement once you consider the dynamic nature of SVG. Other background images don't have the potential to execute scripts. The specification says that there's no access between the DOM of the SVG used as an image and the DOM of the referring SVG document (at least that's how I read it).

The hyperlinking tests that require zooming or viewBox scaling don't seem to work quite right. I don't have the energy to investigate it tonight, but the tests that don't look right are

Mozilla Module (my guess)Test

As for the other major source of incompatibility with the test suite, text/ecmascript is not accepted by Mozilla apparently. Chris Lilley helpfully pointed this out in a comment the other day, and Jeff gave me a reference to read up on it. Let me just say I think the whole situation is stupid. It's a stupid problem for someone to have when they're making a web site. Note that I'm not saying anything about one side or the other of the issue, just that the problem itself is something that shouldn't happen. It's one of those ones that wastes your day after you think you've got everything figured out. It's the kind of problem that frustrates beginners and makes them give up. I understand the significance of the issue, and many very intelligent people have been hung up on both sides of problems like this in the past. I'm glad I don't have any say in this one, because I don't see a right answer. I'm staying intentionally vague here because I don't want to imply that I think I know more than the people that are doing the real work here. I just want to reiterate the feelings of developers and the end users.

It sounds like at least there's a workaround: just don't specify a type attribute for your scripts. Let the renderer guess. I haven't tried it out on the tests in the suite yet, but I might get around to it eventually.

A Couple of To Do's

I tried to do my part to help out the Mozilla people with making SVG work better by reporting a few bugs. I checked out Bugzilla first and didn't see them yet, so my first three bugs are 298281, 298282, and 298283. Those were failures that I was pretty confident are problems in Firefox Deer Park Alpha 1.1. Oh, and for anyone else who decides to get in on the Alpha testing, bugs for SVG go under Core:SVG, not Firefox:General (where I originally put mine).

Your rating: None Average: 2.8 (10 votes)

Hi Rob
thanks for your efforts in testing Firefox !
the "text/ecmascript" issue should be fixed in the latest builds, see
anyways, this is a really interresting article, it would be nice to have the complete test result available online,
and updated regularly, so i can link to it. if it is to much work for you, and you send me your result spreadsheet,
i could publish it on my site, and care about the updating.
all the best

Hi Holger,
I'm glad to hear the issue is going to be resolved.
As for my complete results, I should be able to put them up here early next week. I didn't know anyone would want to read the tables. I don't know that I'll be able to keep them up-to-date, but if I get out-of-date then I've no objection to passing my info on to someone who can.

Did a search for a way to publish an interactive spreadsheet on the web. Came upon your site. I need a way for our Firefox friends to use an interactive spreadsheet. Of course excel doesn't show up in netscape or firefox. Any suggestions. I found it interesting that your data was "just in a spreadsheet" not in a web page. What spreadsheet software are you using?

Hi Kbits, all I did was do a spreadsheet in Excel then monkey around to make it into html for a table (I don't just do a 'save as html' because that leaves too much cruft for me). So it's not interactive.
When you do put an Excel object into a web page, you're using ActiveX. Since ActiveX is Windows-only (and not cross-platform), it's not available in Firefox (or anything but Internet Explorer, afaik). You could just tell your users to save the spreadsheet and open it in Excel, OpenOffice or StarOffice. If you want to go into more detail about how to get your problem solved without Excel, you could try asking in a forum like the ones on my site.