Reinventing Fire

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

A while back, Henri Sivonen stumbled upon a diagram on the W3C site of the technology stack, a curvy-block Venn-diagram overview of the different technologies from W3C and where they fit into the Big Picture.  It’s an attractive diagram, but it oversimplifies things, and shows a decidedly W3C bias toward the Web.  It’s clearly been used past its expiration date, and those who consume it might feel a bit queasy.

Henri strongly criticized this depiction.  He rightfully points out that HTML is not included in this vision (showing XHTML only, which looks a bit silly these days), but then complains that HTML5 and XHR are not included in the diagram.  But of course, HTML5 isn’t even in Last Call yet, much less a W3C Recommendation, so it doesn’t really belong in that particular diagram (oddly, Henri credits XMLHTTPRequest to WHATWG, rather than its originator, Microsoft).

To his credit, Henri put his money where his mouth is, and took the trouble to make a diagram of the Web stack the way he sees it, which presumably better reflects the “real Web”.  It omits many of the W3C technologies, and inserts some of the more common ones that aren’t from W3C (most notably Javascript).  It’s a good diagram, but oversimplifies the landscape dramatically.  He follows the W3C diagram in putting “Internet” at the base of the stack, but doesn’t correct it to include such ubiquitous technologies as email or chat (XMPP, IRC, etc.) even though those are often part of browser-based technologies (GMail, et al).  Of course, he deliberately omits intranets-connected devices, even though that’s part of the browser world, because the official doctrine of the WHATWG is that the intranets (including those that are partly open, such as at universities) are “not the Web”.  I will also quibble that he overlaps Accessibility only with HTML, not with SVG.  But most glaringly, he includes Ogg Vorbis and Ogg Theora, though they aren’t (yet!) really used on the Web, and omits the dominant technologies in that space, MP3 and Flash (and more specifically, H.264).  He covers himself here by saying that this is for a “contemporary browser”, with the insinuation that it doesn’t include plugins, though to users and authors that is a pale distinction.  He also neglects PDF (ISO 32000), which is all too prevalent on the Web, and which several browsers do render (if I recall correctly).  So, it’s not really a picture of the real-world Web stack, either.

The Frames remind us, in their song in “God Bless Mom”:

You’ll see how hard it can be
To keep your side of the deal,
And you’ll see how hard it can be
To keep one foot in the real.

So, his diagram is flawed.  So what?  Why am I picking on it?  I’m not, really… it’s a good diagram, and it serves a certain purpose.  I’m picking on that purpose itself.  Henri was quick to criticize the W3C diagram (on a page where nobody can comment, I note), not because it wasn’t accurate, but because it advanced his agenda to do so (just as the W3C was advancing its agenda by making the original diagram).

Data visualization, like statistics or slogans, has a way of territorializing the map, in a kind of graphical gerrymandering. I’m sure that Henri didn’t mean to make such glaring omissions, but I’m equally sure that the creator of the original W3C diagram didn’t have sinister motives either.  People get busy, and reuse what they have to hand that meets their needs, even when it’s sometimes not quite correct.

I really respect Henri, but what he fails to understand here, or at least to admit, is that different data visualizations are best suited for different audiences and different purposes.  He’s shown a clear bias in his diagram toward depicting the “Open Web Stack” (a bias I have to admit I share) and toward desktop browsers (which I find too narrow), with a Web developer audience.  That’s perfectly cromulent.  But his diagram is not at all suited toward showing the different work going on at W3C, and where it fits in the larger Internet, in an executive summary.  Both the offending W3C diagram and Henri’s own diagram are gross oversimplifications… which is the point of data visualizations.  The map is not the territory.  If I were to make a diagram that encompasses the Web tech landscape, it would include both W3C technologies and technologies from other sources, and code the origins with styling; it would clearly indicate which technologies are open (that is, not proprietary), which are under development and which are stable, and link each node to the definitive resource for that tech; it would not stack them up in a neat little box, but would show the interconnections via lines.  And it would serve a different purpose than either of these other diagrams.

Why was only XHTML included in that W3C diagram, and not HTML?  Wishful thinking.  Say it enough times, and it just might come true, and a picture is worth a thousand words.  We’re all dreaming the Web we want into reality, every day.  I’m tired of the false dichotomy that’s too often drawn between W3C and its members and participants.  How about we lay off the divisive rhetoric?

So, I don’t really pay much attention to my blog, or my site stats, or any of that… probably not nearly as much as I should, given how effective a medium blogs are at promoting ideas in the Web Standards profession.  I tend to write quite a lot, but most of it is emails to various technical mailing lists, especially W3C lists.  I should probably pay more attention to getting ideas out into a broader public sphere, with more diverse comments and feedback, like you can do with a blog.

But not this blog… not right now.  Because this blog is invisible.  If I recall correctly, I had a PageRank of 6, which seems to be moderately respectable.  But since my blog was hacked (maybe because it had a PageRank of 6), no amount of PageRank will help, because Google has cut me off.  So, as I mentioned on my last post, I did all the voodoo, adjusted the bones just so, and asked Google pretty-please won’t they reindex my site.  They replied that they will think about it, in a few weeks (just slightly passive-aggressive in a way only the popular kid can be).  I wonder if my PageRank will emerge intact?

But on the up side, I took the opportunity to clean out my virtual attic.  I took down old content and databases and experimental installations of software, wiped out old user accounts and email addresses, and generally made it easier for me to manage everything.  Installing the latest version of WordPress also gave me the chance to reorganize the sidebar a bit, adding my Twitter feed and removing dead blogroll links (though I need to add some new ones).

I should also try to figure out a way to finally expose an index of all the hundreds of SVG files I have hidden in the back alleys of my site.  Some of them are just experiments, some are examples of best practice, some are fairly cool and elaborate, some are just conformance tests.  I’ve hesitated because some of them are also rather crappy code that was written for the Adobe SVG Viewer, and either doesn’t have a namespace declaration (so it won’t work in modern browsers), or it uses some feature not supported in most browsers.  I’ve now put up an empty placeholder page, just to lay the groundwork.

I’ve also entertained the notion of running an index of my posts to public W3C lists, but out of context, it probably wouldn’t mean anything, and wouldn’t offer more than you could get by just searching the lists manually.  Maybe a weekly summary would be better?  Or maybe no mention of it at all would be most preferable… I think a certain amount of silence from me would do me and the people around me a world of good.

Maybe getting blocked by Google is a good thing after all…

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 »

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!!

On our first day since M arrived, we set out to the Forbidden City, one of the must-sees of Beijing.  In front of the hotel, we bumped into a woman who works for Microsoft in the area of accessibility, and we shared a taxi, then decided to hang out the rest of the day.  She and I had a surprising amount in common, and bored M silly with talk of standards and accessible graphics.  We walked around Tiananmen Square and the Forbidden City, and then took a bicycle rickshaw to the hip lake district for dinner and souvenir shopping.

In the Forbidden City, I rented an audio-tour player, and relayed tidbits to them along the way.  I learned about various measurement devices there (such as a sundial) which were not merely the official standard for the empire (e.g. for time); one of the roles of the Emperor, was as supreme –even divine– authority of Heaven’s standards on Earth.  Perhaps that’s taking it a bit far, but it does emphasize the importance of standards (even arbitrary ones) in making a collection of disparate entities work together, be they formerly independent kingdoms or browsers.  It’s worth noting that even today, despite China’s breadth, it has not four or five time zones, but only one.

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.

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.