AtoZ CSS Quick Tip: Achieving Cross Browser Support

This article is a part of our AtoZ CSS Series. You can find other entries to the series here.
You can view the full transcript and screencast for @supportshere.

Welcome to our AtoZ CSS series! In this series, I’ll be exploring different CSS values (and properties) each beginning with a different letter of the alphabet. We know that sometimes screencasts are just not enough, so in this article, we’ve added quick tips on what to consider for multiple browser support.

S is for support in multiple browsers

Keeping track of which browsers support which features is practically a full-time job. There are great sites out there like caniuse.com to keep us in the loop and amazing automation tools like Autoprefixer that mean you’ll never have to write a vendor prefix ever again.

But still, as diligent front-end developers and designers, we need to ensure that our content is accessible to as many users as possible and even if they don’t get the super fancy version, they can still consume the content and get the information they need.

These quick tips will suggest areas that you don’t need to fret about (for the most part) whilst still ensuring that your projects work across a wide range of browsers and devices.

Don’t worry about animations and transitions

For the most part animations and transitions should be subtle effects to make the content stand out more, direct the user’s attention or add a bit of personality and character to a page. If animations or transitions aren’t supported in a particular browser, the elements will just remain static or snap between states on hover of focus.

As long as the initial state of the animation isn’t positioning an element off screen or making it invisible (e.g. by setting opacity: 0) then the fact that the element won’t move in an old browser doesn’t really matter.

In the case of animations, you could try and provide a fallback using JavaScript but I’d really have to think hard about whether the extra effort, code and maintenance is worth the hassle.

Don’t worry about subtle transformations

In a similar vein to the comments about animations and transitions, I’d also not stress too much about making subtle effects like rotations or skews work across every device either.

.wonky-image {
transform: rotate(2deg);
}

If a device supports transform and you add a small rotation to an image to inspire a carefree and relaxed style that’s great. Does it really matter if a user with an old browser sees a straight image? Probably not. We should spend our time solving more relevant problems than trying to make every page look identical in every browser.

Don’t worry about semi-transparent colours

Based on the previous tips you should get the picture that it’s not worth worrying about making every last visual detail work on every type of device or browser. After all, it’s more about the experience as a whole and about enhancing that experience for those with more modern capabilities.

Progressive enhancement means providing a good base experience for everyone and then enhancing that experience where appropriate and where possible.

In the case of animations or transformations there isn’t really any alternative – although you could maybe use a GIF for an animation depending on the circumstances. However, in some cases, lack of support means nothing shows up on the page. If you have to support IE8, this is certainly the case for semi-transparent colors.

Fortunately, due to the way CSS handles properties or values it doesn’t understand, a simple fallback solution can be provided.

If you want to add a semi-transparent red to the background of an element, you can first declare a solid color and then override that with the semi-transparent one.

.box {
background: red;
background: rgba(255,0,0,0.5);
}

Old browsers will see the first declaration and “understand” the value of red. They’ll then see the next declaration (which should override the first) but see a value they don’t understand. This makes the second declaration of background invalid, leaving the background painted red.

Modern browsers will see the first background declaration and then the second just beneath. If the browser knows what rgba() is, it will paint the semi-transparent color and override the first.

This technique can be used with transparent colors, gradients, rounded corners, using rem values and lots more so is a handy concept to grasp.

What should I worry about then?

It may sound like I’m dismissing the need to think about browser support but I’m not. I’m suggesting that visual flair doesn’t (necessarily) need to look and work exactly the same way in every browser or on every device.

There are three things that I would spend time worrying about, having freed up a load of time by not worrying about the above. Do worry about:

Layout

Legibility

Performance

Layout is key to a user being able to navigate your site, use your app or consume your content. Ensure that the techniques you’ve used for layout work in all of the browsers you need to support.

Legibility is incredibly important. I was recently trying to read an article that we set in a very fine medium-grey font on a light gray background. I had to fiddle around in the developer tools to increase the contrast just so I could read the content!

Performance of your site is also incredibly important. This is a huge topic which I’m not going to try and sum up in a single paragraph but in relation to our topic of browser support, don’t try and polyfill functionality or add a whole heap of animation and effects with JS at the expense of performance. Many of the old browsers that you’re trying to patch with extra code are already clunky and slow at parsing scripts, so adding more is just a recipe for disaster.

Instead, leverage progressive enhancement and start with a good baseline experience for as many people and as many devices as possible within the constraints of the project. Then enhance that base experience with all the bells and whistles to really make your work shine.