frippz.se

I have more often than not been faced with the following scenario; a client, a colleague or maybe a project manager will ask the old-as-dirt question:

“What browsers should be supported in this project?”

For way too long I thought of this as a binary issue. You either supported a particular browser, or you didn’t. If you were a really bad apple, you took measures to make sure that the user of a legacy browser you decided shouldn’t be supported got a snarky message as well – “Sorry, your old browser is not supported by us.” – lovely, right?

All this is of course a pretty bad practice and parallels can be drawn to a store owner telling potential customers to get lost just because they can’t climb the stairs to get into the store.

Looking at the browser landscape of today and the future, we can’t keep asking ourselves which browsers to test for and whether we should optimize for legacy browsers, because that just isn’t very practical.

So what should we do?

Brad Frost wrote a great post called “Support Vs Optimization” back in 2011. You should absolutely read the whole thing, but if not, just read this:

“There is a difference between support and optimization” is a line I use regularly at work. For time and budget reasons, we can’t make the best experience ever for every connected device, but we have a responsibility to provide a decent experience to those who wish to interact with our products and services. As we move into the future, it’s going to be harder and harder to account for the plethora of connected devices, so we need to be construct our experiences with more consideration.

A lot of people will argue that supporting legacy browsers means putting in loads of hours adding fixes and hacks to make your website work in something like, say, Internet Explorer 8 (or even the over-a-decade-old IE 6). But before you dismiss the notion of supporting legacy browsers altogether, consider this quote from the same article:

You don’t have to treat these browsers as equals to iOS and Android and no one is recommending that we have to serve up a crappy WAP site to the best smartphones on the market. It’s just about being more considerate and giving these people who want to interact with your site a functional experience. That requires removing comfortable assumptions about support and accounting for different use cases. There are ways to support lesser platforms while still optimizing for the best of the best.

To get you started, I’d like to give you a few examples of what you can do to achieve this.

Consider progressive enhancement

I will not repeat the many arguments for progressive enhancement, when so many talented individuals have already done this in the past.

If you use a method like “Cutting the mustard” to only serve up JavaScript to modern browsers, you will very likely save yourself a lot of pain.

I’ll refrain from going any deeper into the progressive enhancement part in this post. If you consider yourself to be in the camp that says “But we’re making web apps and this progressive enhancement stuff does not apply to us”, I urge you to have a quick look at the following articles:

• Be progressive – by Jeremy Keith
• Progressive enhancement is still important – by Jake Archibald
• Stumbling on the escalator – by Christian Heilmann

Ok, moving on.

Go mobile first

You might ask yourself what mobile first has to do with legacy browsers. Internet explorer before version 9 does not even understand media queries, right? Well, mobile first in this context could mean that you start with a very basic layout that is defined outside of any dimension based media queries.

@media all {
  /* Put very basic, mobile first layout here */
}

Then you do more complex layouts with something like this:

@media screen and (min-width: 0) {
  /* Juicy, complex and cutting edge CSS goes here */
}

While this might be considered a hack, it’s totally valid CSS. min-width: 0; means all widths from 0 and up, but since IE 8 and older versions doesn’t understand the syntax, they’ll just ignore it. Also, keep in mind that the code snippets above is only the beginning. You of course need to add additional media queries for different breakpoints tailored to your design.

A basic mobile first layout will, provided you’ve kept it simple, work quite well on legacy browsers. Chances are it will look just fine (or fine enough) without you needing to add any quirky hacks to your stylesheet. A great example of how this can look is the website of Jake Archibald. Visiting his site in something very old (like IE6) and something quite modern (like Safari 8 on OS X) shows something interesting:

The looks of that site in IE 6 won’t win any design awards (but then again, neither will Windows XP, right?) The most important thing is that it works. The content is there, but all the bells and whistles are absent. My guess is that the designer spent very little time optimizing anything for legacy browsers. However, any unfortunate soul using IE 6 on Windows XP will still be able to get the core experience; the content. This is what matters the most.

This is only the beginning

This post will hopefully give you just a little bit of inspiration and maybe help you realize that supporting legacy browsers does not have to result in a lot of extra work. In return, you will reach a wider audience and most likely be happier for it.

This problem really isn’t something new and this specific issue has been repeated on many accessibility oriented blogs over the years. But since I regularly see this mistake being made over and over again, I think it’s time for a revisit. I’m talking about why you shouldn’t style away the :focus pseudo-class.

Pseudo-what?

Pseudo-classes have been around in CSS since the first version, albeit in a more limited manner and without the associated semantic meaning.

From the Mozilla Developer Network article on pseudo-classes:

A CSS pseudo-class is a keyword added to selectors that specifies a special state of the element to be selected. For example :hover will apply a style when the user hovers over the element specified by the selector.

Pseudo-classes, together with pseudo-elements, let you apply a style to an element not only in relation to the content of the document tree, but also in relation to external factors like the history of the navigator (:visited, for example), the status of its content (like :checked on some form elements), or the position of the mouse (like :hover which lets you know if the mouse is over an element or not).

Clear as a bell, right?

Our focus of the day

The :focus pseudo-class is often forgotten when developers start messing around with styling anchors on a website. However, it is just as important as :hover, :active and :visited. While the :hover pseudo-class matches when the user designates an element with a pointing device, the :focus pseudo-class is applied when an element has received focus, either from the user selecting it with the use of a keyboard or by activating it with the mouse.

In the context of keyboard navigation, the :focus pseudo-class is very important since it helps users who are navigating with a keyboard rather than a pointing device. All browsers worth mentioning have a built-in user agent stylesheet that sets a style for focused elements.

As you can see, the Internet Explorer 8 focus outline looks a little… ugly. Fair enough. But it still provides an important visual cue for users navigating with their keyboards. The problem is that this outline is also present when you’re using a pointing device and it also has a habit of becoming stuck after you’ve clicked a link (especially if you are are using JavaScript to catch the event). This has given rise to the following CSS rule on a number of websites:

a {
    outline: none;
}

This is, for obvious reasons, horrible. Suddenly, that ugly, ugly outline is gone and your designer is happy. But the accessibility just went out the window. To put it simply, don’t do it! If you must style away the outline, make sure you replace it with something at least equally clear.

The reason I wrote this article is that I still see this transgression on an almost daily basis. I usually navigate with a pointing device (a mouse or a touchpad, for example), but when it comes to forms, I know I’m not alone in tabbing between fields and form controls such as buttons. Say for example that you are about to submit a comment on another blog and you tab out of the text area to press submit, but suddenly, no marker is visible anymore. To make it worse, you might have two buttons after that text area, one for submit and one for clearing the fields. Care to play a little russian roulette with your carefully prepared comment? Didn’t think so.

It took me long enough, but after getting some time to finish learning the inner workings of Jekyll (which has been the tool of choice for this project), I welcome you to my personal journal!

I have to be honest. This entire project is actually created for one person, and one person alone; me. I’m using this website as a place to collect my thoughts and experiments related to front end web development. But since it is a nice thing to share, I’ll of course make it all public. Should you ever find anything I write here of use, so much the better.