Mar 18

Why Open Source is amazing; The story of the Quick Open Bespin feature

Ajax, Bespin, Open Source, Tech No Comments »

Going from hacking away on Bespin before our launch, and now watching it 100% out in the open thanks to open source has been a fascinating transformation. Building a community is so much harder than hacking on code, and very different constraints appear. The past of “get a feature done” is changed to be “make it easy to get features done”. We still have a lot of work to do on extensibility, but it has been fun to see what people have already been able to do.

We have had experienced and junior folks pick up Bespin and help out, and I am trying very hard to strengthen a tough skill… delegation. Instead of picking off some bugs, I try to document them better and explain them so anyone in the community can pick them off. Sometimes it would be easier to hack up a quick fix compared to walking someone through a set of patches. However, that doesn’t meet the goal of getting people fishing away on our code and scratching their itches. Ben, myself, and our team doesn’t scale out to the size of developer tools groups at other huge companies, so we need to do what Mozilla does best….. build honest community. I am having a great time doing just that! The early contributors have been amazing already.

There is one recent experiment that I wanted to share. I was thinking about hacking on a key feature…. the ability to quickly search for and open files. This is the Apple-T feature in Textmate. I use it in the same way that I use Alt/Apple-Tab, or Apple-~ to move around. It is a core way in which I move around my projects. Instead of going right into code, we put together a mockup of how the feature could look:

Then, I spent a bit of time on the general design document itself to explain the feature, both from a use case / design angle, and on the “high level” coding side. I tried hard to give enough detail to explain the feature, while still allowing an implementor the ability to be creative and come up with their own ideas.

A few days later, Julian Viereck (a contributor who has already been incredibly helpful and generous with code) stepped up to the plate to say he would implement this, and in short order with the help of Kevin Dangoor building the server side infrastructure (index to search to find out the file names in this case), they had built a solid first version of the functionality.

It’s phenomenal, and I am so grateful to Julian for putting in time to make it work so well. Not only did he write the feature, but he also create a new Thunderhead component head to allow for moveable windows. Very cool indeed. Here are his thoughts on the implementation:

As described in the DesignDoc Quickopen is a window popping up in the editor to let you choose a file you want to jump to and perform some work on with the editor. This allows you to open a other file without going to the dashboard and back again to the editor => you can stay longer in the editor and have not to reload the whole page just for changing the current file ;) This is a quite important feature when it comes up to work on a “real” project in Bespin as you really stay on the work itself :)

To open Quickopen press ALT + O in the editor.

Quickopen: How it works?

When the user fires up Quickopen the first time it shows a list of the current opened files in the project (quite the same as the Open Session thing in dashboard, but just for the current porject). When tipping a searchkey a request is send to the server and a result list back to the user and displayed.

Kevin did the backend stuff. He says “the server is using a *really* stupid file cache to make searches zippy”. Well, it’s really zippy ;) But here is a list of things I would think that could be improved:

a) the seachindex is not updated at the moment. So once deleted a file, it is still in the seachindex. Try to open this file with Quickopen will cause a strange behavoir. The best solution would be, to have the searchindex in sync with the filesystem, but well, thats maybe a bigger deal. For the moment it would be great to have a command for paver like “paver updateSearch -u <username>”.

b) the search results list also files that cannot be opened by Bespin (e.g. image files…). I would not like to see the backend making a choice which files the user should be able to seen in this result list and which not by certain rules. But I think let the user make that choice is a good point. I’m for example not interessted in the image files BUT also not interessted in all these .py files and these stuff. There should be a new user setting to make this adjustments. But at the moment I have no cloue how this setting has to look like? A regex, or something like “excludeFiles= *\.js|.html|.css” for excluding all files except js-, html- and css-files?

c) the search should remember how often the user picked a certain file from the list and put this file more above in the resultlist.

Other ideas? These is work to be done on the backend. I never wrote one line of python and have not looked really at the backend stuff, so maybe someone else should take over this part :)

But when making so often a switch between the files it also comes up to add other things: the editor should remember the mouse position on the files as the user jumps between them. This makes it easier to continue working on the files. For this I thought about adding a new kind of “settings” that stores such data like mouse positions, window positions and such stuff, but I cannot come up with a name for it.

What do you think?

BUT: There is even more new stuff: th.window!

When implementing the Quickopen window I was thinking: “why is there no such class in th”? Well, there it is: th.window!

th.window brings up a window in the browser, with the same border and window bar as the one used by Quickopen (well, Quickopen uses th.window already, so the Quickopen stuff in quickopen.js is a good starting point to see how to use th.window ;)). Having a th.window class was something Malte asked for and I hope other stuff will provide from this new class as well :)

When creating a new th.window object, a new <div> with a <canvas> is insert. The canvas is used for the th.window::scene, to which is the th.WindowBar added automaticaly as well as the user panel; the place to put in the things that should stand within the window. Some basic functions are added to the window: you can drag them around on the screne, there is a close button within the WindowBar, the window closes automatically the user clicks outside the window (is this prefered in all way, I’m not sure) or press the ESCAPE key, there is a toggle, move and center function. Just the basics, but a good point to build on!

Thanks so much to Julian and the other bright sparks that have made Bespin a fun project to work on. There is so much to be done, but hacking on a tool that you actually use is compelling, so I can’t wait to see more!

Mar 16

Embedding and reusing the Bespin Editor Component

Ajax, Bespin, Open Source, Tech 26 Comments »

From the get go, the Bespin project means a few different things. One of the components is the Bespin Editor component itself. We have already seen people taking that piece and plugging it into their system. For example, the XWiki integration.

The problem is that we (Bespin team) haven’t done a good job at making this reuse as easy as it should be. That has now changed with the edition of the bespin.editor.Component class that tries to wrap up the various parts and pieces that the editor can tie into (settings, toolbars, command lines, server and file access) so you don’t have to think about them.

A common use case will be embedding the editor itself, and having it load up some content, maybe from a container div itself.

I created a sample editor to do just this:

editor component

There is a video of this in action, comically in 2x speed for some reason on Vimeo :)

Since this is a sample, there are things that you can do, that you probably wouldn’t in your case.

To embed the editor component you will be able to simply do this (NOTE: We haven’t deployed this version to production yet, so for now you need to load up Bespin on your own server, sorry!):

<script src=""></script>
    var _editorComponent;
    // Loads and configures the objects that the editor needs
    dojo.addOnLoad(function() {
        _editorComponent = new bespin.editor.Component('editor', {
            syntax: "js",
            loadfromdiv: true
<div id="editor" style="height: 300px; border: 10px solid #ddd; -moz-border-radius: 10px; -webkit-border-radius: 10px;">var foo = "whee";
    function flubber() {
        return "tweeble";

First we read in the embed wrapper code, which relies on Dojo (so Dojo has to be loaded first).

Then we create a component passing in the HTML tag to inject into, and options which in this case tell it to use JavaScript syntax highlighting, and then load up the editor using the value in the div that we are injecting into.

At this point the editor is ready to go. You can focus on the puppy and start typing, but chances are you want to access the editor text at some point (for example, read from it and post it up to a form).

To mimic this, we have a textarea that we can copy contents into (editor.getContent()), and then send it back to the editor (editor.setContent(contents)):

function copyToTextarea() {
    dojo.byId('inandout').value = _editorComponent.getContent();
function copyToEditor() {

The example also shows how you can change settings for the editor via editor.set(key, value).

There are more features we should probably put into the editor, such as automatically syncing to a hidden textarea with an id that you specify (so then a form can just be submitted and the backend gets the right stuf).

What else do we need?

Mar 12

Integrating info from Google Doctype into Bespin

Ajax, Bespin, Tech No Comments »

We have plans for integrating rich documentation and resources with Bespin. One quick hack that I have been meaning to do for awhile just got done finally today.

I created a simple command that lets me type doctype DivElement to get an inline popup with details on a <div>. It looks like this:

Bespin Doctype

Right now you have to know what sections are available, which is laid out for you. There are common patterns in there too, such as: NameOfTag + “Element” (e.g. the DivElement) and the same for *Entity and *Attribute.

In the future I would love to be able to tie search into the system so it is more forgiving, and also other features such as getting this data from a context menu, and more. What would you like to see?

The command is documented here, and to use it in your Bespin, you will need the latest version (as of March 12th) and then you can cmdedit doctype and paste it in:

 * The doctype command takes a section, which is the WikiWordSection 
 * that must be one of the items on this list:
 * It grabs the data and puts it up in an inline popup
 * E.g. doctype DivElement
  name: 'doctype',
  takes: ['section'], // part on the Wiki
  preview: 'grab the doctype info for a section<br><br><em><a href="" target="_blank">See full list</a>',
  completeText: 'can you give me the Doctype wiki section?<br><br><em><a href="" target="_blank">See full list</a>',
  execute: function(self, section) {
      if (!section) section = "Welcome";
      var el = dojo.byId('centerpopup');
      el.innerHTML = "<table width='100%'><tr><td><em>Showing information from <a href=''>Google Doctype</a> for '" + section + "'</em></td><td align='right' style='font-size: smaller; color: #ddd; cursor: pointer'>close popup</a></td></tr></table><div style='background-color: #fff; border: 1px solid #000;'><iframe src='" + section + "?show=content' height='95%' width='100%' border='none' frameborder='0'></iframe></div>"; = "80%"; = "80%";
      dojo.byId("overlay").onclick = el.onclick = function() {

Tabs or Spaces


I am so happy that Ben got to save away my sinister “paddle twaddling” past in his post on tab support in Bespin and how one mistake took down the performance of the editor.

Mar 02

Bespin now learning some art in the Dojo

Ajax, Bespin, Tech with tags: , , 5 Comments »


Roberto Saccon has given the Bespin project a nice gift, by porting the Bespin codebase to Dojo. This was a lot of work and is very much appreciated. The obvious question is going to be “Why did you decide to change from Prototype to Dojo?”

Firstly, Ben and I really like Prototype. I am a Ruby guy, so it feels good to me. I talked about it a bit here, and I will use Prototype in many projects in the future.

The state of Ajax frameworks is quite interesting. On the one hand, many of the top dogs have actively learned from each other which has lead to many of them offering similar functionality. For example, Dojo and Prototype can do a good job with DOM selectors, which jQuery is known for.

Although you can do a good job in any of the top libraries, they still differ in scope, and are optimized for certain use cases, project sizes, and functionality wants.

jQuery offers a phenomenal API for doing stuff with the DOM. It feels right. It is also trivial to extend this world, which has lead to the huge number of plugins to do just that. Because of the clean, simple API, we have seen a huge surge in jQuery usage and interest. I would say that it is optimal for designers and beginner JavaScript folk. This is not to say that it isn’t also great for experts. There is large support from folks like Simon Willison. John Resig did something amazing. If you think functional, this will be your cup of tea even above and beyond.

Prototype goes a little further in that it offers more sugar on top of the language itself. Some find the strapping on of methods on core Objects as obscene. Personally, I love it. It just feels so much nicer for me to say array.last() or array.include(thing), compared to dojo.indexOf(array, item) > -1 for example. In fact, looking at a bunch of code has me feeling a touch nuts with all of the “dojo.” items in it. My brain is starting to ignore them.

That being said, Dojo’s purity gives you a lot. It may be more verbose to dojo.byId than $, but we have no namespace pollution.

The community quickly wanted us to package up Bespin in a way that we could share things. We wanted the same, and have natural components (e.g. the Editor, Thunderhead itself), and some didn’t like the leakage of the Editor component requiring Prototype which in turn meant pollution into the global namespaces. With Dojo we can hide away nicely, and can even run a build to become foo instead of dojo if we wanted.

Since the community really wanted it, and someone stepped up and actually did it, we accepted the change. On our codebase it had some interesting side effects. For example, before hand we had Prototype,, and a slew of third party libraries to give us a bit of this, that, and the other. With Dojo, they had everything we were needing and more, so we could hg rm external/ and be done. We are also doing Comet work and the like, and it fits in nicely.

The first change here was to get Bespin working in Dojo, but now we have more work to make sure that:

  • The codebase feels Dojo-y
  • Use more of the Dojo features (e.g. dojo.keys for key handling, CSS store, Comet, …)
  • Clean up and package our stuff nicely (e.g. bespin vs. editor vs. th)

If you are a Dojo fan, or fancy getting into it anyway, please join in! There are a few Prototype things left around, so some of the spirit is there.

A bit of an aside…

A big pain with Ajax and components, is the whole “I really like that jQuery UI component, but I am using Prototype already…. grrr”. Simon Kaegi of IBM has been putting together some thoughts and code around a JavaScript module system that would enable you to say “I want service X which happens to depend on jQuery, and service Y which depends on Prototype.” I am very interested to see where this goes. We sorely need it! The annoying problem on the client is that having multiple libraries is not cheap. On the server though? Not as big a deal potentially.

Jan 20

Why I often prefer Prototype too

Ajax, Tech, Web Frameworks with tags: 9 Comments »


Picture via Dunechaser

I still get asked “what Ajax framework should I use?” frequently indeed. I think that people feel that with my Ajaxian postings I have seen every framework in the world and will have a magic feel for things.

I dread these questions, as context is king for making the decision, and “feel” is a major part of it too. The various frameworks have in many ways come closer together over the years, so making the choice is harder, but also maybe not as big a deal as it once was.

That being said, I really enjoyed Glenn Vanderburg talk about why he prefers Prototype to jQuery. This is the kind of subject that is asking for trouble and foaming at the mouth from people on various camps. Glenn has the kind of nature, wisdom, and touch that makes it hard to think that way. He gives thoughtful points and isn’t trying to cause a stir.

These days, without any real context (e.g. skills on the team, what the project does) I kinda think:

  • jQuery is fantastic for taking a website and making it dynamic. Easy. elegant. Beautiful. If I was a designer doing a rich site I would stop here.
  • Dojo is fantastic for building a large scale application that will do a lot, and end up with a ton of JavaScript. Everything you need will be found there. This isn’t to say that Dojo can’t be used on the small anymore. The new core is small and fast and good.

Prototype, for me, fits in between these worlds. It is small enough to feel small (not a huge library to learn) yet large enough that I don’t jump out into creating a lot of my own code.

On a recent jQuery project that grew fairly big and I found myself surprised that the core didn’t have certain methods and features. Much of it was small things (one example I remember is array utilities). I would find myself looking around for plugins, wondering which ones are good, and generally having a little bit of a tough time. Then there is a the type system. For something that isn’t strapping on a bit of code to the web site, I actually like Class.extend and the like. With jQuery I would use Traits or Base or something which is fine…. but not just there in the same way.

I get used to myArray.last() and having the convenience methods available to me directly on the objects, even if the puritan in me feels a little strange. Just as Ruby “felt right” to me. Prototype does too (duh, since its heritage). A blend of purity and pragmatism. More often than not Prototype surprises me “oh, wow, it has that function already!” On another recent project that got converted to Prototype, I was able to delete a LOT of code. Utility classes went away. Libraries went away. There is nothing better than the feeling of deleting code. Am I right? :)

So, I agree with Glenn. For me, Prototype is the right balance for many of my projects. I still enjoy playing and using others when the project calls for them, and I am ignoring the huge number of other great frameworks (YUI, GWT, MooTools, Ext, SproutCore, Cappucino, man I could go on forever here).

Jan 02

Loving Ubiquity; Extending the Web in 2009

Ajax, Tech, Web Browsing 4 Comments »

I have a project that deals with JavaScript commands that anyone can author, so I decided it would be smart to take more time looking and integrating with Ubiquity which recently got another beautiful upgrade.

Ubiquity really is the “other” command line of the Web (the URL bar being the first one). It gives me Quicksilver like access, but also has huge improvements: Writing plugins is simple JavaScript, and you can subscribe to commands from other people. This is huge. A social command-line!

There is a built in tinyurl command, but I use one these days, so I quickly wrote one:

  name: "trimurl",
  homepage: "",
  author: { name: "Dion Almaer", email: ""},
  license: "ASL",
  description: "Sends your URL to instead of tiny url",
  help: "Just type in the URL!",
  takes: {"url to shorten": noun_arb_text},
  modifiers: {"as": noun_arb_text},
  preview: "Replaces the inputted URL with a URL.",
  execute: function(urlToShorten, mods) {
    var baseUrl = "";
    var params = "?url=" + urlToShorten.text;
    var custom  = mods["as"].text;
    if (custom) {
      params += "&custom=" + custom;
    jQuery.getJSON(baseUrl + params, function(data) {

This chap uses modifiers to allow me to pass in a custom url.

The following said that there will be a url following, and you can optionally say “as customname”:

  takes: {"url to shorten": noun_arb_text},
  modifiers: {"as": noun_arb_text},

I couldn’t find a way to just add to the takes hash, as it would be nice to say:

  takes: {"url to shorten": noun_arb_text, custom: noun_optional_text },

After using Ubiquity for some time now, I am really impressed with how the team is accelerating, and I see this as a great way to extend the Web, and Firefox in 2009.

I find myself in a funny place with the key combos for bringing up Ubiquity and Quicksilver in my mind. I am using Quicksilver less and less (e.g. won’t use it to search the Web or do anything with email) and Ubiquity more and more. As the Open Web takes over the desktop (another prediction;) then Ubiquity will gain usage for me.

Atul has released a preview of Ubiquity 0.2 which has a new architecture and a new Locked-Down Feed Plugin (LDFP).

Dec 31

window.resize firing frequency in browsers

Ajax, Tech, Web Browsing 11 Comments »

I was playing with a Web application that did interesting redrawing of the layout (e.g. needed to do JavaScript magic in the onresize event).

I noticed that in Firefox the event took a fair time to fire. Joel Webber (of GWT fame) has also found this and said:

“Firefox and Opera do this wierd thing where they only fire resize events when you let go of the mouse button, or every second or so while dragging. It’s really irritating because there’s no way to get a “real” resize event, and it makes your ui look crappy when it goes through intermediate wrong-sized states.

I’ve always assumed this was to cover up layout performance issues. WebKit and IE fire resize events immediately.”

I wonder if the layout issue is correct, and if so, it would be nice to be able to somehow say to the browser “yup, I am in control of layout so please fire faster” or maybe by defining onresize you are saying that.

With decorators/annotations you would say:

@FireFrequency(ms=10) window.onresize = function() {
  // ....

Turns out that Ben was being a good citizen and in going to file a bug, found a couple out there.

Oct 28

The Ajax Revolution: From UI responsiveness to functionality and beyond

Ajax, Tech 4 Comments »

In recent presentations, Ben and I have been taking a look back on the rise of Ajax (where Ajax == popularity of dhtml :). At its core, I think it all comes down to UI responsiveness.

When you look at the killer apps such as Google Suggest and Maps, they broke through a set of myths on the Web.

Latency is the killer issue on the Web

We are used to autocomplete in fields and forms these days. However, if you think back to when Google Suggest came out, if someone had asked you whether it was a good idea to do a background request on each key press you may think they were insane. The beauty of suggest is that it broke through and gave great performance. You could do this on the Web.

Rich interactions are not possible on the Web

Again, we are used to applications that allow us to interact with data in a better way. With Google Maps, you feel like you are moving around the map. You are interacting closely with the data. Before hand, we were used to a static view that had us clicking up/down/left/right or zooming around. Every click responds with a wait and a repaint of the entire screen.

This seems crazy. No application framework would ever do a refresh like this, and dhtml broke us out of that box.

This is all pretty obvious, especially when you take a look back at the HCI research on how anything that takes more than a second drives your users batty (and gets them out of the zone). Getting down to 0.1 seconds and your users will feel like they are at one with the app :)

The responsiveness that Ajax gave us opened up the Web for truly useful applications that users could live in without getting frustrated. This bridged us from pages to apps.

We continue to see movement here too. The reason that WorkerPool was added to Gears (Web Workers in the standard) was to give developers the ability to send “work” (run code) to a place that isn’t on the UI thread, which is a big no-no for building any kind of responsive application. As we write bigger and bigger Ajax applications, we end up running more code, which competes more with the browser. Having Web Workers in the browsers natively, and available to those that don’t via Gears, allows us to build compelling applications.

Add to this fast JavaScript (SquirrelFish Extreme, TraceMonkey, V8), and we can get to a happy place with respect to performance.

So, if the original Ajax revolution was about UI responsiveness, where do we go from here?

I think that we have a few directions that we need to go in:


We need to be more productive. We all feel a lot of pain with Web development, even as we get a lot of benefit from the reach and openness. This is pain is the reason that Ben and I are working under a developer tools umbrella at Mozilla. We want to work with the community to become more productive. It is extremely important to do so.

It shouldn’t be hard to put together the hundreds of applications that the Enterprise and beyond spend too much time and money on every day.

We shouldn’t have to fight the browsers to get things working as much as we do today.

Any ideas on what would help you? We are all ears.

Compelling applications

We have spent a lot of time in the weeds talking about the engine of the car. We jump on a point release of some framework, and argue about the minutia of framework differences.

Maybe it is time to pop our heads up a little and think about how we can build compelling, feature rich applications.

The browser is extending to the desktop more, to give you nice full experiences. The real-time Web is kicking off, and Comet will become a big part of how we develop many applications in the future. It needs to be as natural to us as the simple request/response world that we are used too.

UI latency is only one piece of user experience. There are many others. HTML 5 gives us richer components and semantics to work with. We have been working on different UI paradigms such as the Form History pattern that we have discussed before. Aza Raskin and others have been doing really good work on new paradigms too.

Personally, I think that new input devices are going to create a huge change for us, and the abilities of Web applications. We played with the WiiMote as an input device. We then have multi-touch, which is available on touch pad devices as well as touch screens. Finally! We are moving past the prehistoric inputs where we can point and say “Ug”.

I am incredibly excited about where we are, and where we are going. There is a ton of work to do, but people feel engaged. Let’s “get ‘er done”.

Where do you think we are going?

This presentation goes over some of these points, in more detail:

Sep 30

From Google Developer Day to The Ajax Experience

Ajax, Tech with tags: , , , 1 Comment »

I am on the final leg of a few weeks on the road. I had a great time in Europe speaking at the Google Developer Day events. Above, are the slides from the Madrid event for the “State of Ajax” talk that I gave.

The video is up too:

Now, in Boston, I am having a great time at The Ajax Experience as always. The reason that Ben and I started this event was to have an excuse to get the community together. The speakers are top notch, and it is great to have them.

Since Ben and I have given a ton of talks together, we wanted to shake it up a little bit for our opening keynote. So, 30 minutes before the talk, we whipped up a trivial “Random Presenter” application that would run a buzzer at a random time between the min and max that you set. We used 10 seconds to 120 seconds, and whenever the buzzer went, the other presenter had to take over at the point. This would often be mid-sentence, and Ben did a particularly good job at ending mine :)

It was a lot of fun for us, and I hope it was a little entertaining for the crowd. There is nothing like improv to keep you on your toes!

Aug 25

Using the W3C Geolocation API Specification today; Extending WhereAreYou

Ajax, Gears, Tech with tags: , , 4 Comments »

Last week I shared the WhereAreYou? application that used the Ajax APIs ClientLocation API to access your location via your IP address.

At the same time, we announced support for the Gears Geolocation API that can calculate your address using a GPS device, WiFi info, cell tower ids, and IP address lookups.

Add to all of that, the W3C Geolocation API that Andrei Popescu of the Gears team is editing. You will notice that it looks similar to the Gears API, with subtle differences. The ClientLocation API is quite different.

To make life easier, I decided to put together a shim called GeoMeta that give you the W3C Geolocation API, and happens to use the other APIs under the hood.

If you have the Geolocation API native in your browser (no one does yet, future proof!) that will be used. If you have Gears, that API will be used, and finally, with nothing the ClientLocation API will be used behind the scenes.

To you the API will look similar:

// navigator.geolocation.getCurrentPosition(successCallback, errorCallback, options)
navigator.geolocation.getCurrentPosition(function(position) {
      var location = [, position.address.region,].join(', ');
      createMap(position.latitude, position.longitude, location);
}, function() {
      document.getElementById('cantfindyou').innerHTML = "Crap, I don't know. Good hiding!";

At least, that is what I would like. Unfortunately, there are a few little differences that leak through.

  • The W3C API only seems to give you a lat / long, so you have to do the geocoding to get address info
  • The Gears API gives you an additional gearsAddress object attached to the resulting position object. This can contain a lot of information on the resulting area (street address to city to …) however for certain providers the API returns that as null, the same as the W3C standard
  • That gearsAddress object has slightly different information from the address data that the ClientLocation API returns.

To give you control when you need it, you can ask the navigator.geolocation object what type it is. navigator.geolocation.type will be null if it is native, but ‘Gears’ or ‘ClientLocation’ if a shim kicks in. You can also check navigator.geolocation.shim to see if it is augmented code.


There is some fun implementation code in there if you poke around. For example, for the ClientLocation API, when you make a call, it will be added to a queue if the Google Loader hasn’t fully loaded yet, and it will kick off that call when finished. Dealing with dynamically creating <script src> as a loading mechanism sure is fun!

I like the idea of jumping straight to the W3C standard and updating the shim as the APIs change. That way, when browsers catch up, the code will still work using the native APIs and you don’t have to change a thing.

Where are you?