I just got my dinner: a slice of raspberry-lemon loaf and a "grande no bovine-growth-hormone mocha" (the barrista's words, not mine). I'm settling down to try and deal with the fact that I'd better get to work on my next little project.

Maybe it's motivated by guilt from my persisent preference for the Adobe SVG viewer, but I decided to take the new Firefox Deer Park Alpha 1.1 through the W3C SVG test suite and see how it does. That way I can do what you're supposed to do with Alpha builds: find bugs and report them.

I actually finished the testing yesterday, and included ASV on Deer Park in my tests. It's a plugin and as far as I understand it should work on the new Firefox as it did on the old one, permitting that svg.enabled is false. Now I'm on to compiling the results and my notes to make something that's actually legible. I intend to post to Bugzilla as well, so don't think I'm just some kind of whiner. Some people thought I was too critical of Firefox because it's an alpha build. Just wait - you'll see I can complain about most anything ;-) .
While I'm at it, Jeff has started testing Opera 8.01 against the SVG Tiny test suite. Maybe when he and I are both done we can put together something informative, although not guaranteed by any means to be accurate or impartial.

Testing the Tests
For right now, I'll begin by giving an overview of the test suite and my impressions of some of the tests. You can have a look at the ones that I'm pointing out here to get a flavour for what the tests entail if that sort of thing excites you. Later on I'll figure out how to present the rest of my results (hint: it's probably going to involve a table).

First off, there are two test harnesses, one built in HTML and one built in SVG. Trying to view the SVG test harness with DP gives an error message stating "XML Parsing Error: prefix not bound to a namespace." Deer Park is right, inspecting the source shows this:

But the line should be something like

As Jonathan Watt points out in his SVG authouring advice, svg should be the default namespace. I guess that you could still bind 'svg' (or something else) as the default namespace, but that would require you to prefix all your SVG elements, as in <svg:rect ...> instead of just <rect ...>. Anyhow, the document used for the SVG-based test harness doesn't bind a default namespace and as far as I know, it should. It relies on the viewer knowing that the document is SVG and choosing the namespace (a mistake I know about because I've done it too). That's why it can be rendered with Adobe SVG Viewer. ASV guesses what the document is and Mozilla doesn't.

extend-namespace-01-f
This is an interesting test. The way it works (at least in ASV) is that some XML data is embedded in the SVG document in a namespace called 'bd'. The bd data is used to create a pie chart with some Javascript elsewhere in the SVG document. This is particularly intersesting to me since I've been working on an SVG game storing the level data in another XML namespace. I think the reason that Deer Park fails the test is that it doesn't recognize the declaration of the onLoad Javascript function. If it were reworked to move the Javascript elsewhere I think Deer Park might pass.

filters-blend-01-b
I was turned on to the data url and the Data URL Kitchen a couple weeks ago by Dive Into Greasemonkey. Basically, it's a way to embed a small graphic or other resource specified as a MIME-type and base64-encoded data in the actual URL specifier.

This test uses a data: url which is apparently supported by ASV. I checked it with Internet Explorer and ASV and the results look the same as in Fx+ASV. I also verified that IE won't render the data URL used in the SVG document and Firefox does. It's a pretty cool idea, I thought, and this could be a backdoor to use the data URL scheme in Internet Explorer even for those who are only peripherally interested in SVG.

I wonder if you could encode an SVG document into a data URL and hand that to Deer Park. Lots of permutations there...
filters-turb-01-f
I'm not choosing tests that Deer Park fails on purpose, honest. If you can view the graphic, I noted that the reference PNG looks identical to what Adobe renders. I take that to mean that although the noise appears random at first glance, it's actually predictable. Not that important, just an observation.

masking-path-01-b
I think this is an error in the code of the test; the text below the test states that "The group has a clipping path defined using two slightly overlapping circles. Of concern is the overlapping area of the circle. There should not be holes in this overlapping area." Reading the source, the clip path is actually defined by two rectangles:

metadata-example-01-b
Nice choice for the RDF. You'll have to read it to find out who she is.

pservers-grad-05-b
Deer Park doesn't render the same as the reference PNG, but the SVG source doesn't do exactly what the description says. The way I read it, the stop opacities are not what they are described as. I think the stop-opacity of 0 on the second stop may throw off Firefox, but I'm not sure what the correct behaviour is since the test description says the second stop opacity should be 0.2, not 0. I wonder if the reference PNG matches the SVG or the test description.

That's it for tonight. I had to come home to finish this up - too many screaming kids at Starbuck's tonight. With any luck I'll put the rest of my results in some meaningful order soon and maybe some SVG developers and Firefox developers can get some use out of them.