How the w3c invented the ‘semantics’ logo

Today the w3c launched an HTML5 logo, that includes sub-logos for different technologies included in or associated with the standard. Here's my parodic view of how the semantics one was made:

Jeremy is upset that they're using 'HTML5' to include CSS3, SVG, WOFF too. I've seen SVG and CSS3 versions of the logo - who's got a WOFF one?

Update: I made a version of the logo in HTML only for the purists.

Audio, Video, HTML5 and standards

The chaps at Mozilla, Christopher Blizzard and Robert O'Callahan reopened the HTML5 <audio> and <video> debate yesterday, with a spirited defence of their decision to support only the patent-unencumbered* Ogg format and Vorbis and Theora codecs in Firefox releases as part of their HTML5 support.

Now, I understand their motives here - back when I was at Apple, I spent a big chunk of time trying get permission to add support for Vorbis to QuickTime, but didn't manage to get it past Apple management's fears. However, all the browsers I use now claim to support HTML5 <audio> and <video>, so I thought I'd try it out. I made some simple test pages using mp3, .au and WAV files, to see how they were supported.

What I found was a bit disappointing - it seems that the way that the spec is written, you can support <audio> but no file formats or codecs at all (my Droid does this), and if you can't play the file you're not supposed to show the fallback HTML contents

This means that Firefox, Droid won't show the link to the audio file below:

though browsers that don't support <audio> at all will. Here's the markup:
<audio src="http://homepage.mac.com/kevinmarks/dystopia.mp3" controls><a href="http://homepage.mac.com/kevinmarks/dystopia.mp3" type="audio/mpeg"> Looking Up From Dystopia </a></audio>

However, if I use a direct link or an embedded <iframe>, Firefox will use available plugins to play the file (both Flash and QuickTime happily play mp3's). Thus using <audio> give me less compatibility with current browsers.

On phone browsers, odder things happen - iPhone gives a clickable button for the <audio>, but auto-loads an <iframe>; Droid ignroes iFrames, Palm Pre doesn't have <audio> but <iframe> behaves like the iPhone.

Smarter behaviour with declarative audio would be nice here.

*Submarine patent trolls keeping periscopes down may exist.

An API is a bespoke suit, a standard is a t-shirt

Brad is calling for APIs, and even the NYT is proposing one, but there is a problem with APIs that goes beyond Dave's concern about availability.

When a site designs an API, what they usually do is take their internal data model and expose every nook and cranny in it in great detail. Obviously, this fits their view of the world, or they wouldn't have built it that way, so they want to share this with everyone. In one way this is like the form-fitting lycra that weekend cyclists are so enamoured of, but working with such APIs is like being a bespoke tailor - you have to measure them carefully, and cut your code exactly right to fit in with their shapes, and the effort is the same for every site you have to deal with (you get more skilled at it over time, but it is a craft nonetheless).

Conversely, when a site adopts a standard format for expressing their data, or how to interact with it, you can put your code together once, try it out on some conformance tests, and be sure it will work across a wide range of different sites - it's like designing a t-shirt for threadless instead.

Putting together such standards, like HTML5, OpenID, OAuth or OpenSocial or, for Dave's example of reviews, hReview, takes more thought and reflection than just replicating your own internal data structures, but the payoff is that implementations can interoperate without knowing of each others' existence, let alone having to have a business relationship.

I had this experience at work recently, when the developers of the Korean Social network idtail visited. I was expecting to talk to them about implementing OpenSocial on their site, but they said they had already implemented an OpenSocial container and apps using OpenID login, and built their own developer site for Korean OpenSocial developers from reading the specification docs.

I'm looking forward to more 'aha' moments like that this week at I/O.