Unfortunately browser support is limited to WebKit nightlies (Chromium 11) and Firefox 4 at this time. To compound this, Firefox did not bother to implement FileReader.readAsArrayBuffer() which means you can’t use the File API to read in binary data yet… uh… WTF? So basically I no longer support Firefox in kthoom. Oh well, the performance benefits cannot be ignored and they’ll eventually get there. Bug.

That’s not to say WebKit is all peachy-keen. You currently can crash Chromium OSX nightlies by creating an ArrayBuffer of unusual size and there are some issues passing ArrayBuffers into web workers. This means that I disabled use of Workers in kthoom as a result and everything happens in a single thread. :-/

Oh, and you can’t easily convert bytes from TypedArrays into strings…

FML.

But this just seems to be part of the overall growing trend towards sexy HTML5 user interfaces. Netflix is another one as described in their recent post.

The industry has been steadily shifting into the next phase of web development for a couple years – we’re nearly there now. Well since IE6 is no longer a concern (or hadn’t you heard – less than 5% of web users last month and still dropping), IE7 is quickly shuffling off the stage (~12% and steadily dropping), and IE9 is waiting in the wings.

Oh and IE8?

Yeah I don’t share in the pessimism of some who think that IE8 is the new IE6. And there are a lot of reasons I don’t:

• Month-by-month, the total marketshare of all IE versions combined has been steadily dropping. From 95% six years ago to about 50% now. Any gains on this percentage will be with IE9, not anything older.
• There are now more major modern browsers and platforms than ever before supported by companies with lots of cash and lots of push.
• Unlike IE6 at the time, IE8 simply does not have the capabilities expected of the average web developer. Given the numbers in my first point, next year there will be more users supporting SVG, Canvas, HTML5 audio/video than don’t. It makes mathematical sense to target modern browsers first.
• In a year and a half, Windows 7 went from nothing to a quarter of all desktops. At the end of next year, I predict XP users will be a minority among Microsoft desktops. Any Windows 7 users will be using IE9 in a year, not IE8.
• Google’s Chrome Frame plugin can be used to target IE8- users if you can convince them to download/install it. Disclaimer: I work for Google.

As for my own responsibility as a web developer… well, I’ve been developing for IE9+ for about 5 years now. I just didn’t know it at the time

But I still say that the introduction of the iPad is a signal of doom for Flash-as-a-format. On the other hand, as Adobe gets more serious about producing HTML5, SVG, Canvas, JavaScript from their Flash IDE, well…

One of the surprising factors in SVG-edit has been using GoogleCode in combination with Subversion. Let me tell you why:

Linked Information

Everything is an issue in SVG-edit. This is the way we keep track of things to do. This is the way other people discover things they can work on. This is the way we prioritize features for a release. This is the way we identify good first bugs for new hackers to work on. This is the way we sort problems into browser-specific, usability, interoperability categories. This is even where we put requirements and design decisions.

Making almost everything an issue is good because GoogleCode has some magic that detects revision commit messages and message comments and inter-links the two. For instance, if I fix issue 436, I might do:

$ svn ci -m "Fix Issue 436: Fixed the foo thing"

This shows up in GoogleCode here and provides you a link to the issue.

Now in the issue itself, I can mark it as Fixed and mention the revision that fixed the issue:

Fixed in r1275

Once again, GoogleCode provides a link to the revision when you look at the bug.

This kind of tracking takes a little bit of discipline, but it’s not that bad and the payoff is worth it. It really helps other developers keep tabs on what’s been solved where and how.

Host It

Since SVG-edit is a 100% client-side application (i.e. everything happens in the browser, no server component), and since Subversion allows you to specify MIME types by setting properties on files, we can convince GoogleCode to host the entire project in runnable form for the purposes of demo-ing the code.

This applies to the trunk as well as any branches and tags. For instance, you can actually see the evolution of SVG-edit over time:

• SVG-edit 1.0
• SVG-edit 2.0
• SVG-edit 2.1
• SVG-edit 2.2
• SVG-edit 2.3
• SVG-edit 2.4

Or you can look at the latest trunk build.

Or you can host the file in a web page by using <iframe> element like I’ve talked about before.

The fact that GoogleCode servers host the repo and also support web serving the content is immensely powerful: it means we don’t have to administer a source code repository and we don’t have to pay for a dedicated server or bandwidth costs to demo the software. Furthermore, because it’s a browser-based app, users don’t have to download anything, they can try out the code right on the spot.

Incidentally this is also one of the strengths of a web app in the first place: Zero downloads.

Tracking Down A Regression

GoogleCode’s hosting of the svn repo doesn’t stop at branches/tags. In fact, you can look at ANY revision in the browser directly. Coupled with the fact that we don’t really require a build step means that it is very easy to track down a regression.

git has this cool feature called bisect that allows you to hunt down when a regression occurred by seeking forward/backward across revisions in increasingly smaller increments, building each revision and testing until you find the first revision in a branch that exhibited a problem.

We can do this much easier in SVG-edit using Subversion on GoogleCode. Let’s say one day we notice a problem in the trunk and we’re at r1200. Well, we might decide to try out the editor at revision 1000 to see if the problem existed then. If the problem did not exist, we hop ahead 100 revisions to r1100 – was the problem present then? If so, hop back 50 revisions to r1050. Repeat in the browser until you isolate the earliest revision where the problem occurred, then add a comment to the issue and go review that revision.

Totally amazing capability and no more difficult than changing a revision number in the browser location bar. I have to credit Narendra Sisodya, the project founder, with uncovering that little nugget.

Not a Nirvana

There are still some grips/nits I have with GoogleCode+Subversion:

• Being able to serve gzipped JavaScript would be great
• Being able to display the current revision number in SVG-edit
• The wiki markup needs significant improvements

But this is free hosting and project management software, so I can’t complain too loudly.

One of the interesting things about Google Wave is that it was implemented using the Google Web Toolkit (GWT, pronounced ‘gwit’ apparently). GWT is a Java-based framework that compiles your code to HTML/JS/CSS. Like a lot of folks, I was skeptical about this idea (particularly since none of the significant Google web services were built using GWT). The fact that Google has implemented a major service on top of this toolkit now gives me a sense that GWT has been put through its paces.

Anyway, after the announcement, I adjusted my second day conference schedule so that I could take in the session on Wave and GWT. As part of this talk, they mentioned how they use WebDriver to automate testing of Wave across browsers. I had never really heard about automating web app testing, so I found the notion particularly interesting. Has anybody had any success with Selenium or WebDriver on apps that use SVG or Canvas?

Really briefly I tried to use the Selenium IDE extension for Firefox to run a test on the svg-edit demo. Unfortunately it doesn’t seem possible to capture the mouse click/movement on SVG elements, which means it’s a non-starter for me at the moment. I signed up for an account with OpenQA and asked an unanswered question. Note that after I asked this question, the svg-edit app abandoned its use of the <object> tag in favor of inline SVG that is programmatically added to the page. Unfortunately this resulted in the same effect: Selenium IDE ignores mouse clicks within SVG elements. Bummer.

I then tried to submit a bug only to find that OpenQA’s JIRA was crashing. To report THAT bug I’d have to sign up with an account at atlassian and that’s just too many degrees away from where I want to be. No one was around on the #selenium channel in IRC Freenode so I gave up for now. Hot Tip: if you want to build a community, make sure basic things like signing in to your bug tracker work!

Thoughts on the future of this feature? Here are some things I want:

• Please allow the author to extract the drawing as an SVG file from the service (currently Firebug is the only way I could figure out how).
• Fill gradients (Linear and Radial), please

And yes, there are privacy concerns with an online (aka ‘cloud’) service like this – I’m not implying you should use this for everything – but for the occasional document that you want to use for collaboration, it really does the trick.

Now if only I could get them to update their Spreadsheet service so that I can use it offline…

1. View and edit from any computer connected to the web in a password-protected fashion
2. View and edit locally from my personal computer when offline
3. View and edit from my mobile
4. Automatically sync to one central list
5. Private with occasional times when I might want to share
6. Ability to arbitrarily categorize, sort, filter

That last requirement really kills any plain-text solution without some other higher-level tool/markup.

Now that I have an Android phone with a WebKit browser, requirement #3 becomes easier to fulfill.

Google Docs actually comes the closest to meeting all the above requirements were it not for one important thing:

I’m sure the Google engineers are working hard on this important feature, but describing the existing application as ‘available offline’ is kind of stretching it at the moment.

If you want to launch your app in one click in the emulator (instead of having to pick “Android Application” from that silly “Run As” window every time), then you need to go to Preferences > Run/Debug > Launching. Under “Launch Operation”, choose “Always launch the previously launched application”.

The first time you’ll have to choose how to run your project (right-click on the project, Run As > Android Application). Afterwards, all you’ll have to do is click the “Run” button (or the shortcut combo: Ctrl+Shift+F11).

SVG Support Tables Now Interactive

Someone mashed together the data I publish with my SVG support tables and made it much more interactive and useful! Great! That’s what makes the web so cool: sharing. Now to see if I can break his scraping script… Joking!

IE9 Likely To Support SVG?!?

As “reported” in Wired and Ajaxian: Golly. How much? When? What version/profile? Sorry, but it seems that this is a misinterpretation of the standard SVG party line from Microsoft. Mumble, grumble, integrity… journalism… something, something, mumble…

More Mozilla SMIL Progress

Brian Birtles posts on the latest progress on Mozilla implementing SMIL-in-SVG. I’m hoping to see SMIL pick up, particularly as browser native support improves further. Of course you can get a headstart on this by using the FakeSmile shim right now in 4 of the 5 big browsers.

Qt Winning Votes?

Doug seems to agree with me that a LGPL for Qt could be a big game changer. I admit, I’ve always had a soft spot for Qt, but the recent news that it will be available to commercial projects without purchasing a license from Nokia is getting a lot of people excited – even heavy fans of Java

Google I/O Registration Open

I might actually try to attend the Google I/O conference this year in May. Rob and I tried to get our ducks in a row last year but the planning never crystallized. I’ve been doing some playing with Android recently, so there’s actually a reason for me to go this year.