Still Breathing

A conversation at work last week got me thinking about what we, as web developers and designers, mean when we talk about websites supporting certain browsers. I feel that the word ‘support’ is misunderstood, and has a number of meanings depending on the context in which it is used. Does it work? In my experience,…

Some people who know me well may not quite have heard me correctly, so I’ll repeat: I’m learning React. Does this mean I’m turning my back on the principle of Progressive Enhancement? Does it mean I’m going to start building websites which are 99% JavaScript and 1% everything else? Have I given in? No, dear…

A conversation at work last week got me thinking about what we, as web developers and designers, mean when we talk about websites supporting certain browsers. I feel that the word 'support' is misunderstood, and has a number of meanings depending on the context in which it is used.

Does it work?

In my experience, people mostly use 'support' to describe in which browsers a website will work. However, 'work' isn't an adequate word. Websites rarely do or don't work in their entirety. Websites are complex collections of dozens, often hundreds of, different commands and API calls. Any mixture of them may or may not be available in a browser accessing the website, depending on the browser type and version. It's rarely a binary situation where the site works or doesn't work. We need to take a more nuanced approach, and realise there are levels of 'working' that may or may not make a difference to the user of the website. Those users are the ones for whom the website exists, after all. For example, many years ago when rounded corners were being introduced in CSS, some pragmatic web developers added the code for rounded corners to their CSS styles knowing that if a browser didn't understand that code it would ignore it. The corners would be square, but no error would be thrown. Users, unless they were eagle-eyed and knew that the corners were meant to be round, wouldn't even know the difference. That was made possible because of the declarative nature of CSS. HTML works the same way - if a browser doesn't understand a particular element it will render the contents of the tag as text and move on. No error will be thrown. Here's an example of that flexibility: <audio src="postman-pat-grime-remix.mp3">This will be displayed in browsers that don't understand the 'audio' element<audio> JavaScript, on the other hand, doesn't work like that; it's imperative. This means that if the browser doesn't understand a particular piece of JavaScript code it is beng asked to run, an error is thrown. That error may stop further JavaScript being executed on the page. So there's a big difference in how developers should approach the use of CSS/HTML, and JavaScript. Nuance is the key. This nuanced approach understands that not all functionality is created equal. For example, for some sites the ability to re-order a table of data instantly (i.e. without a trip to the server and back) is crucial to the functionality of the site. Or, perhaps a particular site absolutely cannot function without CSS grid layout. But these cases are, in my experience, rare. Most sites - not all, but most - require only basic functionality to work, even if they get nicer to use with additional 'bells and whistles'. We have to ask tough questions about what our bells and whistles are, and whether the bells and whistles we are adding to a site are really required: especially if they stop users of some browsers using that site.

Can we test it?

The other context people use the word 'supports' is when talking about which browsers we are going to test. This is a difficult subject, as we don't have a hope of testing the huge range of combinations of browsers, operating systems, devices etc out there in 'the wild'. Here, we have to be pragmatic. We should look at the site statistics to determine the browsers, operating systems, and devices people are using. But we should bear in mind that if a particular browser or device doesn't seem to be used much, it might be due to parts of the site not working well for those users - even if they want to use it! We should also pay attention to global browser usage trends, particularly in the region or demographics our site is aimed at. So, rather than asking what browsers we choose support, let's ask what functionality do we need to use. We should make tough choices about the functionality our site actually needs - right the way down to code level; individual JavaScript API calls, CSS properties and values, HTML elements. Let's remember there are often many ways to achieve a particular outcome, and that users just want to do the job for which they visited the website. We'll then find that, rather than just 'supporting' a narrow range of browsers, we allow users with a much wider range of browsers, operating systems, devices - yes, and assistive technologies - to use our sites. Accessibility for all is a fundamental principle of the web. Let's not break it. Bells and whistles are great, but if they get in the way of the user accomplishing their task then they are nothing but a waste of time and effort.