I have Libertarian friends who think Ron Paul has a chance at the GOP nomination… My intuition is that they are engaging in wishful thinking. My best guess is Romney will take it, but I’m hoping for Cain, for 2 reasons:

1. It would be kind of awesome to have 2 black candidates for President of the United States; and
2. I like the idea of Obama going up against McCain and then Cain… it would confuse future schoolchildren.

But should my guess prove correct, and Paul lose the Republican nomination, where would that leave him? He’s garnered quite a lot of support in some polls, and that might encourage him enough to consider splitting off again to run as an independent. After all, he is 76 years old, and may not have that many more chances to run (though he’s pretty spry), so he may as well throw it all in the ring for 2012. (Why independent and not Libertarian? He’s already got the Libertarian vote, and independent status might get him a few people who wouldn’t vote strict Libertarian… it’s a safer label.)

I would love this.

It would split the conservative vote between the Republican nominee (let’s say Romney) and Paul, and hand another term to Obama. It’s not that I think Obama is perfect, far from it; he’s too conservative or moderate for my taste, and I don’t like his persisting in these ridiculous wars, failing to revoke the expansion of Presidential powers, re-signing the PATRIOT act, failing to hold banks accountable, and many other weak moves. But I still support him in general, and I think he’s doing a pretty good job under very trying circumstances not of his making. I support Obama’s jobs bill, and raising taxes on millionaires; I even support him raising taxes on me, and I’m solidly middle class. And I think we need another Obama term to see his efforts really bear fruit, and to give the economy a chance to recover.

But that’s not what excites me about the idea of a Ron Paul schism from the GOP. With his seeming popularity among an increasing number of people, and the coming ugly break-up of the Tea Party and Republicans, and similar disillusionment on the left, it might increase the dissatisfaction with our two-party duopoly, and pave the way for voting reform where it is easier for multiple parties to credibly run for President.

The current system is a crock, where no matter if a Republican or a Democrat wins, the Republicans and Democrats win, and both parties have too much incentive to keep this convenient arrangement that neither will work to reform it, and neither will stray too far from the policies of the other. This race to the bottom is driving us away from real issues and further and further to the right (which is not right).

The simple fact of the matter is that a country of over 300,000,000 people must by necessity have more than 2 opinions on any given subject, so 2 parties can’t really represent their views with any degree of accuracy or subtlety. So, as a result, the “national dialog” consists of hand-picked non-topics that are blown out of proportion by the media, because that’s the only thing that the established parties will discuss. We need more diversity of voices in Washington; for that, I appreciate Ron Paul actually having the nerve to say things that push the boundaries of what Republican voters might want to hear (even if I think his particular stances are nonsensical sophistry or cynical manipulations).

And worse yet, this false black-or-white, uncompromising, your-team-vs-my-team bullshit isn’t just wasting our time and money, it’s actively driving a wedge between Americans, radically polarizing us into knee-jerk offense and defense, resulting in a fruitless stalemate. When I talk one-on-one to self-identifying Republicans, and get past the rhetoric to the real issues and real values, I usually find we think fairly similarly… we mostly disagree on execution of those ideas, and on personalities of the politicians; but I know that once we leave that personal, human conversation, the media machine will hammer at us relentlessly until we forget that point of similarity and solidarity. We too easily devolve into slogans and talking points, reaction against the banality of the opposing politicians’ public statements and stances.

We need more than two political parties, to baffle that echo chamber. We need new voices diverging and disagreeing, then coming to compromise, then pushing new ideas into the political arena, and that won’t happen when it’s just two talking heads shouting each other down. But right now, it takes a tremendous effort and a fortune to try to get on the ballot in each state; state-controlled ballot access means that even if a third party could get enough momentum and campaign donations to have a real shot, they blow that money and energy just trying to get on the ballot, while the Democrat and Republican candidates use their money to influence voters directly. This is only one of many reasons why “States’ Rights” advocates are dangerously naive; issues like this, which affect national elections, should be decided at the federal level.

Of course, lowering the bar for additional parties to be on the ballot, as difficult as it might be, is only one step. Even when they are there, the best they can do is deflect votes from one of the other candidates, as Nader did from Gore in 2000, and as I hope Paul does from Romney in 2012 (though honestly, I think could just barely live with Romney as President… just not Paul, Cain, Sanctimonious, Perry, or that one lady with the creepy crazy eyes… no, no, the other one).

What we would also need is the ability for people to make real and direct choices in who they want as President (and for Congress)… not simply pick the lesser of two evils, but rank them according to how well that candidate matches their own preferences, how well each candidate represents that voter’s views. This is nothing new… we’re one of the last first-world nations that still uses the first-past-the-post, winner-takes-all ballot system, when what we need is a more sophisticated ranked voting system, where if your first choice of candidate doesn’t have enough votes to win, your vote is counted instead for your next choice, then on down the line, until one candidate is the candidate that the most people can live with. Then, an alternative party candidate might actually stand a chance of winning… and even if they didn’t, it would disrupt the carefully-controlled unequilibrium that the duopoly enjoys, so we could at least hear those new voices.

But could this happen? Could a national referendum on voting reform actually bloom? Well, I can imagine a scenario where it might. Obama is limited to one more term, and I have a feeling that he’s going to be more aggressive during his last term… he has less to lose. So, he could well support such an effort, on the basis that if a Republican wins in 2016, they will try to dismantle his reforms… so he’s better off trying to widen the field, on the chance that a it would yield a less clear “mandate” for destroying what he had built just to score one more point in political pong.

Right now, the duopoly strategy against us is winning: they divide and conquer. It’s a proven principle that we need to apply the in reverse: we need to divide ourselves into many parties, so we can conquer them.

This is just a simple essay on how I see the world, and how I came to that view, the first in a set of posts I’m labeling philosophy. There’s no real point to it, no political or technical agenda… just some reflection and thinking out loud. I’ve never formally studied philosophy, and I’m sure these thoughts are probably not particularly original, but I arrived at them organically through my own life, in what passes for wisdom. Megan, my wife, laughs at me whenever I start a sentence with “I have a theory…”; apparently, I have a lot of theories. I have an active imagination, and I’m very opinionated; I like to try to figure out how the world works.

The way the mind works fascinates me in particular, and my understandings and beliefs about it have changed and evolved significantly through my adult life. I’m recording these thoughts now for the entertainment of some future me.

Many years back, in my late 20s, I came up with a sort of metaphor for how people talk to one another that I called the Third Person. I reckoned that we don’t really talk to each other at all. I have my model of how you think, and act, and feel, and you have your internal model of me. When I talk to you, when I gauge your reaction and adjust what I’m saying or doing, I’m actually judging my own flawed perception of you, of how I guess that you are reacting; you are doing the same with me. In a very real sense, we are each engaging in internal dialogs.

But really, my model of you is much more me than it is you.

Together, your model of me, and my model of you, act as a collective, composite intermediary for our discussion, for all our interactions: the Third Person. An external entity that is a sort of gestalt synthesis of how each of us tries to understand the other. We each talk to the Third Person, and the Third Person tells us the other’s reply.

Usually, we aren’t even really aware that we aren’t actually talking directly to each other; we’re almost completely taken in by the illusion. The Third Person is a skilled translator.

Functionally, that third person is there to help us communicate, but sometimes it can get in the way. I act differently around different people, and I tend to be relatively consistent with any given person or group… much of that is bound up in past interactions, in expectations of behavior (how I expect you to behave, and how I expect you want me to behave). Those expectations can lead to a much more limited personality than either of us have really developed. The Third Person’s personality is often quite different than my personality and your personality. The Third Person can also accentuate and enhance relationships; it can put us into a frame of mind that we don’t normally use in our day-to-day lives; some of my favorite, most inspiring times are getting together with old friends and having a reunion with our Third Person.

(Just for the record, in case this strikes you as solipsistic or schizophrenic, I do believe in an objective reality; by definition, that which we call reality is reality. But I also believe that that reality is mediated in ways we don’t understand.)

I’ve always been a reader, mostly fiction (sometimes even literature), and in my teens, reading books by Vonnegut and Brautigan and Robert Anton Wilson really shaped how I saw myself and my place in the world. So, it amused me to call my metaphor the Third Person, after the third-person narrative view; it fit well, since it was an omniscient view of a dialog, outside of any of the speakers.

I didn’t really put the metaphor of the Third Person into praxis in my everyday life… it was just an interesting observation, one of hundreds of thoughts that occurred to me, not a way to lead my life. But it resonated with me, and looking back, it was the first tangible seed of one of my central operational beliefs: mental models. I’ll write about that some other time.

This week is our first Geek Week at W3C. The idea is to have a week where we improve our skills, collaborate with each other on prototypes and fun projects that help W3C, and to come up for air from our everyday duties. I’m working on a few projects, some small and some larger.

One of my projects is to make a plugin for Thunderbird, my email client of choice, which exposes the Archived-At email message header field, normally hidden, as a hyperlink. This is useful for W3C work because we often discuss specific email messages during teleconferences (“telcons”), and we want to share links to (or otherwise find or browse to) the message in W3C’s email archives. It’s also handy when you are composing messages and want to drop in links referring to other emails. (I do way too much of both of these.)

I’ve made extensions for Firefox before, but never for Thunderbird, so this was an interesting project for me.

One of the cool (and I think unusual) things that W3C does is to attach an email header field to each message, providing a link back to the place in our archives where the message is stored. This is defined in RFC 5064. These links are very useful, but most email clients don’t do anything with them… you can only see them when you view all the headers, and then you have to hunt for them among the gobbledygook.

I’m in the process of migrating to my new Macbook Air 13″ (hooray!). This is my second Mac (I was a Windows guy before), and I thought I’d take the opportunity to rebuild my setup from scratch, rather than importing my old settings, so I could do some optimizing.

This means that I’m installing and configuring a lot of software (including some updated versions that wouldn’t run on my old Snow Leopard OS), like Thunderbird. Over the years, I’d installed several plugins for Thunderbird, some of which no longer worked. One of those exposed the message headers, but it was a pain to use. I was also able to expose the header by changing the “mailnews.customHeaders” preference in Thunderbird, but that still didn’t give me what I wanted… I had to copy the header manually, < and > bookends and all, and paste it in the browser bar, edit out the delimiters… clumsy. I raised a bug on it a couple years ago, but never got the gumption to do anything about it.

Until now, that is. Now I’ve made an extension to do the grunt work for me (laziness being the true mother of invention). My new extension, Archived Link, exposes the Archived-At email header as a hyperlink, and when you click it, it opens in in your default browser; it also copies it into your clipboard (an option you can change in the preferences).

I cobbled the plugin together from scraps I found around the Web. I borrowed heavily from the framework of the first plugin I found that added a line to the email header message pane, Andrew Van Tassel‘s cool MailHops Thunderbird Plugin.

I also got timely and friendly help from Jonathan Protzenko (protz) and Jim Porter (squib) on Mozilla’s #maildev IRC channel, for which I’m very grateful.

If this seems like something useful to you, please download the Archived Link extension and install it in Thunderbird. Let me know what you think.

Update 1: Screencap

Just to make it more clear what this extension does, I decided to add a screencap:

Update 2: Mozilla Add-Ons App Store

I’ve now submitted Archived Link to Mozilla’s Addons site. It still needs review, but you can find it via the direct link to Archived Link.

There has been a heated argument recently on the W3C Canvas API mailing list between accessibility advocates and browser vendors over a pretty tricky topic: should the Canvas API have graphical “objects” to make it more accessible, or should authors use SVG for that? I think it’s a false dichotomy, and I offer a proposal to suggests a way to improve the accessibility potential of the Canvas 2D API by defining how SVG and the Canvas 2D API can be used together.

This brings together some ideas I’ve had for a while, but with some new aspects. This is still a rough overview, but the technical details don’t seem too daunting to me.

Retained-Mode vs Immediate-Mode Graphics

First, some background…

SVG is a retained-mode graphics format, meaning that each shape persists as a separate object, with distinct characteristics such as location, size (bounding box), and precise outline (stroke). These characteristics can be acted upon within the object structure (DOM) as discrete entities (or groups of entities) for manipulation by script or by user-interface actions (e.g. mouse clicks or keyboard tabbing); one of these interactions may be hit-testing.

The Canvas 2D API is an immediate-mode API, meaning that it allows the programmer to create visual shapes as individual pixels that are unstructured; in other words, if a red circle and a red square are drawn which overlap one another, there is no way to distinguish these from one another, or from the background canvas element (though a programmer could maintain a separate structure in script).

With retained-mode graphics, each object which is added to the DOM increases the memory “weight” of the page or application, potentially slowing down the browser or otherwise decreasing performance; by contrast, immediate-mode graphics, which are not represented as objects in the DOM, do not decrease performance, which is an advantage over retained-mode graphics.

Some accessibility advocates have noted that hit-testing and zooming are critical accessibility features of graphics; this requires the ability to access the location, size, and other characteristics of individual graphics. Unfortunately, adding this retained-mode feature to an immediate-mode API effectively removes the primary advantage of using an immediate-mode graphics system.

However, by defining how SVG and the Canvas 2D API can be used together, a model may be created which allows authors to easily use both together, each for their appropriate strengths. This approach involves two aspects: defining the behavior, and a potential shared API syntax.

Defining Behavior

Currently, the Canvas 2D API is only defined to work with the <canvas> element defined in HTML5, and it does not allow SVG to be drawn or imported into the Canvas. However, it could be extended to work inside SVG or to allow SVG to be used inside Canvas.

Canvas in SVG

At its simplest, the Canvas 2D API could simply be defined to allow authors to draw on the SVG raster <image> element, just as it does in the HTML <canvas> element, but there does not seem to be a reason to limit it to this element. The Canvas API could be defined to draw to any SVG element, rendering or structural, as an overlay. It would be merely a visual effect, and would participate in the rendering structure, including “z-index”, only as its “target element” does.

SVG in Canvas

SVG shapes could be allowed to be imported into the <canvas> drawing context, such that they render there but are also inserted into the DOM or shadow DOM. Currently, as I understand it, this is not allowed for security restrictions involving content from potentially different sources, but for content that does not have external references (for example, a <use> element to another site, this should not be a security risk.

SVG in the Shadow Tree

The accessibility features of the Canvas 2D API include a “shadow tree” and focus ring for those elements, such as text, which are not otherwise accessible to users with limited vision. Each such “graphic piece” which is created and painted to the screen is also represented in this underlying shadow DOM (IIRC).

SVG elements used in conjunction with Canvas could also be placed in this shadow tree, so that navigability is preserved. In order to save memory usage, a concept like the <use> element in SVG could alternative be used to “point to” an SVG in the main DOM from its appropriate place in the shadow tree.

SVG elements could either be used as visual shapes themselves, or could be invisible “hot-spots” for specific areas of the screen.

Common API

I have suggested before that we create a simple graphics API that will allow either 2D Canvas (immediate-mode) or SVG (retained-mode) images with the same set of methods and parameters, with the only difference being which “mode” the author selects to have as the instantiated form. If the author draws a circle to the canvas context, it would simply be drawn to the screen with no structure; if the author draws that same circle to the SVG context, it creates a <circle> element with the appropriate attribute values and style and inserts it into the DOM.

There would be certain differences in some of the renderings, because of the different rendering and compositing models of SVG and Canvas, and there would be certain specialized functionality and features each would have, but the majority of the visual appearance would be the same.

This would allow authors to learn only one API for 2D graphics for the Open Web Platform. With this ease of learning and use, the author could decide on a case-by-case basis, even within the same application, which mode works best. It would provide incentive to authors to use each to its best effect.

I call this approach COG: Common Open Graphics.

Example

An example of the effective use of SVG and Canvas together is a hypothetical game in which the user pilots a spaceship amidst an asteroid field.

The background of the game includes animated nebulae, passing comets, rotating planets and moons, and other visual effects which are not interactive, and which do not affect the play of the game, but which add visual appeal. The foreground of the game (the “playable area”) includes asteroids, enemy ships, and energy beams that the player must dodge or shoot at, which increase in size the closer they get, and which benefit from hit-testing and keyboard focusability. The middle-ground of the game contains many smaller asteroids and ships that are not yet interactive, and so don’t need hit-testing or focusability.

Adding all of these graphics shapes as retained-mode objects in the DOM would unnecessarily increase the memory footprint of the game, degrading performance and playability. However, since only a small number of these elements (those in the playable area) need the retained-mode interactivity, the majority of them could be drawn with immediate-mode characteristics, then when a certain “distance threshold” is reached, changed to interactive SVG elements, perhaps using the same shared API. This preserves the accessibility of the game, while also causing minimal performance degradation, and possibly even helping performance, since the hit-testing doesn’t need to be calculated in script. From an authoring point of view, using the same shared API means that both types of shape, retained-mode and immediate-mode, are equally easy to generate and maintain.

To enhance the visual appearance of the SVG asteroids, the finer control of the Canvas API could even draw an overlay on the SVG stroke and fill areas, much as filters do, to show craters and other surface details in a more fine-grained manner then can be done efficiently in SVG. Since this would be drawn specifically on the SVG element, the element itself would still provide the geometry and position characteristics.

Caveats

This proposal has two caveats:

1. Canvas can only be extended to be as accessible as SVG is, in this model. Even with object retention, there are still many enhancements needed to make SVG truly widely accessible. However, as plans for SVG accessibility improvements are made, these would be largely importable directly into the Canvas API, rather than working in parallel on two unrelated but overlapping graphics models.
2. Simply because the Canvas 2D API may be made more accessible, does not mean that all Canvas API applications or content will be automatically accessible, any more than all HTML or SVG content is accessible. Authors will still need to use best practices and take specific steps to make their applications accessible. This proposal only provides the means and the incentive to do so.

Feedback

I’m interested in feedback on this, either in the comments section of this blog, or on the W3C Canvas mailing list, public-canvas-api@w3.org.

Update

Someone pointed out offlist that this post emphasizes the accessibility aspect of this proposal, because that was the context of the most recent discussion, but this is a win for anyone who wants to do graphics in the browser, for any reason, not just accessibility. Like any good accessibility feature, my proposal has general benefits, so it is more likely to be used in more content. In the example scenario above, the developer gets the hit testing for free, regardless of whether or not Accessibility Technology is involved. Other general advantages include ease of learning and use of graphics by developers (as mentioned above), sharing of features between modes (like using Canvas.toDataURL() to save an SVG as a PNG), pixel operations (like painting or detecting a color at a point) in SVG, metadata (like microdata, RDFa, or microformats) in select parts of a Canvas app, and so on. I’m sure that clever people will come up with a whole boatload of cool things to do with a combined retained-mode/immediate mode API that I couldn’t imagine here.

Anyone who has seen Tim Berners-Lee do any public speaking knows that he speaks very quickly. Too quickly, in fact, for non-native speakers, and some native speakers, to follow along. The words seem to tumble out of him, long after his mind has moved onto the next thing he’s planning to say, and the thing beyond that. W3C’s communications lead will frequently signal him to slow down, and Tim will step down to a slower-than-normal rate of speech and slowly build back up to his own “normal” auctioneer rate.

It’s not a coincidence that he’s one of the creators of the Web. From working with him at W3C these past few years, I’ve observed that his mind does seem to spin at a few cycles faster than the norm. He makes connections quickly, and even when I don’t agree with his conclusions, I admire his ability to grasp situations rapidly, and to revise his opinions progressively as he is given more information. He also shows a remarkable humanist take on topics, not just a technologist take. The Web, for him, was always less about the technologies involved than about the goals that could be accomplished with those tools; technology is necessary but not sufficient, just a means to an end.

And Tim is impatient to get to that end. It’s reflected in his rate of speech. It’s clear from the way he moved on from the solved problem of HTML (including XHTML and HTML5, mere refinements on the basic approach), to the idea of linked open data. People laughed at the Semantic Web a decade ago, and now companies like Google, Yahoo, and Microsoft are scrambling to put their own stamp on it, and governments are deploying it. Once again, Tim was ahead of the game, leading the pack.

On the W3C staff, we laugh about how Tim (or “timbl”, his email shortname and IRC nick) types as quickly as he speaks, with a cornucopia of typos. Sorting out the jumble is left as an exercise to the reader.

Some people can understand the spoken word at an astonishing rate. I once called a blind colleague, who listens to his screen-reading software at treble-speed, and he impatiently told me to speak more quickly. If you’re a seeing (and hearing) person, and you get a chance to listen to a blind person use their screen reader, prepare to be blitzed and dumbfounded. Paragraphs roll by at a modulated buzz, and you’ll be lucky to pick up a word or two; menu navigation is a staccato of half-spoken stutters as familiar items are tripped through like a stone skipping across water. Tim doesn’t speak that fast, thankfully… he speaks just fast enough that you have to listen carefully.

That’s why some of us on the W3C staff have developed a new unit of measurement: the timble. 1 timble is the uppermost rate of speech at which a normal person can understand what’s being said in their native language. On average, I’d guess most people speak in the range of 0.5 to 0.7 timbles; screen-readers are often operated at 2 or even 3 timbles; southerners (I live in North Cackalacky, USA) speak at about 0.4 timbles.

I recently teased TimBL about the timble at dinner in Bilbao, Spain, after he’d given a wonderful presentation at a local Web conference at a very equitable 0.8 timbles. He graciously offered an alternate definition: speech at more than 1 timble is difficult to understand; speech below 1 timble is simply boring.

Offered without comment.

Post about HTML5 logo and overblown “controversy” surrounding it:
1,078 hits on the first day.

Post about details on W3C touch events spec, including a roadmap and future plans:
273 hits on the first day.

Last week, I published the first draft (and subsequent updates) of the Web Interface specification, which defines touch events. This is the first spec from the new W3C Web Events Working Group.

Peter-Paul Koch (PPK) gave it a positive initial review. Apparently, others thought it was news-worthy as well, because there were a few nice write-ups in various tech sites. Naturally, cnet’s Shank scooped it first (he has his ear to the ground), and it was fairly quickly picked up by macgasm, electronista, and Wired webmonkey.

I thought I’d go into a few of the high-level technical details and future plans for those who are interested.

Touch interfaces are nothing novel, nor is using them with Web content, but there are enough differences from mouse interaction that specifying them should lead to easier development and better user experiences on the Open Web platform (or in HTML5 webapps, if you prefer that buzzword).

The most important thing to note for multi-touch events (using more than one finger, say) is that you want the different touch-points to be considered together, not as completely unrelated events. The WebKit implementation, used in the iPhone and Droid smartphones, as well as many, many others, used a good model for this, with each event exposing lists of currently-active individual touch-points; with wide deployment of WebKit already, it was an obvious starting point. PPK’s blog post was off on one minor detail here: while I did base the spec on WebKit’s behavior, I didn’t base it directly off of Apple’s documentation; I wrote it from scratch, for better or worse, and extended it for broader applicability.

One of these extensions was to take PPK’s suggestion to add ‘touchenter’ and ‘touchleave’ events, the equivalent of the ‘mouseenter’ and ‘mouseleave’ events that we finally specified in DOM3 Events, which work much more intuitively than ‘mouseover’ and ‘mouseout’.

I also extended the WebKit model to add ‘radiusX’ and ‘radiusY’ attributes, to indicate the general size and shape of the thing that touched the surface… say, a fingertip or a stylus (a fancy way of saying “pen-like stick”), described as an ellipse. I’ve been soliciting use cases and requirements for a couple of years, and this is meant to cover a similar request across different devices.

That leads me to mention the other use case for this specification: pen-tablets. Almost a decade ago, I was writing a browser-based SVG editor called SVG-Whiz (long since decomposed into digital fertilizer), and I wanted to be able to use my Wacom tablet with it. It worked okay as a mouse replacement, but I had to choose the stroke-width manually… I couldn’t use the tablet’s built-in pressure sensitivity.

We’re about to change that. Another change to the WebKit model is the addition of a ‘force’ attribute to indicate the level of pressure used on the touch or tablet interface. This will be useful for SVG or Canvas API drawing apps, games, and myriad other purposes. For example, most touch screens don’t have the capability to detect hovering (some capacitive screens being the exception)… this is a challenge for accessibility, but perhaps the pressure sensitivity—expressed in the ‘force’ attribute—could be applied to that end. We may specify a new related CSS mode, or simply define when existing ones apply, such as triggering the CSS ‘:hover’ pseudoclass past a certain pressure threshold (device-specific and user configurable, of course).

(On the subject of new CSS properties, Nokia has made the suggestion of haptic feedback properties for touchscreens, based on their implementation. This could be a very interesting addition to touch interfaces, even if it’s not available on all devices. That work would be handled by the CSS Working Group.)

In addition to pressure-sensitivity, pen input has other characteristics that distinguish it from touch, including the angle of the pen, so we may add that as well. Pen-inputs, either through tablets or stand-alone digital pens, often include particular mode-shifting buttons, so we have added attributes to detect when the alt, shift, and control keys (or buttons) have been pressed.

So, to cover a wide range of devices, we will be defining some capabilities beyond basic touchscreens: multi-touch, touch area, force, perhaps pen-angle, and even haptic feedback. Not every feature will be available for every device, but they will be useful for those that do, but we want the spec to be future-proof and device-independent.

This leads me to another touchy area: gestures. One of the common requests I’ve gotten is to add events for specific gestures, like pinch, swipe, twist, flick, etc. There are two problems with trying to standardize this right now:

1. Each device and each platform has its own gestures, sometimes several to do the same thing, and there is still room for innovation there;
2. It’s a patent minefield.

Instead, we intend to specify higher-level “intentional” events, like zooming in or out, panning, navigating, editing, etc., and define a way to map between the physical actions (touching the screen and moving your fingers) and the intention event (zooming in); it also means we can map between input on other devices, like keyboard and mouse, and the intent behind those actions. An additional aspect of this is another proposal by Nokia, the transform action events; these match the transforms in SVG and CSS, such as translateX and translateY, scale, and rotate, and add the ability to detect the rate of the actions. Having all these high-level events will ultimately make it much easier to author content and applications that work on multiple devices.

And though gestures are different on each device, we do plan to create an informative document detailing some common ones, perhaps something like the excellent Touch Gesture Reference Guide by Luke Wroblewski, Craig Villamor, and Dan Willis. That might eventually lead to some industry consensus about future efforts to define gesture events.

Last but not least, one of the additions I made to the spec after the first draft was to add my co-editors, Sangwhan Moon from Opera and Matt Brubeck from Mozilla, both of whom have already made excellent suggestions we’ve integrated into the spec, and who have volunteered to help me write the spec. It’s a positive sign that we’ve got active participation from so many different browser-engine developers, since interoperability here is the most important thing.

For me, this specification has been about a decade in the making… it’s one of the things I wanted to tackle when I first came to W3C, even before I worked there. So, I’m very excited to finally be doing it, and to help make touchscreens and pen-tablets part of the Open Web platform. With some hard work and a little luck, we could get this spec completed and implemented in browsers by early next year.

So, if you are interested in helping us make sure the Touch Interface spec meets your needs as a user, developer, or implementer… get in touch!

I was involved in rolling out the new HTML5 logo for W3C; I wasn’t the person in charge, but I helped out with some aspects of it.

The interesting thing to me was the reaction to the logo, aesthetics aside. (I like the logo personally, but I also like the retro-futurism of Soviet Realist art, like the statuary in Memento Park in Budapest, and comic books.) I loved the parodies and jokes about the logo, but I was both unsurprised and disappointed at the some of the negative dialog (and in some cases, monolog) about what the logo is meant to represent.

Just like the Gap and Starbucks logos, there were going to be some people who would be unhappy because that’s what makes them happy. There would be no pleasing them, and it’s senseless to try.

But there was another set of people that we really value, and we wanted to make sure that they were comfortable with the logo: the perfectionists. As you can imagine, it’s not the easiest group to please, but they are the ones who make standards work, by reviewing the specs to make sure there are as few errors as possible, by creating exacting tests to ensure interoperability between browsers, and by teaching web developers the precision of terminology and best practices that lead to high-quality web sites and webapps… usually on a volunteer basis.

These are our people, and we wanted to please them. But at the same time, a logo has to serve lots of different communities… including managers and clients who don’t know or care that there is an “HTML5 specification” (whatever that might be), and people throwing around the word “HTML5” like it’s birdseed at a geek wedding. Even people who know better use “HTML5” as shorthand for “Finally, browsers are doing all this cool stuff I want to play with! WHEEEE!”

So, how do you strike a balance between people who want us to say, “This logo is for the HTML5 specification only, and we will sue anyone who puts it on a site that uses HTML4.01+CSS3” and those who want us to give them the shiny and shut up? You make an “identity system” which includes sub-icons for specific technologies and general technology classes, and you say that the identity system, in toto, represents HTML5 and the peripherally-related technologies like CSS3, SVG, WOFF, Geolocation, etc.

And how do you screw it up? You oversimplify in the FAQ and use the word “logo” instead of “identity system”, and let people infer that the main logo, the one for HTML5, is meant to represent not only HTML5, but CSS3 as well. (Interestingly, some of the more vocal people who complained on Twitter don’t mind the geolocation API or SVG being conflated with HTML5 nearly so much as CSS3… that seems too fine a distinction to me.)

But we knew we would make some mistakes. We went out of our way to explain to people that we were not trying to shove it down their throats… that we wanted to have a community conversation about it.

Once we had something we thought was ready to share, we released it to the public, rather in a rush. We took to email, to Twitter, and to blog posts and comments, to collect feedback and clarify our message. Turns out 140 characters is not enough to convey much nuance. After a couple of days of seeing if the message was clear enough, giving people a chance to have a second look and see if the idea of a “logo system” stuck, we decided it wasn’t good enough. We updated the FAQ to split out the HTML5 logo from the sub-icons. That seemed clearer to people, though it’s really saying the same thing in a different way… but the way you say something matters.

And that’s my point, here: The way you say something matters.

W3C started the conversation about the logo by clearly stating, and reinforcing consistently, that we were interested in feedback and we were listening to what people were saying. Sometimes people didn’t believe us, but we were. (And I sincerely appreciate Jeremy Keith taking the trouble to explain what was frustrating him about the “logo / identity system”.)

But some people didn’t hear that we were listening, because they were too busy shouting. Shouting things like “Fire W3C Communications Person Who Led Messaging”… I’m not the person that’s targeted at, but I found it a rude and mean-spirited thing to say nevertheless. (Pet peeve: I can’t stand when people make a public rant in a post and don’t allow others to comment on it… it demonstrates a certain lack of accountability.) Tantek Çelik has been in Web standards for a long while, and knows exactly who the (overworked) Comm person is whose job he was calling for, and I think that’s irresponsible.

Tantek compounded this with a tweet that somehow manages to pretend that W3C wasn’t listening, but all the shouting forced us to change our FAQ, then goes on to say in his next blog post:

Yet with W3C’s first draft HTML5 FAQ, we almost gave up. Almost. But apparently sometimes angry rants can effect change. Sometimes passion works.

Within 24 hours of the last of our posts, W3C updated the FAQ, removed the errant entry, added more clarification

You know what also works? Having a calm conversation, reading the FAQ carefully and seeing where a mistaken impression (or even an outright mistake) might have been made, and making suggestions to the people who have invited you to share your thoughts.

Folks, you didn’t need to get angry. Yes, there was some ambiguity in the FAQ, and that was a mistake… one we were sorry to make and happy to correct, only a couple days after the logo was released. But the result of all the shouting was that, several days later, I’m still talking to people who think that W3C is sending this mixed message with this logo, because that’s what everyone was shouting about… and all the clarifications and updates now aren’t going to put that spilled milk back in the glass, since you sent out the cry to arms. A few simple words and a modicum of patience and trust would have served your cause—the precision we all value—much better.

W3C went out of our way to give you a voice. You’re long-time contributors to standards. You’re all insiders… use your inside voice.

Last week, Megan and I went to the opening ceremony of the first electric vehicle charging station in North Carolina, on the corner of W. Hargett and Dawson in Raleigh.

Megan wrote up a short blog post about it, and we talked about what this might mean for the future of our national infrastructure.

We have a Prius, so if we got an electric car (I like the Nissan Leaf, and not just because they use SVG on their site), we would probably use the hybrid for longer trips, so we could refuel easily. But in 10 years, that might change. Since it takes around half an hour to fully charge modern electric cars using the class 3 charger (the heavy-duty one), and 4-6 hours using a class 2 charger, electric road-trippers will need something to do while they wait. Megan mentions this in her blog:

Would owners of this type of business be motivated to install charging stations as a way to attract customers and hold them captive while their car is charging?

I could see a whole new class of businesses that cater to waiting customers, that charge the charging, so to speak: movie theaters, theme parks, mini-zoos, gaming parlors (multiplayer videogames or casinos or both), strolling gardens… activities that emphasize a more leisurely pace of travel. The return of the roadside attraction!

Here’s to the retro-future!

Text in SVG is text. Visually, you can use webfonts like WOFF or SVG Fonts (where they are supported, like in Opera or the iPhone) to make it look cool, and you can style both the stroke and fill to make it all fancy, or apply filters to pop it out or make it glow or give it a dropshadow, but it’s not just a raster image like many text headers… it’s human- and machine-readable text, as nature intended.

So, SVG is translatable, right?

I wanted to make that point in my talk yesterday at Web Directions East, here in Tokyo, so I thought I’d translate my slide on text in SVG
in real time (note: click the down arrow to step through the bullet points). But testing it beforehand (I’m glad I did some prep), neither Google nor Bing even try to translate it. Yahoo’s Babel Fish at least returns the original page, though it doesn’t take the extra little step of doing any actual translation.

Lame.

Why don’t they translate it? Bing offers this helpful explanation:

What text formats are supported?
Html and Text. The viewer will not translate text on images, in PDFs, or in Flash graphics and animation. It may also not translate some dynamically generated text, such as in cascading menus.

I expected this to work, since Google now indexes SVG; as I mentioned in a previous blog post, I made a test page back in 2002 that sorta conflated the two services, indexing and translating. But obviously, these are two different tools, and need to be fixed separately.

It would be easy to fix, I’d expect… simply add SVG to the list of allowed file types, and translate the text content of each element, just as they do with HTML. If they actually special-case different element types, that would add slightly more work, but not a lot… just as with the task of indexing, you would pay attention to the content of the <text>, <tspan>, <textPath>, <title>, and <desc> elements.

It’s ironic that this doesn’t work, because on my way back from Lyon last week, I happened to meet Bert Esselink, the author of a book on localization who works for the translation company Lionbridge, and he and I chatted about how they use SVG extensively for their translation work.

In the end, I just had a native speaker translate a couple of text passages (the automatic translations were apparently not very good) and included them in my slide, just to serve as a placeholder. But I’m hopeful that soon I can demo the automatic translation live. It would be especially useful to people looking at SVG infographics, to be able to see charts and graphs in their native tongue.