This post is best viewed in some other browser

8 June 2011 · 3 minute read · html5 · opinionated

Does everyone remember the good old days of when websites had the introduction

This website is best viewed in 800x600 and Internet Explorer 5

No? We’ll you missed the ‘good old days’ of the browser wars which saw the different browser vendors supporting different features which resulted in web developers having to pick and choose what browser(s) their websites would work in.

Fast forward a half dozen years and we end up in 2011 where we see a new browser war going on and this time the focus is on HTML5. With the browser vendors turning out new versions at a speed we haven’t seen in a long time, 8 to 12 weeks for IE, 12 weeks for Chrome and 14 weeks for Firefox, the features available in each browser can (and often are) different.

Take for the example the HTML5 input types, most specifically the the date picker. For years we’ve been using plugins for our favorite JavaScript library to create date pickers so it was only natural that the browsers would evolve to having built in. But there’s a problem, only some browsers do support them.

This isn’t a huge issue because through tools such as Modernizr we can detect if a browser does or doesn’t support it and use a polyfill or shim to patch the gaps. Awesome, but what if the browser has partial support? For example at the time of writing the current version of Chrome is 12.0.742.91 (Official Build 87961) running WebKit 534.30 (branches/chromium/742@88085) and it supports <input type="date" />, but it only has partial support. Here’s how it looks:

Chrome date input

In fact Opera is the only browser that has full support for it.

But that’s fine, as I said before we can use a polyfill to add the date picker, only there’s a problem. Because the partial support which the WebKit engine has kind of has a date picker but kind of doesn’t you still end up with the scroll bar on the side. Additionally you can’t change the format of the date that you’re entering.

Another interesting fact is that the <input type="number" /> in this build also appears to be miss-implementing the HTML5 spec and inserting a comma every three digits.

There was also the saga about Web Sockets spec changing and potential security holes (which saw Firefox disabling them by default).

And this brings me back to my original question, are we going back to the days when the differences between the browsers are holding us back from doing what we need to in complex web applications or are polyfills and shims going to save us from another generation of websites which work best in some other browser?


Published: 2018-05-29 16:49:01 +1000 +1000, Version: aaf7f73