Yesterday, Paul Rouget, a Mozilla tech evangelist, wrote a blog entry stating that IE 9 is not a “modern browser”. Not long after that, Ed Bott tweeted that the post was “surprisingly shrill”. Several folks (including me) responded that the post made important points, and Bott asked for specific examples of real web sites that used the HTML5 features that IE9 is missing. (I’m using “HTML5” to refer not only to the language itself, but also to the new APIs related to it.)
That’s hard to do, especially in a tweet. If the most widely used web browser doesn’t support these features, even in its upcoming newest release, how many mainstream sites can use them? They’ve been added to the HTML5 spec because there are strong use cases for them, and when users have browsers that support them sites can start taking advantage of them. Of course, there are some sites that use these features, but Bott specifically said he didn’t want to hear about pilots or demos, which excludes a lot of them.
There’s a chicken and egg problem here. We can’t make heavy use of HTML5 features in web sites unless web browsers support them, and Ed Bott seems to be saying that the upcoming version of IE9 doesn’t need to support them because they aren’t yet widely used. That kind of problem is part of what stalled HTML and browser advances ten years ago. The WHAT WG didn’t accept that, and pushed for what became HTML5. I think that Google was a major help because it had the resources to improve browsers (first with the non-standard Gears plug-in, later with their standards-based Chrome web browser) in order to be able to develop more sophisticated web applications. Their experimental ChromeOS devices like the CR-48 show that Google is still very interested in the idea that the browser can be an application platform, not just a viewer of web sites.
For me, IE9 is most disappointing because it fails to implement many key HTML5 features that are essential to building good web apps. (I use “web apps” to mean platform independent applications that live and run inside a modern browser, including many mobile browsers.) Yes, IE9 makes a lot of advances and I appreciate them all, but some of what it leaves out is essential and does not seem nearly as hard to implement as some of what they included. Consider some use cases that I actually encounter.
In a traditional web browser no data persists in the browser between separate visits to a web page. If I want to start working on something in my web browser and then finish it later, the browser has to send it to a server to remember it, and when I revisit the page in the future it has to fetch that information back from the server. But what if I don’t want to disclose that information to the server yet? Maybe I’m preparing a tax form, and I don’t want to give a third party a history of all the changes I’m making as I fill it out, I just want to submit the final filled-out form? In a traditional web browser I can only do that if I perform all the work during a single page visit.
If only the browser could store the data I enter within the browser, so I could come back and work on the form over multiple visits without ever disclosing my work in progress. Actually, HTML5 (and related technologies) lets you do that. Web storage (including local storage and session storage), indexed database, and the file system API can each meet that need. (So can web SQL databases, but that approach will likely not be in any final standard.) Of these solutions, only web storage is widely available today. It’s on all major current browsers, including IE8 and IE9. Good for IE.
Now, suppose I want to work on my tax form and I don’t have an internet connection. The data I need is in my browser, so shouldn’t I be able to do this? If my web browser supports application cache, I can. Every major web browser supports this, and most have for the last several versions of them. Except for IE. Not only does IE8 fail to support this, so does IE9. If I try to work on my tax form in IE9 I’ll just get an error message that the page is unavailable. Even though all the functionality of my tax form program lives inside the web browser I can’t get to it unless the server is reachable. That’s a problem for an app. This is my biggest disappointment with IE9, especially since application cache seems like a pretty easy extension of the caching all web browsers, including IE, already do.
But you might ask, so what? This is a web app, and it’s not that big a problem if it only works when the server can be reached. After all, it’s going to have to talk to that server sooner or later in order to submit the tax form. But let’s switch to a different use case. Suppose I want to do some photo editing. The HTML5 canvas API gives me a lot of ways to do that. I gave some talks last summer on HTML5 techniques and built an application that could resize photos and convert color photos to black and white or sepia toned. The whole example took less than an hour to do. This is an application that doesn’t need to ever talk to a server except for the initial installation. It’s something that I could use on my machine with any modern web browser, so I can write it once and use it everywhere. There are two big challenges for this application, though: getting photos into the code in my browser, and then getting the edited photos back out.
There’s no way to do that in an old-fashioned web browser. If I’ve got a binary file on my PC and want to get it to the code in the browser, I have to use a form to upload that file to a server. My browser code can then fetch it back from the server. It goes through the browser to get to the server, but is inaccessible to code running inside the browser. With the HTML5 File API, I no longer have that restriction. I can select a file with a form and the code in the browser can directly read that file instead of sending it to the server. That’s how I get a photo into my application. Every current major browser supports the File API except for IE and Opera. And Opera might add it in their next version (they haven’t said), but IE9 won’t have it.
Once I’ve edited the photo I need to get it back out. What I need is either an img element (so the user can right-click and choose to save the image) or a simple link that user can click to download the image. The problem here is that for either of these methods to work, the photo has to be in a resource with a URL. How do I get it there? In an old fashioned web browser, the code in the browser would send it to a server, which would save it and make it accessible at some specific URL. Once again, my browser ends up having to send something to a server so that the browser code and browser user can share something. With a Data URL, I can create a resource with a URL inside the browser so that no server is needed. Data URLs are a lot older than HTML5 and have been supported in all major browsers. However, until recently IE limited their size so much as to make them not very useful. IE9 does allow large Data URLs, though. Again, good for IE9.
So, for these use cases we need four key technologies: persistent storage in the browser, offline access, reading files, and creating resources and URLs for them in the browser. Every modern web browser supports all of them (assuming the next version of Opera adds the File API). IE9 supports only half of them, and can’t serve either use case.
That’s one reason we should not consider IE9 to be a “modern browser”.
Charles Engelke's Blog 