ed.blog

This is a response to "Mythbusting: Why Firefox 4 won’t score 100 on Acid3".

To get the facts straight, let's start with some history.

Acid3 is a test released in 2008 that tests EcmaScript and a number of different W3C Recommendations. The test as a whole is heavily focused on DOM functionality, and gives the tested browser a score from 0 to 100 based on how many subtests were passed. Having 100/100 is not enough by itself to pass the test; the rendering must also look exactly like the reference page.

Ian Hickson compiled the first 84 tests, and announced a competition to fill the 16 remaining subtest slots, open to anyone that had a test that fulfilled the conditions (quoted with emphasis added in red below):

1. The test must consist of the body of a JavaScript function which returns 5 when the test passes, and which throws an exception otherwise. It doesn't matter what kind of exception.
2. The test must compile with no syntax errors in Firefox 2, IE 7, Opera 9.25, and Safari 3. (You can use eval() to test things that are related to syntax errors, though.)
3. The test must not crash any of Firefox 2, IE 7, Opera 9.25, and Safari 3.
4. The test must fail (throw an exception) in either a Firefox trunk build from January 2008 or a Webkit trunk build from January 2008 (or, ideally, both). (Opera and IE are failing plenty of tests already, I don't want to add more tests that only fail in one of those. Of course if you find something that fails in Firefox or Webkit and Opera or IE, so much the better.)
5. The behaviour expected by the test must be justifiable using only standards that were in the Candidate Recommendation stage or better in 2004. This includes JavaScript (ECMAScript 3), many W3C specs, RFCs, etc.
6. You must be willing to put your test into the public domain. (I don't want us to end up with any copyright problems later!)

Several people of various affiliation (myself included) contributed tests during the week the competition was open.

Now, every once in a while (usually around major version release time), various companies and individuals complain about having to fix bugs and/or implement web standards to pass the test.

Opera and Webkit implemented (very brokenly, in at least Opera’s case) a small subset of SVG 1.1 Fonts; basically just enough to pass Acid3.

Opera 8 was the first version of Opera that shipped with native SVG support back in 2005. A full version history is also online these days thanks to Frank M. Palinkas. Opera 8 had support for much the same subset of SVG Fonts we support in Opera 11 today. True, we did have to revisit the fonts code several times after Opera 8, to fix it to properly deal with unicode surrogate pairs for example and a slew of other bugs unrelated to Acid3 (remember, this was before Opera even passed Acid2). Granted, we did add support for the SVG <altGlyph> element because that was a required part of subtest 79 (created by Cameron McCormack) in Acid3. That was something that we simply hadn't prioritized, much like many of the other (uncontroversial) things tested by Acid3. As far as the "very brokenly implemented" remark goes, feel free to submit bugs to the Opera bugtracker.

At this point, the SVG working group has decided that SVG Fonts will no longer be a core part of SVG but will be a separate specification, and that it might need some serious work if anyone is ever to implement it in full.

It's correct that the SVG WG has been asked to split out the SVG Fonts chapter to a separate specification. This is most likely going to happen as part of the work on SVG 2.0 (or SVG.next, call it what you will). An interesting tidbit is that SVG Tiny 1.2 requires support for the same subset of SVG Fonts that has been implemented independently by several vendors to date. It's a fully backwards-compatible subset, a SVG Tiny 1.2 font is compatible with SVG 1.1 user agents - provided of course that they support at least the same subset of SVG 1.1 Fonts.

In other words, the WOFF font standard is more appropriate, works in more browsers, and is a better way to handle custom font support in browsers.

There are also the TrueType (TTF) and OpenType (OTF) formats, which are equally appropriate, at least if transferred with gzip content-encoding. In fact, downloadable truetype fonts is a part of Acid3 (see the top right corner of the test). WOFF can be used for some things, and it's not a bad format, but it doesn't have the same feature-set that SVG Tiny 1.2 fonts has, and saying they can always replace each other is simply not true. More about that below.

Myth #1: You need to implement the whole SVG 1.1 Fonts chapter to pass Acid3

To be really clear: the entire feature-set of SVG Fonts, where each glyph can have e.g many different fills and strokes, raster images, animation, and be arbitrarily complex, as specified in SVG 1.1, has not been implemented in a single SVG user agent to the very best of my knowledge. Nor is it a required part for passing the Acid3 test.

Myth #2: SVG Fonts and foreignObject support are both required to pass Acid3

Once you put an <iframe> in a glyph, all sorts of issues arise — both in terms of the spec being underdefined and in
terms of the behavior being very difficult to implement, no matter what the spec said.

The spec is really quite clear:

It is not required that the SVG user agent supports the ability to invoke other arbitrary user agents to
handle embedded foreign object types

So in fact it's not underdefined, it's explicitly not defined.

But what are SVG Fonts good for?

Here are a couple of examples:

• Provides simple and manipulable graphics that can help in preserving text as text while maintaining the same visual appearance
• Crossplatform, crossbrowser, with exact metrics and rendering specified by the SVG specification - e.g very useful for designing tests, or for platforms where you can't install fonts as a user
• Easy DOM access to glyph outlines (path data)
• SVG Fonts are fully editable in a text editor
• The path data syntax is more expressive than what e.g WOFF/OTF/TTF fonts allow
• Can be "misused" to do specialized stroking (e.g chain fonts, roads or railroad tracks) - granted, this is also true for other kinds of fonts.

Last time we explored how to get boundingboxes of any svg element. Today I'd like to expand this a bit, and to show what the client (or screen) boundingbox can be used for.

How to get the screen boundingbox

Here's a simple function that returns the boundingbox of an element as a 'rect' element. If the 'rect' element is inserted just after the element that we got a boundingbox for it would in most cases cover that element.

var svgns = "http://www.w3.org/2000/svg";
function getScreenBBoxAsRectElement(elm)
{
  var bb = elm.getScreenBBox();
  var rect = document.createElementNS(svgns, "rect");
  rect.x.baseVal.value = bb.x;
  rect.y.baseVal.value = bb.y;
  rect.width.baseVal.value = bb.width;
  rect.height.baseVal.value = bb.height;
  return rect;
}

Here's an example of how to show the boundingbox as a border around any element in an svg, along with the values in text format. The boundingbox in userspace is shown with a red border, the screen boundingbox is shown with blue border. View live example.

The script that shows the boundingboxes and their dimensions can be viewed here. To use it in another svg file just download that script and the getScreenBBox fallback script to the same directory, and add a 'script' element to the svg file you want to use it in, like this:

  ...
  <script xlink:href="showbboxdims.js"/>
  ...

• Andrea Cassera presented a webapp for visualizing historic volcanic activity using svg, which was demo:ed in Opera 9.5. Currently not publicly available in the version that was shown at the conference.
• Shaun Roe gave a very interesting presentation of a tool called SEDUX which transforms XML data files from the Atlas experiment at CERN into an interactive SVG webapp by using XSLT and clientside scripting. See the paper, and example. Note that Opera 9.6 is required for proper display of the example.
• Yet another cool example of presenting data was the GPS track webapp by Olaf Schnabel.
• Zack Rusin talked about how KDE is using SVG and how he'd like to see SVG improved in the future.

• Jon Cruz showed some of the new cool features in Inkscape 0.47. The workshop was especially helpful, with many useful tips and tricks.
• David Dailey gave a session on SVG Filters, and I don't think we had time to more than skim the surface before time was up.