Wow. After a ridiculously long time in preparation, with political battles along the way, and a long slog of making tests and maintaining older versions of the spec, as well as working on supporting specs like Element Traversal and DOM3 Events, SVG Tiny 1.2 is finally a W3C Recommendation. Whew!
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!
SVG 1.2 Tiny, previously in CR, went back to LC today. Which might seem like a step backwards, but is really a huge leap in the right direction.
Okay, you have no idea what I’m talking about, right? So, the W3C’s Recommendation track looks something like this:
- Editor’s Draft, where ideas are just being hashed out
- First Public Working Draft, where we have the basic direction, but still in rough form, and are seeking initial public feedback
- incremental Working Drafts, where the draft spec improves over time, based on review and comments
- Last Call Working Draft, where we pretty much think it’s done, and ask the public to give it a final once-over
- Candidate Recommendation, in which the spec is mostly stable, and where we invite implementors to actually write the code and provide the wisdom of experience
- Proposed Recommendation, where the W3C Members get a final chance to say what they like, don’t like, and provide their official comments for consideration to the Director
- Recommendation, where the Director (usually Tim Berners-Lee, in consultation with trusted advisors) looks at the spec, looks at the comments, and decides whether or not this should have the stamp of approval from W3C.
On the surface, SVG 1.2 Tiny going from Candidate Recommendation to Last Call seems rather counter-productive. But the truth of it is, the SVG spec has changed quite a lot for the better, due to lessons learned during implementation and building a test suite. But change is change, and if you change the spec any time before Recommendation status, you go back to Working Draft (in this case, Last Call Working Draft). This lets everyone review the current spec, and provide critical feedback before we move forward again. But with a solid test suite (though no test suite is ever really done), and several interoperable implementations, the current state of SVG 1.2 Tiny is much improved over the previous Last Call, so the path to Recommendation is actually much clearer this time.
I’m really proud of the work the SVG Working Group has done, and I’m honored to have been part of it. I’m glad that we are now a public working group, so people can see what we are working on and help steer us in the right direction (especially with the new SVG Interest Group that I co-chair with Jeff Schiller). I’m relieved that the long haul of completing SVG 1.2 Tiny may be coming to an end. And I’m confident that this specification will really push SVG forward.
And have we got some cool things planned for the coming months!!
We stayed in sleek Shanghai for several days, recovering (first M had the stomach flu, then I played the copycat the next day, though with much milder symptoms). We saw the impressive Shanghai Museum and the amusingly propagandistic Museum of Urban Planning, shopped in a trendy hutong and in the shops outside (and inside) Yuyuan Garden, walked the Bund and saw the Pearl from across the river, and spent a rainy day in art galleries, all with free lodgings, bikes, and frequent use of a driver. Our hostess was very gracious, which I hope we can repay when she visits her daughter (our friend K) in Chapel Hill. I worked a bit, too, attending a few telcons and answering some emergency emails.
But we’ve been back in Beijing for a few days, seeing a few sites we’d missed the first time we were here. Today we saw a Taoist temple; it was quite a welcome novelty after seeing so many Buddhas in temples and museums… I’m as weary of images of Buddha as I was the ubiquitous “Madonna and Child” motif after months traveling Europe years back. We also visited a small unrestored temple with gorgeous carvings and statues… they had the original intricate paints, not the cartoonish solid-colors of most of the refurbished temples we’ve seen here.
I was surprised at first to see so many active Buddhists praying in the temples here, since I thought most religion was wiped out in the Cultural Revolution, as it largely was in Soviet Russia. But M pointed out that the larger number of religions here may have led to a more adaptable approach… Communism is just one more bureaucratic religion that will be absorbed into China, the latest of many.
We then went to a huge bookstore, bustling with hundreds of people; I was hoping to find some English-language translations of Chinese science fiction stories, having read some Soviet sci-fi stories in the past and being interested in the Chinese take on it. No such luck, though we did get some music CDs and a novel about the Mongolian steppes.
Finally, we ended our stay in China in teahouses… first in one in a hotel, then, coincidentally, dinner at another in the lakes district.
Since I was Down Under for the annual SVG Sydney F2F anyway, I made plans to meet with some key players in the Annodex Foundation. They are doing some amazing stuff with video on the Web, far ahead of anything I’ve seen elsewhere. I first met Silvia Pfeiffer at the W3C Video on the Web Workshop a couple of months ago. She threw a small barbecue on Saturday, and we met again for dinner and drinks at Coogee Beach on Sunday evening, this time my my friend Andrew Shellshear, who I stayed with over the weekend and who is doing some neat stuff with video himself.
We talked about true video hyperlinking, media metadata and searching and APIs and the Semantic Web and accessibility, proxies and caching and bandwidth, codecs, uploading and streaming, and sundry other things regarding video as a first-class citizen of the Web. This is a hot area to watch for Web standards, because it needs to be done right, and it needs to be open.
I’m here in Sydney to attend the SVG Working Group F2F. This marks the third time I’ve done this trip. When I first joined the SVG WG, I flew here for my first face-to-face meeting, and SVG 1.2 Tiny was in the can, no new features, only such changes as required by Last Call comments; this was a bit frustrating for someone who set out to represent authors, since I really felt some new functionality was needed. But it had already been too long between versions, and SVG 1.2 Tiny just needed to be published before new work could be started, so I took one for the team. I was assured that it would be published and done within months.
Well, the best-laid plans… I was here last January again, and the same situation applied. We’d received an avalanche of Last Call comments, from typos to tweaks to time-wasters to trip-wires. It amounted to a sort of Denial of Specification attack. Many of the comments were valid criticisms (though a few of those couldn’t be helped due to legacy or other dependencies), but an equal number were ideological. But all of them had to be dealt with. This had occupied the past year, and looked to occupy the foreseeable future, but we soldiered on. The biggest chunk of work was dealing with errata for SVG 1.1, and with the test suite and implementor feedback (which is the point of “CR”, the Candidate Recommendation stage of becoming a W3C Recommendation). We also split out some functionality into the WebAPI WG, so it could be more generally used by other Web technologies besides SVG. So last year, it looked like one step up and two steps back.
And now another year has passed. In this last year, I came to work for W3C directly, and the SVG WG has two new Chairs, one each from a desktop and a mobile implementor (Opera and BitFlash). SVG 1.1 is better specified, due to errata, and better implemented, due to good, interoperable native implementations in Opera, Safari/WebKit, and Firefox. SVG 1.2 Tiny is widely deployed on mobile phones (more widely than Flash Lite), due to excellent implementation by BitFlash and Ikivo, and has a good test suite that’s still growing (and will keep growing even after it’s published… can’t have too many tests). We’ve cleaned up the SVG 1.2 Tiny spec, and made progress on ancillary specifications. We’ve pared down what needs doing in order to move forward to the next stage on the Recommendation Track. We’ve learned from past mistakes, and we’re working more openly with implementors and the general public.
And we’re talking about new features. We spent a day this F2F planning several small modules for the next year or so that will add capability to SVG, and make it easier to author compelling content in this iPhone age. SVG was a bit ahead of its time (especially as regards uptake in desktop browsers), but with the delays of the past couple of years, competing technologies are pulling ahead. We’ve got an aggressive plan that includes bringing in more direct feedback from designers and developers, and targeted feature additions.
When I joined the Working Group three years ago, SVG was struggling and morale was low. But now we’re really excited by all the recent progress and the momentum behind SVG. This looks like a good year for SVG.
ACID3, that is. Most of you will have heard of the ACID tests put together by the Web Standards Project in order to promote interoperability among browsers. Microsoft recently made a hit in the blogosphere by announcing that the next version of their browser, IE8, passed the ACID2 test, showing their commitment to Web standards.
SVG has had a huge surge of popularity in the past few years; it’s now used on Wikipedia and Google Maps, and largely implemented in 3 of the 4 major browsers (it works in Opera, Safari, and Firefox). There are a few inconsistencies between implementations, so we thought ACID3 would be a great chance for a push for SVG interoperability. The SVG Working Group, most notably Erik Dahlstrom of Opera and Invited Expert Cameron McCormack, devised a few tests that we hope will be included in ACID3.
You can read the explanations for the tests, and see the tests themselves, in Erik’s email. Let us know what you think, and if you support the inclusion of SVG in ACID3 (and let Ian Hickson know, too). Maybe by the release of IE8, it will pass ACID3 –and any SVG tests– too.
[originally published on the W3C Questions and Answers blog]
Update (25-01-2008): Just so you know, our efforts paid off. Hixie accepted our tests, and SVG will be in slots 70-74 (or 75) of the Acid3 test. I think this will be a great win for interoperability, and nice acknowledgment that SVG is a first-class citizen of Web architecture. Thanks again to everyone who contributed to the tests and to the conversation, and to Ian Hickson for putting the tests in (and for driving Acid3 in general).
- Doug Schepers (a Montague)
- Anne van Kestern (a Capulet)
- Simon Pieters (a Capulet)
- Henri Sivonen (a Capulet)
- Rich Schwerdtfeger (a Franciscan)
- Aaron Leventhal (an Apothecary)
Over the past few weeks, there has been a long, drawn-out discussion about how to integrate ARIA (an accessibility specification) into both SVG and HTML in a uniform way. There have been two main camps, as there usually are in these matters: the XML advocates, and the HTML5 (WHATWG) advocates. Both sides want to make sure that all content works the same across all browsers, authoring tools, etc. (collectively called User Agents), but they differed in how they thought it should be done.
The XML True Believers have held that the way forward for the Web is to enforce a strict, well-defined syntax for Web languages, and that to extend or combine languages, a differentiating mechanism called “namespaces” would be used. Namespaces in XML are specified to take the form “schepers:doug”. They declared a do-over on HTML, recasting it in the new XML mold (XHTML), and planned for browsers to be stricter on new content, and for authors to have learned their lessons.
The HTML Young Turks came forward with the observation that no matter how well you define a syntax, people will make mistakes (or not know the right way to do things), and that the way to recover from those mistakes is to define error-handling behavior for each kind of mistake; they also believed that since they could now reconcile older “broken” content with new browser behavior, that they were constrained to define behavior that would work in all past browsers, as much as possible, and to degrade gracefully in those that didn’t. But this required a more rigid parsing mechanism that doesn’t work well with extensibility, a problem exacerbated by Internet Explorer’s idiosyncratic and variable (one might even say spasmotic) behavior regarding the colon (“:”), meaning XML Namespaces didn’t work right. Also, the colon has a special meaning in CSS, yet another wrinkle.
So, XHTML and SVG are based on the XML model, and the new HTML5 is based on the new-old model. This difference wasn’t really much of a problem for SVG, though, because SVG and HTML are two different languages…
But of course people want to use them together. (More on that in some other post.)
The obvious way around that is to have two different parsers (a parser is a program that reads a formal syntax and makes a model of it for the browser to act on), and when you encountered SVG inside HTML, you would switch to the stricter parser. HTML would have its model for naming attributes (with no colon), and SVG would have its attributes (with a colon).
But there’s a hitch. ARIA is an accessibility technology meant to work in HTML and XHTML and SVG (and other presentation languages). The functionality for ARIA is defined in its own specification, but it’s not intended to be used on its own… it has to be integrated into a host language. It would be confusing for authors to have to use two different syntaces for the same functionality in different languages.
For example, in SVG you might have:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:aaa="http://www.w3.org/2005/07/aaa"> <g xhtml:role="checkbox" aaa:checked="true"> <rect x="5" y="5" width="20" height="20" rx="5" ry="5" fill="none" stroke="crimson" stroke-width="2"/> <text x="30" y="22" font-size="18" fill="crimson"> Enable Accessibility</text> </g> </svg>
While in HTML, you would have something like:
<html> <ul role="checkbox" aria-checked="true"> <li>Enable Accessibility </ul> </html>
Let the drama unfold…
I just signed the contract! I’m now officially part of the W3C Team, in the role of staff contact for the SVG, CDF, and WebAPI Working Groups. Basically, I’ll be writing and editing technical specs (and tests and tutorials and sundry other periphiana), promoting the implementation and use of open standards, doing grunt work for group members, aiding in liaisons between groups and organizations, organizing international meetings, and getting people to play nice together. And coding… I think it’s important to eat my own cooking (not literally, though… I’m not much of a cook).
The contract is actually retroactive to June 1st, since I unofficially started on the job while waiting for the paperwork to go through (though I’ve been keeping it relatively quiet, in case things went pear-shaped; I have to thank Chris Lilley for his heroic efforts in making it all work out). The position is funded through the Keio University W3C host office in Japan, and I’m excited about visiting there (and hopefully staying there for a time). For now, I’m working from home or on the road.
I wasn’t really a great fit at 6th Sense (my last job), though I think they’re all good folks, and I wish them well with what is truly an innovative service. Frankly, though, I was more passionately involved in my Standards work, and I don’t think that a start-up like that really has a strong need for a pet standards geek (they’re using standards, but not implementing them). Obviously, sometimes you have to sacrifice some of your passion for quotidian practicalities (I have a mortgage after all), but in this case, I was lucky enough to have a safety net: an open position at W3C, with a job description practically tailored to me. I’ve been actively involved with SVG for years, and as part of the WG for a year and a half; I’ve been in on WebAPI since it’s inception, and even presented at the Compound Documents Workshop where the idea was conceived. The pay is not nearly as good as I was getting before, but I think I will find it more fulfulling. Open standards gives me hope for the future.
But I’m not a believer in open standards because I’m an employee of W3C; I’m an employee of W3C because I’m a believer in open standards. I feel strongly that they are the only thing that allows the Web to flourish, and I have grave misgivings about proprietary formats (like Flash and Silverlight). This is an opportunity for me to devote myself to keeping the Web open and to move it forward. The W3C has had a bit of a rough couple of years, PR-wise, with criticism of its methodology, but I think that it is the best hope we have for a free Web. I’m honored to be a part of it.
I’ve spent the last week here in Zurich, Switzerland, for an SVG F2F. I’m staying with Andreas Neumann (GIS PhD student, SVG pioneer, and organizer of the SVG Open conference series) and his wife J. (also a cartographer); they’ve been gracious hosts to Erik Dahlstrom and me, providing room and board in their spacious and elegant apartment nestled in a small village outside of Zurich. The weather has been nice, and several times we dined out on their patio, including Friday night when they had the whole Working Group over for dinner. The view is of the Alps is lovely, though Andreas says it’s even better when the sky is clear… they can see higher peaks further away. Yesterday, the four of us took a gloriously scenic train ride down to Lucano, on the shores of Lake Lugano in the Italian part of Switzerland. We hiked up a small mountain and had lunch at a restaurant at the peak. It was somewhat cloudy and rained a bit while we were eating (good timing), but the view was still lovely, and we all had a good time.
Speaking of climbing the Alps, the SVG F2F was a lot like that. We have all been channeling the bulk of our energies for the last several weeks (and to a lesser extent, months) toward preparing for the SVG Tiny 1.2 Test Fest. It’s been like climbing a mountain, with long tedious preparation before the event, culminating in a burst of exertion. Concentrating on the testing, we didn’t have the opportunity to cover as wide a variety of issues as we have in past F2Fs, though we did spend Friday afternoon discussing administrivia, some unresolved issues with the microDOM, and the other specs we’re working on, including Print and Filters.
Read on past the fold if you care for a little more detail about the technical stuff…
Continue reading “Climbing the Alps”