Reinventing Fire

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. Read the rest of this entry »

While answering a question about styling SVG with CSS in the Freenode #svg IRC channel (yes, people still use IRC), I threw together a simple example to illustrate.  I like to do this, since in keeps me in practice, and gives me a chance to check the state of current implementations in the fast-changing world of SVG browser support.

The question was how to use CSS stylesheets, both internal and external, with SVG in Inkscape.  While I know that Inkscape makes heavy use of CSS inline style declarations on elements (more than is to my personal taste, to be honest), I didn’t (and don’t) know if it has any UI features for adding internal stylesheet blocks, or links to external stylesheets.  So I made a little test…

svgstyle.svg

<?xml-stylesheet type="text/css" href="svgstyle.css" ?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     width="100%" height="100%" viewBox="40 0 145 70">

  <style type="text/css"><![CDATA[
     ellipse
     {
       fill: lime;
       stroke: green;
       stroke-width: 10px;
     }
  ]]></style>

  <rect id="inline" x="50" y="10" width="30" height="50"
        rx="5" ry="5"
        style="fill:lime; stroke:green; stroke-width:3px;"/>
  <ellipse id="internal" cx="103" cy="35" rx="15" ry="25"
        style="stroke-width:3px;"/>
  <circle id="external" cx="150" cy="35" r="25"
        style="stroke-width:3px;"/>
</svg>

svgstyle.css

circle
{
   fill: lime;
   stroke: green;
   stroke-width: 10px;
}

Which looks like this (at least, in Firefox, Opera, Safari, and presumably Chrome):

Both internal styles worked fine in Inkscape, but the external reference did not, showing just a black circle.  I’m not really surprised.  Note the clunky way that you have to link to external stylesheets in SVG:

<?xml-stylesheet type="text/css" href="svgstyle.css" ?>

That’s really XSLT-licious. I have to confess, I don’t really care for PIs (insert dated Magnum PI joke here), or XML prologs in general… they seem somehow clumsy and un-XMLy, like a throwback to SGML. And as far as I know, they can’t be created or changed dynamically via clientside script. Compare that to the relatively easy and straightforward X/HTML way of linking to external stylesheets:

<link href="svgstyle.css" rel="stylesheet" type="text/css"/>

In the SVG WG, we intend to allow authors to reference external stylesheets in a manner a little more modern and consistent with what authors are already used to using, in some upcoming spec. We could do that a couple of different ways. We could allow them to use an xlink:href attribute on the <style> element, in the same way we currently treat the <script> element (that is, if there’s a resolvable external link, we use that, otherwise we use the child content of the element), or we could add a <link> element like X/HTML, or both. I kinda like the idea of allowing either.

To that end, I made a couple of tests, just playing around, to see if any browsers accidentally supported either of those options, by merit of having some shared codebase with X/HTML in their implementations. Unsurprisingly, neither worked.

But then I had another idea… use the an <xhtml:link> element in the XHTML namespace…

<xhtml:link href="svgstyle.css" rel="stylesheet" type="text/css"/>

With this rather happy result, which works in at least Firefox, Opera, and Safari.
external-link-xhtml.svg:

I don’t know if this is by design, or if it just fell out of the model, but I have to say I’m pleased as punch that it works. If nothing else, it’s a great proof of concept for adding more ways of linking to CSS in the SVG spec. This one goes in my toolkit, and I’m going to try to ensure that it gets standardized, if it’s not already there in some corner of some other spec. Probably somebody already knows about this (hell, probably everybody does, and I’m late to the party), but for me it was a w00ty discovery.

Update: heycam speculated that you might also be able to use @import rules, and indeed you can:

<style type="text/css">@import url(svgstyle.css);</style>

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!

Read the rest of this entry »

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!

The SVG Working Group met in Ottawa for the SVG 1.2 Tiny Test Fest this week, which went very well.  The Test Fest was sponsored by BitFlash at the Brookline Hotel, which is where the Bilderberg Group met last time I was up here.

With airlines prices being what they are, and anticipating having to rent a car, I decided to drive up instead of flying.  I actually looked into train tickets, but was sorely disappointed… it would have taken 2 days, required finding a hotel room in NYC, and booking a connecting train in Canada, and it would still have been the same price as a flight.  Apparently, Amtrak is not only not ramping up their service to meet what you would think is a growing demand for cheap, eco-friendly travel… they are actually removing passenger lines, because the freight industry controls the rails. What a pity… I would like to have taken a train.

As it turned out, though the drive was long (about 13 hours), I didn’t really mind it.  I kind of enjoy road trips.  I loaded my iPod with podcasts and audiobooks; I loved the podcasts so much, I haven’t even gotten to the audiobooks yet.  This is the first time I’ve ever listened to a podcast, and I am definitely going to subscribe to some feeds (I know, I’m behind the times, but I work from home and normally just listen to NPR or music while I’m driving).  The changing leaves were beautiful, too.

On the way back down, I decided to detour to Niagara Falls.  The only other time I was in this area, as I was roadtripping across the States with a friend (on my way to move from Missouri to North Carolina by a very circuitous route), she didn’t want to go to the Falls, and I’ve been wanting to go ever since.  So, I figured, hey, since I’m in the area… But we worked pretty late last night, so I ended up leaving the hotel just before midnight… I was pretty drowsy about half the way to Niagara Falls, so I pulled over and slept in my car in a rest area.  But that gave me a chance to see a bit of Toronto by day;  I detoured from my detour to see the CN Tower and Kensington Market in Toronto, which seems like a nice city… it’s one of the few major Canadian cities I’d never been to before, so I’m glad I did it.

In Niagara Falls, I did the normal tourist thing, strolling along the walkway above the falls, snapping pictures, and taking the Maid of the Mist boat tour that takes you into the deluge under the falls.  I got soaked, naturally, and the roar was deafening. It was pretty fun.  The falls –American Falls and Horseshoe Falls– are pretty impressive, with the rainbows and towering mist and translucent water rushing over the edge.

So, off to dinner, then I’m hitting the road again back home to North Carolina.

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:

1. Editor’s Draft, where ideas are just being hashed out
2. First Public Working Draft, where we have the basic direction, but still in rough form, and are seeking initial public feedback
3. incremental Working Drafts, where the draft spec improves over time, based on review and comments
4. Last Call Working Draft, where we pretty much think it’s done, and ask the public to give it a final once-over
5. 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
6. 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
7. 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!!

Since before the iPhone was released, there was speculation that it would support SVG.  After all, WebKit supports SVG, and Safari is based on WebKit, and the iPhone uses Safari.  But alas, the build of Safari that went on the iPhone did not include SVG support… nor, more famously, did the iPhone support Flash or Silverlight. Rats!

Realistically, it doesn’t make a huge impact in the total deployment of SVG on mobile devices.  For all that they are cool, iPhones make up a pretty small margin of mobile devices.  Opera is probably deployed on more devices, and it’s supported SVG for a while.  SVG is used on the BlackBerry, as I understand.  The BitFlash and Ikivo SVG players are deployed on something like half a billion phones, both for content viewing and as the GUI of the device itself.  But… still, having it on the iPhone would be a bit of a coup, and would enable lots of neato Webapps.

And as of yesterday, when I updated the firmware on my iPod Touch, SVG is now supported natively!

Read the rest of this entry »

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.

Ian Hickson, who wrote the second ACID test, is now working on ACID3. He recently started a contest to get contributions from the community on what features they want tested.

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).

Well, today is my birthday, so I’m giving you all a present. I’m finally releasing my Grafox extension, which extends Firefox’s native SVG functionality. I’ve gotten quite a lot of requests for this, which strikes me as odd, since I haven’t promoted it much at all. I’ll also note that Holger Will also has a Zoom & Pan extension that is quite good.

Grafox adds zoom and pan controls, and support for text-wrapping, editable text, and declarative animation, among other things. And at this stage, it adds them all badly. I’m releasing it now not because it’s stable (in fact, it was more stable a few versions ago), but because it’s unlikely to get stable bit-rotting on my harddrive, and I’ll be more inspired if I have an audience. I’m also releasing it as an open source project, in a sense… anyone can take any piece of it they need, and more importantly, anyone can submit patches or feature requests. I’m hoping that by the time Firefox 3.0 hits the wire, Grafox will be stable and functional.

The permanent home for it will be on my Grafox page. Try it out, and let me know what you think.