- What's the problem?
- What compromises need to be made?
- What options do we have?
- Keep it pure
- Undermine it
- Spread the marmalade
- Browsers without JavaScript
- drop support altogether
- serve un-styled page
- replace HTML5 tags with HTML4 tags
- move HTML5 tags back to HTML4 tags
- 'double bag' all HTML5 tags with HTML4 tags
- Should we even support these older browsers (or their non-JavaScript scenario)?
- Decision Tree
- Can we get users to upgrade their browser?
- CSS Strategy
In our progress to move the responsive code base up to the desktop, we have pressure to support older desktop browsers.
Specific pain browsers being: Internet Explorer versions 6, 7 & 8. But although we speak almost exclusively of older versions of Internet Explorer we shouldn't exclude potentially other similarly problematic browsers.
Ultimately, supporting older browsers will mean making compromises in our code.
There are two areas of concern:
- We require an additional script (HTML5shim) which will enable the browser to render CSS against HTML5 tags (the responsive code base was built using HTML5 as its foundation).
- We will be required to polyfill certain features or functionality that has been built with more modern API's.
Without JavaScript, we cannot load the HTML5shim and so the browser cannot apply CSS to the HTML5 tags being used. This means even the 'core' experience will not be usable for these users.
-
We keep the 'cut the mustard' test pure and any browsers that do not pass the test (or do not have JavaScript enabled) get the 'core' experience (this does mean older browsers such as Internet Explorer 6, 7 & 8 when run without JavaScript enabled could end up with a totally un-usable experience**).
-
We undermine the 'cut the mustard' test so that browsers such as Internet Explorer 8 can pass it (e.g. we polyfill the lack of
addEventListenersupport) and then we can map any requests in our code base to jQuery 2.0 to point instead to jQuery 1.9 which will hold API parity with 2.0 but is backwards compatible for older browsers (this does mean older browsers such as Internet Explorer 6, 7 & 8 when run without JavaScript enabled could end up with a totally un-usable experience**).Also, browsers such as Internet Explorer 6 & 7 do not have sufficient support to pass the test even when polyfilling
addEventListener. So we would need to either drop support for those browsers completely OR serve up an un-styled version of the page (see ** below). -
We create a 'spread the marmalade' test which would check for browsers that fail the 'cut the mustard' test (e.g. Internet Explorer 6 & 7) and allow them to get the JavaScript enhanced experience. By mapping jQuery 2.0 through to 1.9 we should be able to rewrite certain chunks of code to work with these browsers (this does mean older browsers such as Internet Explorer 6, 7 & 8 when run without JavaScript enabled could end up with a totally un-usable experience**).
Ideally we'd encapsulate these chunks of code in such a way that they could be easily stripped out when the market share for those browsers falls off. The problem with the non-JavaScript scenario is still prevalent though and so as per the previous option we would need to either drop support completely for these browsers running that scenario OR we serve up an un-styled version of the page.
The 'spread the marmalade' test would be a good measuring stick for stake holders to better track user statistics and make a more informed decision moving forward.
**Browsers such as Internet Explorer 6, 7 & 8 when run without JavaScript cannot load the required JavaScript file which allows them to apply CSS to the HTML5 tags used in the responsive code base. This means there are a few options available to us still…
- we either drop support for those browsers completely (because the non-JavaScript scenario for those two browsers means that even the 'core' experience would not be usable)
- we serve up an un-styled version of the page (e.g. no CSS) which would at least provide the core content to the user (similar to the 'core' experience but just not very nice to look at).
- we implement some form of browser sniff on the server-side to determine when to load up a PHP script to dynamically replace all HTML5 CSS & HTML to HTML4 equivalent tags. The downside to this is both the fact that we need to 'browser sniff' for specific browsers and also the extra server processing required to handle the transformation.
- we replace our HTML5 codebase back to HTML4. The major downside here is that we're neglecting all future users/browsers. This is not positive or progressive way forward.
- we 'double bag' the HTML5 tags so they have HTML4 tags wrapped around them with appropriate class names that are tied to the original CSS. This does mean the CSS & HTML would get slightly larger as we're attaching more class names to already defined CSS rules (and adding extra markup) but it does allow for us to provide a usable 'core' experience to our users and still allow us to remove support for these older browsers in the future.
It depends on the browser's market share at the time we need to make a decision.
We're currently (as of May 2013) not ready to move to desktop and so we still have time to consider the above options before committing to a decision.
We may find that when we're ready to go live with our desktop offering that the market share is so low that we just drop support for those older browsers.
To help us make our decision as to what browsers we will support (when the time comes to make that decision), we should refer to the following document: http://www.bbc.co.uk/guidelines/futuremedia/images/Decision_tree_v03.pdf which provides us with the relevant information we require to make an informed decision.
Other information useful for stake holder decisions:
Regardless of the options listed above, we could for each of those options decide instead to show a message to those users who visit the site with an older browser informing them to upgrade their browser experience.
As an example the following was a message that used to be used at my old agency…
{{company}} does not support the web browser IE{{version}} (Internet Explorer {{version}}). For more information on what a web browser is see the following link http://www.bbc.co.uk/webwise/topics/using-the-web/using-a-browser. Also, below is an outline of why we've made this decision and relevant links to more appropriate, more secure browsers.
The internet is constantly evolving and moving forward, implementing new and exciting features and technology. As part of this progression to a better web experience, older software needs to be upgraded to both make sure users are protected from known security flaws and to be able to fully enjoy the rich experience modern web applications provide. Our decision to no longer support IE{{version}} is based on its inability to handle basic design features, technological advances or, most importantly, the ability to implement satisfactory security protection and prevention.
Putting this in context, at the start of 2010, several leading governmental organisations and companies – both in the UK and abroad – began the process of removing support for this browser. Most noticeably, the Department of Health advised the NHS to move away from IE6 for all its communications. Indeed, the Cabinet Office has already issued advisory guidance to central government on how to deal with problems concerning the use of IE6, while government agencies across Europe are advising all internet users to stop using IE6 completely. Google has also abandoned support, with recent security threats to the site pinpointed to use of the browser.
{{company}} therefore recommends the use of other, more up-to-date browsers. Upgrading your browser is free and is very simple. There are many good browsers available. To find out more – or to download them – simply click on the links below:
The responsive code base has a mixed CSS strategy that needs to be solidified and re-architected.
Currently the code base mixes an inheritance style pattern (e.g. Wide inherits styles from Tablet). But also we have a composition style pattern where we inject styles into the page specifically for device dimensions.
We need to pick one strategy and stick with it.
We also need a strategy that allows better maintainability because the content visual noise of @if $core or $tablet { stuff } is just a nightmare to deal with and keep clean/efficient and well maintained. Conditional logic is a hideous code smell and when used to the level that we're doing it is a sign that we need to rethink our code design/architecture.
Our decision on what specific CSS features to use (e.g. more cutting edge CSS3 features) is a secondary decision to the underlying foundation that is our biggest concern at the moment.
Yes, on top of that strategic decision we will still need to decide what CSS features we utilise and that will ultimately be guided by browser statistics at the time of reaching Desktop. If we are to make a decision before reaching Desktop then that will mean we'll have to choose the lowest common denominator (e.g. IE8 or even lower -> which means a fair bit of our existing CSS code base would need to be rewritten to accommodate these older browsers).
Would legacy IE get an unusable experience or an unstyled experience?