Reinventing Fire

I’m really excited about W3C’s new public Audio Incubator Group, just launched today, and open for collaborators, innovators, and instigators. Go take a look for yourself, and see if you can contribute.

To celebrate the occasion, here’s a simple example of an experimental audio inteface, in the world’s first (and worst) audio synthesizer in SVG (you’ll need a special Minefield build to use it). Just click on the keyboard… it’s pretty rough still, but it shows some of the potential:

(standalone SVG file)

For some background, read on after this break…
Read the rest of this entry »

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 »

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 »

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?

Last year, I noticed that my blog had lost all its styling… I was busy with other things at the time, preparing for my presentation at WWW2008 (and my subsequent vacation in China), juggling cats, and so forth, so I didn’t really fret about it. I thought it was probably just my host temporarily flaking out.

But when I futzed around with it, I noticed that if I changed themes, the styling came back. Hmmm. But again, didn’t think much of it. Well, it had been hacked, and hacked good. I rebuilt the theme from scratch, and that seemed to fix it (the hacker had injected some hundreds of fascinating links inside the header and footer templates). But for some reason, nobody could leave comments anymore, and some of my posts had disappeared. Days turned into weeks turned into months… and Google let me know that my site was still hacked in some mysterious manner that honestly doesn’t interest me much, but which had a pragmatic downside: they removed my site from their index. Simple fix, they said: just uninstall your site and start from scratch.

For a while, I just put my excess energy into my twits (other people may have “tweets”, but mine are so inane I think “twits” is more appropriate). But I had a hankering to blog again, so I finally put a few uninterrupted minutes together and un- and re-installed my blog software, exporting and importing my history. Maybe this will fix it? Only the Shadow knows…

But at least comments seem to work again, and over the next few weeks, I may play around with new themes and other adjustments.

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>

Firefox is my browser of choice. I really like Opera, and it has excellent SVG support, but I’m a creature of habit, and I can’t shake using Firefox. One of my favorite things about it is that you can trick it out to fit how you use it. I’ve installed quite a few Extensions (community-made bits of browser functionality) that I use all the time. They have become such a part of my browsing experience that I have even forgotten they aren’t standard, and when I had a hard-drive crash and had to reinstall, I was a bit at a loss why FF didn’t have some of the core functionality I’d come to rely on… until I reinstalled the extensions. I’ve even made one for my last employer, and in my spare time, I’ve been working on an image- and SVG-specific extension for Firefox, which I’ll be releasing shortly.

One of the other things I love about FF is the context-menu option for “View Selection Source”. I use it to figure out how certain bits of a document are marked up (though I also use Firebug for that). In my standards work, I also find myself needing to cite particular sections of large documents, such as technical specifications or documentation. I cite them to point out errors, to show where a bit of functionality is specified, to help out people with questions by pointing them to a reference, to defend my interpretation of a technical issue, and all sorts of other geekademic occasions. Since these documents are usually quite long, it’s necessary to get as close as possible to the relevant section when supplying a link, and fortunately, specifications tend to be very well marked-up, with logical document structure and plenty of ID attributes for ease of linking. View Selection Source is really great for that, because I can select a section header, open up the partial source in a new window, find the id, select it, append it to the original URL preceded by an octothorpe (“#”), and use that as a reference link; of course, sometimes the id isn’t where you expected it to be, and you need to look around for it a bit…

Okay, you see my problem. As relatively easy as View Selection Source makes the task, it’s still a bit… shall we say, labor-intensive. To be honest, it’s not quite as cumbersome as it sounds, and I’m so used to having to kluge around like that when programming that it somehow never occurred to me that it could be easier.

It just got easier. I spent a few hours putting together a Firefox Extension that automates this process. You just right-click on the section you want to link to, and select “Copy section link”. Idiri, my extension, automagically finds the nearest preceding link to where you’ve clicked, and copies it to your clipboard. It also highlights the element that it found an id on, as a visual indicator that it’s done its job and to let you know where you’ll be linking to. Simple.

You can download Idiri (from “id” for identifier, and “iri” for “internationalized resource identifier”, a fancy way to say URL or Web address), and let me know what you think. More details below…

Read the rest of this entry »

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

I was sitting at the bar with Chaals and Danny Ayers (who I’d previously only known through mutual friends and by reputation) at the Fairmont Springs at lunch. He’s an RDF guy, and I put to him the question I’d put to Harry Halpin last night (while watching Super Troopers); Harry likes the loose structure of microformats (though he acknowledges the utility of established ontolologies for constrained domains like medicine and physics), and I wondered if maybe the linguistic model of exemplars would be useful in RDF and OWL to add some flexibility.

But if formal ontologies are too rigid, I think microformats is too loose. It’s great that people are tagging their content, and useful things can be done with these tags in the short term. But microformats is not immune to language drift. Someone will see a tag, misgrok the meaning from context, and idiosyncratically misapply it to other content. This is exacerbated by the international and multi-language nature of the Web.

For example, let’s say that someone had tagged some content with the word “meme” 15 years ago; it would clearly have referred to Dawkin’s model of “idea evolution” (where a concept is spread not through accuracy, but through adaption to its mental environment… an idea akin to Colbert’s “truthiness”). But a few years ago, it spread into common use as a synonym for “fad”; so far, it retains some superficial similarity to Dawkin’s idea. In a few more years, it will probably be a very dated word (like “groovy”) and may well shift to a meaning like “old-fashioned”; it would then have completely lost its essential meaning. So, a diagram of Dawkin’s model tagged “meme” would then be misinterpreted, misindexed, and regarded with confusion by a future reader.

In the long haul, RDF provides a more time-proof solution by providing conceptual context, not just a cluster of words.

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.