As a web developer, over the years I’ve asked the producers/project managers I’ve worked with “and what browsers are we supporting?” more than once, for every project I have worked on as though its fine to think there are some browsers we just don’t support. We understood that the internet is accessed by a wide range of browsers, it should be accessible and inclusive and project’s content should be viewable for as many people as possible. But, we have a limited about of time and resources and there was only so much graceful degradation and progressive enhancement we could do.
Recently the gov.uk developer blog posted “Gaining Understanding of the Browsers People Use”. In it, they published a table of September 2016’s traffic broken down by browser; importantly listing both percentage and the number of sessions.
And it really got me thinking.
In September 2016 they had 91 million sessions. Which is one and half times the population of Great Britain. Of those, the majority used nice new browsers. Great. Older Microsoft browsers – IE6, 7, 8, 9 and 10 – account for just 3% of sessions. A forgettable 3% minority? Put back into numbers, 2.5 million sessions. Or, the population of Manchester (England’s second city, my home town), Paris and Brooklyn. Put into numbers like this, that 3% seems a lot more important.
What should we do about these users?
Polyfilling and shimming, CSS hacking and testing all these browsers is going to take forever. Clients budgets aren’t limitless and focussing our efforts the vast majority of more capable browsers makes more sense.
So, lets not bother
When I asked myself why people visit my sites, and the ones that I make for other people, the answer was always “for the content”. Content that is almost always written words and that means type.
Using such things means we don’t waste time and energy in the impossible task of supporting every browser but people who are still using those browsers can still easily read what they came to the site to read – the content. He was right. He also managed to sell it to his clients without complaint.
And today it seems more pertinent than back in 2009. Back then, we essentially considered IE6 to be legacy and pretty much all other browsers to be better. Today, old versions of Chrome, Safari, Firefox and Opera are practically just as bad as those older versions of Internet Explorer. We can’t target these browsers with the same conditional comments trick Andy used for his Universal IE6 CSS.
What can we do?
Get to some code already!
In our document head, inline, we have a piece of code similar to this:
This performs our mustard test to determine if the browser is a HTML4 or HTML5. If it decides it is a HTML5 browser then it loads picturefill.js from a CDN to ensure our responsive images work in modern browser as even some modern browsers don’t fully understand responsive images.
If the browser is deemed to be HTML4 then we load in a HTML4CSS and a legacypicturefill.js.
HTML4CSS and a legacypicturefill.js
HTML4CSS is a new project on AREA 17’s GitHub to provide typographical styles to HTML elements, a sort of updated Universal IE6 CSS, only not just for IE6 and with some timeless A17 styles. Right now HTML4CSS is in initial release phase and is due for tweaks and updates from myself and A17 design but, its ready for use right away.
One complexity with legacy browsers and modern responsive images; they are a little more complex to handle. Responsive images have new and different markup for an image than older browsers are expecting. New attributes for alternative image sources and a new attribute describing when to use those alternative image sources. We also got a new picture tag; older browsers have no idea how to handle these. Leaves us with a problem, many responsive images will appear as broken images on older browsers and they say a picture is worth a thousand words.
To tackle this, legacypicturefill.js is another new project, also on AREA 17’s GitHub, which somewhat arbitrarily gives responsive images and responsive pictures a usual image source for legacy browsers to display. It won’t be the most optimal image but it will be something rather than just a broken image. It also attempts to handle circumstances where lazy loaded images using
data-srcset attributes are used instead of regular
Both are on MIT licenses to do as you will with them.
While I mention new A17 GitHub projects
We’ve also published lazyload – a very simple, very tiny, image, picture and iframe lazy loader which does lazy loading and only lazy loading. It might prove to be a simpler, smaller alternative to one of the many other more complex and larger lazy loader scripts.
If you find any of them useful, please send us a tweet to let us know.