HTML5 hurdles: what is missing and web browser update rate problems

Yesterday I attended the Stockholm Web Monkeys’ spring 2011 meetup in Stockholm, and I gave a short presentation and led a discussion about HTML5 – What’s good, what’s missing, web browser implementation takes.

My introduction

To begin with, I gave a short talk about HTML5, the current web browser state and my takes:

To summarize, a lot of exciting things are, and have been, happening with HTML5, and for the future I think one of the most interesting things is to see how the Device API will turn out and truly empower developers building open web-based things for mobile devices. Internet Explorer 9 is a great leap forward for Microsoft compared to previous versions, but it still lacks some of the things available in the other major web browsers. Some worry was also expressed about IE release cycle time and that if it’s behind now, imagine how long time until we will get the next version.

Biggest obstacle: web browser update rate of users

After my introduction I thought I’d get a lot of feedback on current web browser implementations of HTML5 features, performance, missing APIs etc. And sure, there were some talk confirming my thoughts on things missing in IE9, but the majority of opinions and worry was mostly about the update rate (or lack thereof) of web browsers amongst end users. Everyone seemed to agree that HTML5 is great, it offers amazing possibilities and in some time, when minor differences have been worked out, it will be a fantastic opportunity to build things for the web – no matter if it’s on desktop computers, mobiles or other types of devices.

The questions/thoughts were more about having a wonderful tool set with HTML5, but not being able to use it because of the market share of older web browsers. You could potentially target older web browser through the help of polyfills, depending on what you want to use, but we also discussed if that created a user experience good enough (due to all scripts and workarounds to make things work in web browsers that are already slow to begin with).

A common consensus seemed to be that most end users have no idea which version their web browser have, and most of the time, don’t even know which web browser they use at all, or what a web browser actually is.

We discussed the pros and cons of automatic web browser updates, where the pros naturally are always having the latest version and removing the risk of people not upgrading, but the cons are about respecting the end user’s free choice and awareness of upgrading, and also about backwards compatibility. Having an automatic update breaking old functionality, especially for business-dependent web sites, is a major risk.

We covered the topic of having version-less web browsers (connected with automatic updating then) since no one knows the version the web browser is anyway. And with the incremental speed of the version number in Google Chrome, it seems to somewhat kill the point of versioning.

Another point of view brought up was if we can start asking/requiring of end users to have the latest most modern web browsers to experience a web site (I also discused this with Yoav Weiss on Twitter yesterday, and he wrote about it in Putting IE to sleep)? Personally, I think web content is there for everyone to take part of, but the vital thing is that they can read the content and perform the actions on a web site. In some cases it could work with a respectful and subtle notification to the end users that there will be more features available if they upgrade.

We also touched on the topic whether a web site/experience should aim to be the same for all end users, or if it’s possible, both technically and financially, to have multiple versions of everything we build.

Feature suggestions

It got late and people were tired, but when trying to push people for missing features, an idea came up about having P2P support and APIs directly in a web page. However, much more emphasis, and trouble, seemed to come from all the old web browser versions and (lack of) functionality to support. It seems like the current state of HTML5 is sufficient for so many use cases, that getting people to upgrade their web browsers and being able to use these opportunities by default is much more important to just keep on adding more and more things.

What are your thoughts?

What I’m really curious about is what you think about this? Do you also think we have the same problems with web browser update rate of end users, and if yes, do you have any good suggestions how to tackle that? Also, when it comes to HTML5, what are the potential things you are missing?


  • Teylor Feliz says:

    Hi Robert,

    As we discussed some days ago, I think it should be an option for the user to automatically update the browser or at least let the user knows when there is a new version available. Most of the users are not web developers or geeks to know that what they are using as a browser is old. For example, there are a lot of people that still use Windows XP and every time they reinstall the software they have IE6 in their computer, but nobody let them know that what they have is more than ten years old. However, the browsers should be careful introducing new versions to automatically updates because they can break even the well written code. As an example is the AVG antivirus caused a problem at the start up in Windows 7 and users cannot even run the OS due to an automatic update that was not tested enough before they put it in the server.

    I do not think that Modernizr or tools like that are the solutions for browsers that do not support HTML5 because doing that we are still coding and checking for old versions which bring us to the 90’s and its IE and Netscape ward (Coding for to different browsers).

    I have some other ideas but I would like to see other people ones…

    Thank you for letting us share our thoughts!

  • Beecher Greenman says:

    I’m not really sure about the use cases for either of the suggestions mentioned.

    P2P: If this is about starting P2P downloads, then what about URI schemes isn’t sufficient? If it’s about something else, then what is it about?

    APIs directly in Web pages: If this is about browsers making calls to an API using URLs, isn’t this already solved via REST (or, alternatively, URI queries with parameters)? If it’s about JavaScript APIs, isn’t it solved via JS libraries?

  • Yoav Weiss says:

    It is very true that Chrome’s “new version every 6 weeks” had made the notion of browser version irrelevant. Like we say in French “Trop de versions tue les versions”. Currently they have no competition in bringing the cutting edge features to the hand of users.
    I think the ideal approach to browser updates is (frequent) automatic updates, option to opt-out from automatic updates (for devs and power users), and a possibility to install different versions side by side (for research/experiments)

  • Paul says:

    Right now for developers I think it’s an incredibly exciting time. We have access to some brilliant technology, particularly in the case of HTML5. But at the same time we are having to hold on to the past and support browsers that are, in one case, over a decade old. Doing so costs a lot of money and ultimately it hampers development and adoption of newer technologies. There is a case for businesses that require that their users stick with old browsers because their intranets and so forth require it. Outside of that setting, however, it makes very little sense.

    I am generally in favour of auto-updates. I actually like it about Chrome because for me I don’t want a regular prompt that gets in the way of me actually using the browser that effectively says “upgrade”. I have to trust the browser manufacturer knows what they’re doing and that an upgrade won’t break my computer, etc. whether I do that upgrade manually or if it happens automatically. Since that’s the case I think I’d rather the update just happened quietly in the background. With that said I think a user should have the option to disable automatic updating if they so choose. So probably a balance is called for on that one.

    My own take on this is that browser manufacturers should embrace a version-less browser model if they are technically able to do so, but provide network administrators and power users the ability to lock to a specific version if they require it. Ultimately, though, I feel it’s in everyone’s interest to keep moving forward and for us to continue to let go of older browsers where we can.

  • I think the ideal approach to browser updates is (frequent) automatic updates, option to opt-out from automatic updates (for devs and power users), and a possibility to install different versions side by side (for research/experiments)

    I can only second that.

  • Kyle Simpson says:

    Great article, and important that you’re calling some attention to this topic.

    In a way, the situation we’re in with HTML5 is kind of like the government actually passing a budget to fund a program (or enforcement of some law) they earlier voted to approve. There’s a gap between when the theory of something is solidified, and when it becomes reality. We’re still definitely in that gap, where HTML5 has become law, but the funding to enforce it is far from plentiful.

    To carry the analogy slightly further, it’s like a law that was passed that only a small percentage of the public even knows about. It raises the question, if the government declares a law, and the law is only rarely or barely enforced, and the public doesn’t know much about the law… is that law even relevant? If a tree falls in a forest…?

    The same is true of HTML5. Until end-users inherently care enough about it that *they* are driving/demanding adoption, then it’s a tail-wagging-the-dog situation, where we as the passionate, vocal minority (that is, leading edge web developers) are pushing and pushing to get new cool features we can play with, but we gloss over the fact that the majority of web developers are simply driven by practical pressures from bosses and clients to implement “good enough”, and fast.

    Take web sockets for example. Fundamentally, there’s only a few things that web sockets can do that XHR cannot. That’s why is so awesome, because it basically implements web sockets on XHR for older browsers. Slower, but it works. How do we convince end users that they must demand browsers get web sockets (and get it right)? I think that won’t happen until we find a user-story that is fundamentally different and better with them present, compared to without them. Until then, it’s just a law with no funding, taking up wasted space in the books.

    Now, agreed, if developers aren’t pushing to expose new and better ideas via bleeding edge browser functionalities, the natural discovery rate of these things will be so slow that the general public won’t really *know* about HTML5 until we’re already well past it, into HTML6 or 7. That’s an unacceptably slow rate of adoption, obviously. So we as developers do have a role to play in helping users understand why **they** want these features. Not because they’re cool, or make *our* lives easier, but because they will fundamentally alter (for the better) their experiences on the web. But we have to be careful that we don’t over emphasize aesthetics as opposed to functionality. Are rounded corners and gradients really more important than geolocation and history.pushstate?

    Finally, I think we need to be really careful that browser vendors don’t get so frustrated with the “slowness” that, in their bleeding edge experiements, we end up in a mess like with IE6, where developers and sites start demanding users only be on some particular bleeding edge browser, and cause lock-in. This is, I think, an unhealthy trend in the effort to find relevance among the most cutting edge new HTML5 functionalities.

  • Jake Archibald says:

    Google’s update model seems to work. I don’t recall them breaking anything in an update, if they have I guess they sorted it out pretty quickly. As a developer, I don’t have to test loads of different Chrome versions, as users tend to be on the latest.

    IE appears to be prone to regression bugs, I guess that’s a problem they’ve created for themselves. Their current solution of quirks/standards/superstandards mode switch seems to be working for now, but they’ve got to stop that for new versions.

  • Okke says:

    As a webdesigner I would love to see auto-update for all browsers, the sooner everyone has the newest version, the better. Maybe an opt-out for auto-updates instead of opt-in?

    Another option might be; always auto-update, but leave a button of sorts (maybe under Help) with which to go back to the old version if things break horribly?

    As for things missing in HTML5? I agree, let’s first get the whole world to use HTML5 capable browsers…

  • Jos Hirth says:

    The most important metric in this context is how long it takes until a specific percentage (e.g. 80%) of users have switched to a newer version of their browser.

    With Chrome it takes somewhere between a week and a month, with Firefox/Opera about 6-12 months, and with IE it’s 6+ years. (This ballpark figure is based on StatCounter’s statistics.)

    The update frequency is also very interesting. A high update frequency fragments the long tail so much that supporting it becomes completely impossible.

    Now, this may sound like a bad thing, but to be honest, the effect actually looks pretty positive. Case in point, no one would support IE6 and IE7 anymore if their market share were divided between 100 different versions.

    There is also a solution for corporate environments and business-critical intra-/extranet applications: You can use something like Chromeless, Appcelerator, or whatever if you want to use a fixed platform for those things. You can install and run as many different engines as you want/need this way. This option is clearly superior to using one specific IE version for everything till the end of time.

  • David Bruant says:

    Fully agree with the idea that what moves he web forward is when web developers can decide to drop support for older browsers.
    On how the upgrade policy influences new version adoption, I highly encourage to take a look at and look at “browser version” over a year. It can be seen that Chrome older versions go to a ridiculously low market share in no time. On the other hand, since IE is tight to windows updates, people don’t upgrade that often. Firefox seems to benefit from users habit to update their browser themselves, but a campaign to ask people to move from FF3 has been helpful to decrease it’s market share. (this is all my own interpretation of course)

    Keeping older versions around has been useful for some time in earlier ages since people were coding add-on or plugin for some particular versions of particular browsers. Moreover, HTML, CSS and JavaScript required hackeries that worked only in one version so some services would require their users to have a particular version.
    But the web is moving:
    – All browser vendors now are getting the importance of HTML, CSS, JavaScript interoperability and backward compatibility.
    – These massive technologies which were under-specified and under-documented are finding more and more their edges and hacks standardized
    – As for add-ons, it seems that platforms are stabilizing their APIs.
    – Web developers are getting the importance of feature detection over browser sniffing and other good practices that help the transition to a new browser.
    All of these points make that moving from one older version to a new one costs less. It should actually make more sense now to encourage people more explicitly to update.

    Slightly aside, it’s good to see that now browser vendors have all understood that the browser war isn’t that much within web application technologies (because it makes developer work a burden), but around them:
    – Firefox has always been leading the way with tabs, the awesome bar, plugins, themes. And now panorama, personas, etc.
    – Chrome with tabs on top and with a tremendous work on speed (actual or perceived)
    – IE with Windows 7 integration (and jump bar or jump list or these things I don’t know about since I have a WindowsXP/Ubuntu dual boot!!) and hardware acceleration
    – Opera with Opera Unite (I understand the potential, but no one really uses it unfortunately and they should have allowed people to create their own Opera Unite servers!!)
    – All browsers work hard on their developer tools
    – Private mode
    – etc.

  • Robert Nyman says:

    Thanks everyone for great comments! Definitely something worth considering and thinking about.

  • Karl Böhlmark says:

    As mentioned earlier, a large part of the problem with slow browser update rates is corporations having locked themselves in to ancient IE versions by means of building IE6 and/or IE7-only applications.

    With one of those large enterprises being a customer of mine at the moment, it’s interesting to note that this issue is quite high on the agenda right now. The reason it is being brought up, however, is not that they long for HTML5 or that they want to be able to use the delicious Firefox 4. Rather, it’s because the upper management want macbook air and IPads.

    I actually believe this to be truly significant.

    IPad will help us push out html5 to the enterprise :-).

  • Karl Böhlmark says:

    Regarding browsers in the enterprise environment I very much appreciate the work google is doing to make chrome a viable alternative for enterprise deployment (for example msi packaging:

    Personally I will try to promote rolling out chrome frame as way of enabling html5 features for new applications while retaining the capability to run the old ones.

  • Karl Böhlmark says:

    As to peer-to-peer connections in HTML5, work has been done not just in terms of specification but also implementation: .

    Example of usage (with implementation) can be found here:

    As always the most interesting aspects of p2p is the increased scalability. If your application lets your users communicate via voice, wouldn’t it be nice (for scalability) if those data streams didn’t pass by your server?

    I see this as a natural step in turning the web server into mostly a deployment mechanism.

  • […] common discussion about HTML5 and whether to use it, and touched on in the HTML5 Hurdles article, is usually about fallback support and making it work in every web browser. But do we […]

  •   says:

    I think that web sites should organize strikes against such outdated users. Replace all the content for a day with a full screen explanation about what’s happening. Announce this before and add a timer during the blackout to display the time remaining. If this wouldn’t work, I’m not sure what would.

    If they don’t care about us, why should we?

  • I think the ideal approach to browser updates is (frequent) automatic updates, option to opt-out from automatic updates (for devs and power users), and a possibility to install different versions side by side (for research/experiments)

    Exactly what I was thinking. Having notifications that require confirmation before an update is performed doesn’t seem to work.

  • I’m of the mind that we have to be patient until the W3C sets the final standard for HTML5. I’ve been using HTML5 on mobile development because of the “forced” choice of browser on Android and iOS. On the normal web I’ve held back because IMHO there are too many users on older browsers than on new ones.

    When the W3C sets the standard then in many cases we should just build as we can based on the latest browsers and leave notices telling users to update. This is like when we had to get users to update for JavaScript and also for Flash 10. Sometimes you have to practice tough love.

  • Robert Nyman says:

    Personally I don’t think just an announcement is a good thing.


    Yes, it seems like most people just get annoyed by it and/or dismiss it.


    I understand your point of view, but don’t necessarily agree. I think we can use progressive enhancement and give a basic experience to older web browser and a more advanced to later ones.

  • […] reactions I have gotten to HTML5 hurdles: what is missing and web browser update rate problems and from constantly meeting/getting in touch a lot of web developers in very varying contexts from […]

  • […] reactions I have gotten to HTML5 hurdles: what is missing and web browser update rate problems and from constantly meeting/getting in touch a lot of web developers in very varying contexts from […]

  • […] common discussion about HTML5 and whether to use it, and touched on in the HTML5 Hurdles article, is usually about fallback support and making it work in every web browser. But do we […]

Leave a Reply to Matjaž Horvat Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.