I’m working with a professional designer, Michael, on some graphics for my upcoming MIX presentation.  I’ve worked with designers before on various projects, some SVG, some traditional Web design, but this is my first time working on an SVG project with someone who never used SVG before, and it’s been an interesting experience, which I thought I’d jot down for anyone interested.

Both of us have been busy with other projects, and since we are in different places (me in Chapel Hill NC, him in Atlanta GA), we have only gotten to touch base a few times.  Michael has delivered some first drafts of the graphics, which look lovely, and I decided to dig into the underlying code, confident that I could trim down the file size and thus help browser performance.

My personal graphical editor of choice is Inkscape, which is a fine tool for all its warts (though it’s a little painful on Mac, where it is hosted as an X-11 application); typically, though, I create SVG either programmatically with a script or manually with a text editor (yes, I know that’s crazy… but it can be done).  Michael, being a professional designer, uses Adobe Illustrator, and I am keen to have him use the tools he is most comfortable with.  Since I want SVG to be used by mainstream designers, I want to understand how their tools work and what their workflow is like.

So, in order to make sure that we can roundtrip the files as seamlessly as possible, while still leveraging the features of SVG, I set about today to establish a workflow with Illustrator, TextMate (my go-to text editor, with a custom SVG code template bundle), Firefox, and its native debugger extension Firebug (with its handy “Inspect Element” context-menu selection).  My goal: to make reusable icons out of some of the graphical assets in the larger image, to be referenced by SVG’s <use> element.

The <use> Element

Some earlier graphical languages, especially special-use ones such as CAD languages for engineering, architecture, or mapping, included a native symbol library.  These would normally include a variety of arrowheads, iconic symbols, line styles (dotted, dashed, etc.), and other graphical primitives.  The problem with this idea is that such symbol libraries were by necessity limited in the number of symbols, and usually only had one or two styles for each basic symbol. Not very extensible.  SVG took a different approach.

SVG has the ability to “clone” an image, to reposition or resize it, and to change some of its styling.  This works on a shape or collection of shapes, whether the image is defined in the same document, or in an external SVG file.  The mechanism to do this is the <use> element, and it looks like this:

<use xlink:href="#myImageId"
     x="100" y="300"
     transform="scale(1.5)"
     fill="cornflowerblue"/>

Translated into English, this code says,

Find the image with the id of “myImageId”, and copy it.  Move it 100 pixels to the right, and 300 pixels down.  Increase its size by half again.  Oh, and if it doesn’t already have a color, make it blue. Thanks.

(That final “/” is the part that says “thanks”, a quaint courtesy missing from HTML5.  SVG was specified in a gentler time.)

Thus, designers can provide their own symbols, in the style appropriate to the task at hand.  There are several good SVG clipart libraries that allow SVG authors to share their symbols and simple reusable images.

You can see that if you draw an image of a balloon, with several paths (the bubble, the knot, the string, and maybe a highlighting accent) and some special graphical effects (a gradient, and perhaps a filter effect) all amounting to a dozen lines of code, and you want to reuse this balloon, you don’t want to redraw it each time; it would be a waste of effort, and result in a much larger file.  For print, this may not be as much of an issue, but for a Web-based format, it takes longer to download and uses more memory in the browser, resulting in poorer performance.  So, instead of rebuilding a score of balloons, or copying and changing the original image description, you can simply make one basic model, sans color, and reference that multiple times, with a different color and size.  It’s easier to do, and each extra balloon only increases the size of the file by a small amount, much smaller than adding dozens of duplicates.

To really take advantage of this feature takes a different way of thinking about the design.  A clever designer can even create several image components and recombine them into composites with even more variation.  Of course, it’s not always appropriate for every project, but my current project has quite a few duplicate images.

This is a feature supported by every browser with native SVG (though not every one yet allows you to reference images in external documents).  So, it’s a safe and natural feature for an SVG authoring tool to utilize in its SVG output.

Best Practice: Make liberal use of <use>.

<use> It and Lose It

Illustrator doesn’t support <use>.

Or rather, it does recognize it, and render it… but it promptly converts any instances of the <use> element to simple verbose copies of the referenced image.  I could not find any way to create an instance of <use>.

Also, when creating gradients, Illustrator seems to get overly specific about the position and dimensions (width, height) of the gradient, needlessly yoking them to a specific element at a particular location and of a particular size.  SVG allows you to define a gradient once and reuse it among several shapes, decreasing the number of gradients; Illustrator should make better use of this feature, and so should Inkscape.

This is not a tool created with the Web in mind.

Because of this quirk, my current file size is about 6 or more times what it needs to be.  Let’s see how we can work around that.

Symbolic Gestures

I spent quite a bit of time –hours, truth to tell, because I’m an Illustrator newbie– isolating individual images (trees, benches, etc.) that were used through the graphic as a whole.

When I make “symbols” (for lack of a better word), I like to find their positioning anchor –that is, the point at which they are most usefully positioned– and set that to the {0,0} point, so there are no unpleasant surprises when placing the symbol.  For most symbols, this is the centerpoint of the symbol; if I have an icon (a badge, a logo), I will position it smack dab at the point in my graphic that it should be applied, relative to other images.  For other symbols, it is one of the extremities, where it will meet up with another shape… for a tree this would be the bottom of the trunk where it sprouts from the ground, for an arrowhead it would be the base where it it attaches to a line.  I try to pick the most intuitive anchor for each symbol.

When you drag a shape to a new location, as I did for creating anchors, Illustrator converts the path or attribute values to their new coordinates, rather than simply applying a transformation.  This is something that Inkscape gets wrong (at least, last time I checked).  Nested transforms are harder for developers to work with than simple coordinates.  So, kudos to Illustrator on this one.

Each symbol is best enclosed within a group… in SVG, this is a <g> element (SVG also has a <symbol> element, but in practice, I don’t think it’s worth much).  Grouping allows the designer to collect all the constituent parts of the image together for greater portability.

When a designer works, if they are anything like me, they tweak a bit here and there, sketching out the rough shape, working on another part of the big picture, then focus on adding details.  A problem arises for a developer who has to subsequently dig into the resulting code… elements are added to the document in the order they are created, so a bunch of shapes that appear to be one symbol might be scattered throughout the document, and might even be in different layers.

Best Practice: Group early, group often.  Create graphical objects, and think about graphical / document structure.  Your developer co-workers will thank you.

Being the non-designer developer I am, my first instinct was to group the elements in a text editor, and as a clumsy first attempt to find the different elements, I used Firebug to inspect each element to find its id or unique data I could use in a text search in the text editor, but the different parts were too scattered for this to be effective; pretty quickly, I turned to Illustrator myself to do the grouping visually.

The process for converting these graphics into symbols was made much clumsier by the selection mechanism of Illustrator.  When things are grouped in Illustrator, it logically selects all the bits of that grouped image.  The problem is that it also does this with layers, as well as groups; you can “drill down” from a layer into an individual group, but when you are first trying to select a set of images that aren’t already grouped, this can be twiddly and frustrating.  Illustrator also defines far too many nested groups, decreasing their usefulness and creating markup cruft that makes later programming harder. Using the selection marquee (the draggy box), you can more easily select the constituent parts of the image, but be careful of any background elements.

Best Practice: When creating symbols, select the elements you want as part of that symbol, either with the selection marquee or with shift+click.  Right-click on the selection, and choose “Group” to group the elements, which should also group any gradients, filters, clipping paths, etc. that the shapes use; in the Layers dialog, you will see the graphics collected under a new group labeled “<group>”; double-click this, and give it a meaningful name.  (Note: you might need to right-click again and choose “Isolate Selected Group” in order to the collect the gradients and other graphical effects into the group; these are not shown in the Layers dialog, so I wasn’t sure at what point they are included in the group.)

“Let Me Tell You What I Think You Mean”

As I isolated each image, I deleted extraneous shapes that weren’t part of any symbol.  I made each symbol into its own file, just to keep them tidy.  Each symbol looked great by itself, but when I finally recomposed all the symbols together, the colors were all wrong!  A little digging revealed the problem… Illustrator changes the ids of the “paint servers” –referenceable graphical effects like gradients and filters– as you delete other shapes.  So, when I recombined the symbols into a single file, some of the gradient ids overlapped and defaulted to the first instance… which screwed up the colors.  This is a portability and maintenance nightmare.

Illustrator tried to be a little too clever here.  Like the way it unwinds <use> references and discards the <use> element, it doesn’t play well with a designer-developer roundtripping workflow.  I ran into many such cases where it discarded changes I had edited by hand.  I tried to resize the document dimensions in my text editor, but when I loaded it in Illustrator, made some changes, and saved it again, it scaled down my graphics (which I’d just explicitly scaled up) and changed the viewport to a much smaller set of dimensions.  Hey, Illustrator, if I wanted it that size, that’s the size I would have made it!  Finally, I gave up, and set the dimensions I wanted in a new file I created in Illustrator itself, and copy-pasted from one Illustrator window into the new document, which seems to have taken.  I don’t like programs which introduce inconsistency into a workflow.

What are you smirking about, Inkscape?  You pull the same kind of nonsense!

Copy-Paste Error

After all this tweaking, I ended up with more or less what I want to start with: a document with the dimensions I need, with a set of reusable symbols at the right scale.

But when I tested it out by selecting a symbol on the canvas, copying it, and pasting it in its new location, I was disappointed to find that Illustrator copied the parts of the symbol, but not the grouping… it just added the individual parts of the graphic directly in the target layer.

FAIL!

I messed around a bit more with the interface, and through luck, I stumbled on a different way of selecting the symbol.  By toggling a selection button for the group in the Layers dialog, and copying that (Ctrl/Cmd+C only… Illustrator doesn’t provide a right-click menu on items in the Layers dialog list), I could paste the group.

Best Practice: Copy and paste symbols from the Layers dialog to preserve their logical structure.

This is a far cry from having a <use> element, but I plan to apply a post-processing step to the final document, replacing duplicates with <use> references.  Luckily, Illustrator didn’t give the pasted copy a completely random id, but simply appended an incremented number to the original symbol id, so this should be fairly easy.

My next step is to turn the new document over to Michael, my long-suffering designer, and see if any of this makes sense to him, or if he will come to his senses and throttle me for imposing all this developer madness on him.

To Be Continued…

I recognize that my own inexperience with Illustrator is probably behind some of my missteps (the full extent of which I have shielded from you, dear reader).  On the other hand, a fresh pair of eyes can often spot flaws that could be eliminated where an experienced hand would simply repeat the same mistakes.

This project is far from over, and as I refine my workflow, I’ll report back what I discover.  Some of what I learn may inform future versions of SVG.  Other parts should be changes to the authoring tools.  Hopefully some of it will help help designers and developers work around issues in creating SVG with the tools they use today.

I attended Google I/O a couple weeks ago, and had a great time.  They really put the “hype” in HyperText Markup Language 5, identifying things like the Geolocation API and some of the WebApps Working Group deliverables as part of “HTML5″.  Not quite accurate, but it was a branding exercise, not a technical one.  Notably absent from the things they rolled into HTML5 during the keynote, though, was SVG… in fact, they seemed to go out of their way to avoid it.

But it’s in there.

Behind the curtains, I talked to several Googlers at the conference committed to SVG.  Brad Neuberg, a whipsmart Google engineer and all-around swell guy, is making a Javascript shim that takes SVG (referenced or inline) and renders it consistently across browsers, including Internet Explorer, using the Flash plugin.  Patrick Chanezon and Ignacio Blanco, also of Google, spoke about SVG and Canvas at JavaOne the week after.

It wasn’t a certainty that SVG integration would make it into HTML5 (rather than HTML6, etc.).  I’d been asking for it to be included for a while, but the the editor, Ian Hickson, was resistant to the idea.  At one point, he even suggested supporting some other vector graphics language, even a stripped-down custom format (which was likely a testing of the waters… in a similar vein, rather than simply integrating custom namespaces or RDFa or ITS, he reinvented his own syntax for each instead).  But ultimately, even he knew that wouldn’t fly for vector graphics.  SVG is already too well supported in browsers, in authoring tools, and as a general format for anything else to make sense.

Because it’s all about the platform.  And SVG is part of the platform.

Already, inline SVG (that is, SVG mixed into a single document with XHTML) works in all the browsers that support both XHTML and SVG (that is, all but Internet Explorer), and even worked in plain-text HTML in Internet Explorer with the Adobe plug-in almost a decade ago.  Steven Pemberton points out that that was the true innovation of XHTML, the ability to plug in new syntaxes and new functionality without having to change the core of the language or revisit parsing rules.  It has been argued that XHTML’s extensibility is superior to HTML5′s parsing rules that only work with a set vocabulary.

But the browser vendors were determined that text/html, being more common and robust than XHTML, had a market advantage, and so to fit in with that, SVG needed to work not just with XHTML, but also with text/html.  There were compromises along the way with SVG… probably chief among these are parsing issues.  Unlike XHTML, SVG was designed from the ground up for an XML syntax.  HTML uses a much more complicated parsing that defines error recovery behavior for things like missing quotes around the attribute values, case insensitivity, and non-well-formed markup, and it doesn’t support namespaces properly.  SVG in text/html has to (some say “gets to”) follow some of these rules in order to fit in.  The SVG WG was a bit reluctant to adopt these changes, out of concern that SVG might fly into tag soup, making it harder for existing authoring tools and XML-based SVG viewers, as well as generic XML processing tools.

But ultimately, we had to agree that SVG needs to conform to the platform.

So, we’ve taken a step backwards in some ways: right now, there’s pretty much no non-conforming SVG content in the wild, and the Adobe SVG viewer was fast, and had features still not found in some browsers.  But we’ve now got better error recovery, and SVG in almost all major browsers, which is more robust than a single-vendor plug-in, and is ultimately better for authors and users.  The way to use it with HTML is now better defined:

• as with HTML, for SVG in text/html, you don’t have to use quotes on your attribute values (if the value doesn’t contain spaces, etc.)
• authors don’t need to declare namespaces (in fact, this was the case with the Adobe SVG Viewer already, so not really much of a loss)
• mistakes in casing for element and attribute names will be corrected
• well-formedness errors will be recovered as best as possible, rather than halting rendering
• custom namespaces, such as round-tripping metadata inserted by authoring tools, will not be supported
• most importantly, normal valid, well-formed SVG with no custom namespaces will Just Work, whether as a standalone document or referenced as an external file, or inline in text/html or XHTML.

In fact, though HTML5 is not yet done, SVG inline in text/html already works in special experimental builds of Firefox and Opera, and should work out of the box soon.  Forward-looking authors can already use SVG in modern browsers, using XHTML, and that content will soon work when served as text/html as well. The final barrier to common use of SVG is being solved by Brad’s “SVG Web” shim, allowing SVG content to work in IE.  This will not be a perfect solution; it would be better if IE supported SVG natively without making developers jump through hoops, but that won’t happen for at least a couple years (if at all), and SVG Web at the very least will bridge the gap.  I’ve seen it run, and it’s pretty impressive already.

That SVG has had to bend in the wind gives the SVG language a unique opportunity to innovate.  If the syntax is already going to need an update in existing browsers and authoring tools, we can reexamine some old assumptions and past missteps, and extend SVG to be better integrated with HTML and CSS and existing scripting practices.  And even more importantly, we can examine use cases and make SVG better suited for what authors need to do.

Why is HTML5 a powerful enough platform that Google throws it’s weight behind it, despite the inaccurate and ungainly name?  Is it the error-correcting parsing?  No, that’s a good feature, even if the need for it is unfortunate, but it’s unclear that this is better than XHTML.  Is it the new features like the <video> and <audio> elements, which allow it to compete with the most common use of Flash?  No, that capability has been possible using XHTML and SMIL for years, and is even part of SVG Tiny 1.2 (N.B.: HTML’s script interfaces are simpler and better than SMIL’s, but its lack of synchronization or timing containers is a big step back).  Is it the new WebApp-centric user interface focus?  No, we would probably be better served by a language designed for making UIs (like XUL).

So, what is the true power of HTML5?  Coordination.  Getting all the browser vendors to standardize on a common set of features.  HTML5 is not a technical achievement, it’s a social movement.  It’s an instantiation of the Open Web in the form of several specifications across several groups, and implemented fairly uniformly across all major browsers and platforms.  This is largely in response to user demands to the browser vendors.  They are tired of the special-casing and workarounds that make their lives and jobs harder and less satisfying, that make users struggle… they want a consistent platform, one without script libraries or shims or plug-ins or arcane rules.  And the browsers realize this, and know that a rising tide raises all ships.

My personal advice to vendors who have excellent authoring tools, but who want to also control the runtime environment?  The Web has moved on from vendor lock-in and black-box plug-ins.  In a world where there is coordination between multiple vendors to deliver and support a central set of technologies, where everyone is unifying on a standard Open Web platform, from Apple to Google to Mozilla to Nokia to Palm to Opera to Vodafone.  Nobody wants the hassle of being the only one to maintain the platform, but they all want the ability to change it without going though the gatekeeper of a single vendor.

It’s all platform games, and if you want to play, you have to jump to the next platform.  Google knows this… they are hosting the next SVG Open, and are aggressively pushing the whole platform.  Looks like a fun year ahead!

I wish I kept a more detailed journal… I have chat logs and emails as a quotidian reminder of my doings, but it doesn’t capture all the great conversations and interesting people I meet when traveling.  This short trip to Tokyo, only 10 days or so, was jam-packed with cool folks with cool ideas.  But now I’m jaunting back to Tokyo from the W3C-Keio office, and then to the airport, so no time, no time…

Maybe on the plane I will sketch out my erstwhile meanderings.  The short version: spoke at Web Directions East (and will speak again at Web Directions North) about SVG and Canvas, was blown away by the other presentations there, hung with cool Web community folks (locals and internationals) who I hope to see again, ate good food, wandered the streets of Harajuku and Shibuya and Asakusa and Ebisu, watched mochi being made at a temple festival and ate the results, met with the Japanese chapter of the SVG Interest Group and some Japanese Industrial Standards folks regarding SVG 1.2 Tiny and further on, and collaborated with my awesome and inspiring W3C-Keio teammates.  Had no access to my cash because of a mixup with Visa/RBC.  Stayed in another capsule hotel, in Fujisawa.

And saw Mt. Fuji two clear days in a row, with lovely warm winter weather.  Sayonara, Japan!

I’m in Beijing, presenting at the WWW2008 conference.  Last night, we attended a banquet at the Great Hall of the People, which (ironically) is hard for most Chinese people to get into.  On the long bus ride there, I was rather surprised to see a young man driving a trailer-bike with an anarchy flag flying from a pole.

I’d have loved to grab a picture of this, but we were warned that the security wouldn’t let us in with any camera bigger than a mobile phone.  Foolishly, I took them at their word; others brought in SLRs, so it’s clear it wasn’t that serious a matter.  One of my colleagues refused to attend, even though he had a ticket, because he didn’t approve of the security screening; I admire his principles.

The banquet was great, with good food and several performances by singers, dancers, musicians, and even a truncated opera.  Tim Berners-Lee gave the keynote, and he spoke about the size and rate of growth of the Internet, comparing it in size to the number of neurons and connections in the human brain.  He also opined about social networks, urging them to adopt privacy policies that respect the users, with the expectation that that would lead to open systems with open data.  He discussed challenges and opportunities in the standards process, pointing out that the very factors that build cohesion and camaraderie in groups serve as bricks in the wall that divides that group from the larger community.  Finally, when asked to speculate about how the world would change because of the Web, he was quick to point out that the Web was built by people, by the larger community, and that this distributed effort will allow humanity to experiment with new models of economy, of cooperation, of government, and with science itself; that we could “let a thousand flowers bloom”, and pick the best path forward in all our endeavors.

I’m here in Banff, Canada for the 2007 W3C AC (Advisory Council) meeting. The AC is essentially the company reps to the W3C. I played a small part in one of the panel discussions yesterday.

It was the last presentation of the 2-day conference, and the theme was Web2.0: what it is, and how the W3C is adapting to and enabling it. I gave an overview of what Web2.0ey things WAF and WebAPI WGs are doing. It went well… I made a short SVG slideshow with some geeky in-jokes, and it got some laughs. It may have been slightly overshadowed, however, by the conversation between 2 of the other panelists: Sir Tim Berners-Lee (the creator of the Web) and Tim O’Reilly (a prominent tech publisher who coined the term Web2.0). Tough act to follow.

The conference was a lot of fun, as usual, and I got to meet and talk with a lot of technical luminaries, including Dave Raggett, who’s generously letting Chaals and I crash in his hotel room.

I’ve been out here in Santa Clara, CA, the last couple of days at SD West, a developer conference. There have been a few good classes (I finally met the hyperproductive Elliotte Rusty Harold for the first time), and a couple of great events. David Platt gave a hilarious and insightful talk based on his book, Why Software Sucks, and Google dominated at the geek-themed quiz show, Developer Bowl. 6th Sense was a finalist for the Jolt Awards, which were announced here last night, and I stood in for our marketing guy, since I was going to be here anyway. We didn’t take away the grand prize for our category, but we were one of the runners-up; we got a nice little plexiglass plaque.

I’ll be holding my own class on SVG tomorrow afternoon. I don’t know how well attended it will be… the last day of conferences tends to have a lot of attrition. But it will be fun anyway, and I always enjoy evangelizing SVG. I whipped up a little presentation app in SVG… it uses the powerpoint idiom, but slides around a large canvas between text and interactive examples. I’ve been using SVG slides for a while, but this is a little more interesting… well, interesting to make, I hope it’s interesting to watch. The class will center on workflow using SVG, and I’ll dig into code here and there (this is for developers, after all).

Update:  I’ve put my SVG slideshow up here.

We really had a productive face-to-face meeting of the SVG WG last week. Converging on Raleigh were Chris Lilley of W3C (Scottish, but living in France), Andreas Neumann of ETH (Switzerland), Andrew Shellshear of Canon (Australia), Andrew Emmons of BitFlash (Canada), and Erik Dahlstrom or Opera (Sweden), and Antoine Quint of The (mysterious) Venice Project (France). We locked ourselves in a room and finished up the revised test suite, broke the ground on the errata document.

At one point, our Canadian colleague stated, quite straight-faced, that he was (and I quote) “jiggy with” a resolution on a particular technical point. My jaw dropped. I didn’t know anyone was jiggy with anything anymore… but he went on to claim that it’s a common thing for Canadians to say. Just when you think you know a country, they drop a bombshell like that…

Read on for a brief summary of the proceedings…

The test suite took far longer than expected, as expected. We spent nearly 3 days locking down what we’d hoped would take a few hours, but these things rarely go smoothly. But we were determined that it would be published before we closed shop, and published it was. One reason it’s so vital is that it will serve as the backbone of the SVG Tiny 1.2 Test Suite, which we need for that spec to move forward.

We made up for the lost time by working an extra day, meeting for 5 days instead of the usual 4.
We also began the SVG 1.1 Errata, a document that will correct some mistakes (ranging from mere typos to troublesome ambiguity to maldesigned features) from that earlier spec. Our publication goal for that document is early January. An errata is critical for new implementations, so they don’t have to implement bugs while trying to conform to the spec, and so they know how a feature is supposed to be implemented in the first place.

We also took care of a few liaisons with other standards groups, both within W3C and outside. We reviewed the upcoming XBL2 spec (a pretty exciting technology that I will talk about at some later point), and tried to coordinate features with another specification from the MPEG group which is mandated to use SVG. We intended to communicate with the CSS Working Group about their CSS 2.1 spec, which is moving toward Candidate Recommendation status, just to make sure that our 2 technologies don’t needlessly clash, but the chair of our group fell deathly ill the day we meant to do that (unrelated, I’m sure… well, probably). We’d set a pretty aggressive agenda, so I’m not surprised a couple of things got lost in the shuffle.

In addition to all that bureaucracy, we did some exciting first steps toward our next specification. Going forward, rather than publish a monolithic spec that takes forever to publish, we will be making smaller, more focused specs that will combine, Voltron-like, into a larger, more powerful spec. The first 2 modules (as we’re calling them) have their early drafts done: SVG Print, and SVG Filters. We reviewed them and resolved some issues there.

Finally, we ended the face-to-face on a fun note by judging the SVG logo contest. I’ll write a separate post about that, but suffice it to say that I was pleased with the winning entry.

All this week, 6th Sense Analytics (my employer) is hosting the SVG Working Group’s F2F (face-to-face meeting). Normally, the SVG WG conducts its business via email or twice-weekly “telcons” (voice conferences enhanced by concurrent group chat sessions in IRC). But there’s nothing like sitting around a table, locked in a room together, to get resolutions on issues. Thus, the quarterly F2Fs.

So, a contingent of the SVG WG is gathered here in Raleigh (well, Morrisville), NC. We’ve been hard at work knocking out the long-overdue SVG 1.1 Test Suite (more later), liaisons with other standards groups, and other matters.

For dinner the first night, we went to a pub in Raleigh called Hibernian. Our chair, Chris Lilley, entered us into the pub quiz under the obscure (dare I say geeky?) moniker “SVG++”. When the announcer was introducing the teams by names (most of which involved being drunk), he exclaimed, “SVG-plus-plus…? What is that, a disease? Get an ointment for that!”

If you’re really interested in the gruelling details of the F2F, read on…

SVG 1.1 Test Suite

As any QA person will tell you, test cases are as important as they are mind-numbingly tedious. Without a test suite, implementors of a technical specification (like browsers or authoring tools) have no good way to make sure that they are indeed conforming to the spec. As complete as a specification may be, the devil is in the details, and there are innumerable tiny ways that different implementations can diverge. This is well and truly annoying for content authors, who want their page or image to just work across browsers (and rightfully so). Implementors know this, and they have 2 choices:

1. Make a guess, and do it the way they think it should be done (hopefully, the way they interpret the spec, but sometimes how they think the spec should have been), and hope that all the other implementors do it the same way; or
2. Copy the behavior of other implementations, whether or not it agrees with the spec.

With both options, but especially the second one, you are likely to differ from what the spec says, and so authors just do what works… even if it’s technically wrong. You can’t blame them. This happened with Adobe’s SVG viewer: it did lots of stuff “wrong”, and when Firefox and Opera came along and did those things right, folks found that their content from years back was suddenly broken. That sucked. HTML also suffered from this, and got caught in an downward spiral, where implementors had to support the wrong-but-backwards-compatible behavior that most content authors were forced to code to by implementors that supported the wrong behavior…

SVG is hoping to avoid that by simply moving forward and being more precise in what implementors should do in any given circumstance. This is where the test suite comes in. With a complete test suite that provides reference behavior (especially for tricky bits that are subject to misinterpretation), implementors know where they went wrong, and authors can definitively point out specific bugs that they need fixed.

Of course, this test suite should have been published 3 or 4 years ago, when the last version of the spec was published, and implementors (and vendors) are chomping at the bit for it to be done. But like I said, this is boring and exacting work, so I’m not surprised it got put off when there are tons of other things on the agenda.  To be fair, most of the tests were already created long ago, but needed to be reviewed, corrected if necessary (bad tests, as you might suspect, are bad), put into the proper format, and published.  But we’re on a forced march to get it out this week, and to start on the SVG Tiny 1.2 Test Suite and the errata for SVG 1.1. More on that tomorrow.

I just sent in my confirmation letter for my presentation at SD West 2007, a respected technical conference series in Santa Clara, California. I’ll be speaking on (can you guess?) SVG (you got it!) in a talk entitled Scalable Vector Graphics: Shaping Up the Web. The conference will be going on March 19-23, 2007. My company is really working on getting speaking engagements, so I think this may be only one of several that I’ll be doing in 2007. Of course, I will be speaking at –and helping to plan– the SVG Open conference next year as well. I normally give a 101 class introducing SVG there, in addition to a presentation on current projects I’m developing.