Korzybski remarked that “the map is not the territory”, reminding us that we shouldn’t confuse our mental models for reality. But maps, and data visualizations of all kinds, are really powerful, conveying complex ideas easily, and even shaping (or misshaping) perceptions about facts. This is one reason why decentralization of mapping resources and services is good; no one organization should control our common maps.
SVG is a natural fit for mapping. There’s even a detailed proposal by KDDI’s Satoru Takagi-sensei for tiling, layering, and coordinate resolution that fits on top of SVG, which I’d like to see standardized.
I’ve had an idea for a small open-source project for a while, which I’ve discussed with the brilliant Andreas Neumann of Carto.net; he’s been too busy planning SVG Open every year to help out with it thus far, and I don’t have the skills to do it without a great investment in time. Read the rest of this entry »
SVG paths have a pretty good set of shape commands, enough to let you draw any 2D shape you might want in an authoring tool: horizontal, vertical, and diagonal straight lines, elliptical arc segments, and cubic and quadratic Bézier curves. Béziers are great, giving you precise control over the position and curve interpolation of each point in a concise format, using control points (“handles”), and are easily chained together to create complex shapes.
But let’s say you have a series of points, and you want to draw a smooth line between them, e.g. for stock data, an audio wave, or a mathematical graphing equation. Béziers are not as handy there, because not all the points needed to define a Bézier spline are on the curve itself. Obviously, you can decompose any set of points into a set of Béziers, but that takes math, and who wants to do that? (Put your hand down, nerd. I’m talking to the normals.)
Sometimes, you just want to lay down a set of points, and let the browser draw a smooth curve (unlike polylines, where each segment is just a straight line between the points). Like this:
Recently, a browser implementer asked me for examples of SVG. He was having trouble finding good examples of SVG in use, particularly as parts of an HTML document. This question has come up again and again, actually, and it always vexes me. I’ve been active in the SVG community for close to a decade, and I’ve seen thousands of amazing SVG files (and many more of mediocre to average quality), but somehow they seem to have disappeared or bitrotted over the years. Some of those files only worked with the slightly-unstandard Adobe SVG Viewer, or didn’t quite work with Firefox’s incomplete support, I know, but surely not all of them. Where is all the great SVG content I remember, the games and GUIs and design and development? Where are all those files to be found?
I hear some browser implementers say that people just don’t use SVG. Intuitively, this feels false to me, based on my own experience. But could it be true?
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:
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.
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…
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!
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!!
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!
