The first of our series on modern development challenges will focus on the platform itself; the humble web browser.
We develop complex websites and web applications every day, leveraging more and more browser features in each project. Sadly these features are often incomplete in some browsers - in some cases even missing entirely. For this reason, a decision needs to be made on whether to make use of a new browser feature at all.
In recent months we have been investigating new browser features and determining whether to adopt them as a standard part of our offering; most recently CSS Grid Layout.
"This CSS module defines a two-dimensional grid-based layout system, optimized for user interface design. In the grid layout model, the children of a grid container can be positioned into arbitrary slots in a predefined flexible or fixed-size layout grid." - CSS Grid Layout specification
In an ideal world we would be able to take the advantage of this new browser feature and create our new website layouts without the issues encountered with Flexbox. Flexbox wasn't really intended to be a solution to the website grid layout issue. CSS Grid Layout brings us back to the old "table layout" days but without the semantic issues and with support for fully responsive layouts. However, not all of our standard browsers have full support for CSS Grid Layout.
According to the Can I Use statistics we are still waiting for Microsoft to ship the feature in Edge and - more disappointingly - Internet Explorer 11 will likely never support the full specification. We will soon reach a cross-roads where we need to re-evaluate our position on IE11 support. We believe using CSS Grid Layout for the standard page structure will positively impact both project timescales and website performance - both are great things for the users and our clients.
So how should we approach browsers which do not support this new feature?
- Do we re-implement the grid in a way that those browsers will support?
- Do we no longer support those browsers and include a message to inform the user?
- Do we try and go halfway and ship the website with a simplified grid layout?
This decision will need to be made on a project-by-project basis and the key metric for this decision will be…
The critical decider: browser market share
Unfortunately, Internet Explorer still holds a reasonable browser market share worldwide, and more so in the United Kingdom. This is likely due to Windows 7 users who have not made the leap to Windows 10. It is expected that this figure will go down but for some of our clients this share could be significant.
Worldwide desktop browser share
UK desktop browser share
It is useful to have an idea of the general browser share in the target market but the client's own analytics will always be the priority. If Google Analytics shows that a tiny fraction of their users browse with IE11, and they tend to have a low conversion rate then the decision is likely to be quite simple - drop support for IE11 due to the poor ROI. However, if the client sees positive conversion rates from those users then investing the budget in supporting them is a valid option.
Are "polyfills" the solution?
In many cases we can bridge the gap between browsers using a polyfill. This is essentially an implementation of a browser feature that is shipped along with the rest of the website assets in order to achieve feature parity. For example, the Fetch API can be used to make requests to external locations - such as APIs - and handle the responses. The support for this feature is very good - in fact only IE11 lacks support. Thankfully we can use a polyfill such as whatwg-fetch to ensure IE11 still works as expected.
However, in our example a simple polyfill isn't really an option; generally speaking CSS polyfills don't really exist. We cannot simply include a polyfill to enable support for the CSS Grid Layout specification, instead we aim to include a fallback under the guise of graceful degradation. This means that anyone who visits the website in IE11 will not have the same experience as users visiting the website in browsers that already support CSS Grid Layout - and this can be absolutely fine.
However, there is something on the horizon which could provide the solution to CSS polyfills - Houdini. This is a new team dedicated to solving the issue of browser feature parity in regards to CSS, and their main tools will be a series of APIs to allow developers to extend the browser's rendering engine. The full scope of Houdini really needs its own blog post so I'll include a link to Philip Walton's deep dive into Houdini.
Ultimately, the challenge of when it is appropriate to make use of a new browser feature boils down to a handful of questions:
- Is the feature additive? Will it improve the overall experience when support, but does not remove critical functionality when unsupported.
- Is the feature supported by the browsers highlighted in the client's analytics?
- Is there a polyfill that can be used to create a consistent experience in browsers that do not support the feature?
As long as we can meet one of the those three points then the likelihood is that we can adopt the new feature.