CSS Adventures: Avoiding CSS resets

It didn’t take me long at all to realise that I hated frameworks. Presentational classes in Bootstrap? I didn’t dare touch it. HTML5 boilerplate? Let me do it myself. JavaScript for a carousel/slider/gallery? I tried to avoid it at all costs.

CSS resets, though, are another story.

What is a CSS reset?

In a nutshell, a CSS reset file is a file that you can either build upon or let sit under the rest of your CSS. It is designed to ensure consistency across different browsers, particularly with regards to margins, padding, font sizes and other features that may be present in only one browser (Firefox-only or Chrome-only).

Building future-proof (and browser-proof) CSS

I started using a CSS reset about a year ago. I used normalize.css as I had used it at my workplace at the time. I was admittedly sucked in from the moment I read “consistent” and “all browsers” in the same sentence. I didn’t think much further than that. I thought that if I had base CSS like this, it would help prevent browser compatibility issues down the track.

Putting aside the fact that I test my designs meticulously in Safari, Chrome, Firefox, Opera, and IE (often right down to IE8, and IE7 if I feel like being a ninja) anyway, browser compatibility issues can’t necessarily be solved with just CSS, much less a CSS “reset” file. Browsers were built differently and naturally have their inconsistencies. A normal part of web development and building websites – especially good websites – is sweating out stuff like cross-browser compatibility, and I dare say we make our lives hard by making this seem like a chore.

There are many features of HTML and CSS that only work in modern browsers, and I personally choose to avoid them until I have a firmer grasp on how the feature works, and until more browsers support the feature. It means less headaches associated with trying to make things cross-browser compatible.

CSS wizard Harry Roberts puts forward his viewpoint on building websites to last:

You’ve got new stuff for new browsers and old stuff for old browsers. The thing is, the old stuff works. So if you need [the site] to last a long time … just use the thing that will work everywhere.

User experience over just appearance

While you are considering older browsers and attempting to give them the same experience, you are potentially including unnecessary declarations. Vendor prefixes and extra classes to target IE8 are nice hacks, but they are just that – hacks. Older browsers were not meant to support flexbox, columns and pseudo elements, because they were not originally built to support these features.

When you attempt cross-browser compatibility, consider what the user experience actually is. A (good) website will, more often than not, function with minimal CSS. Letting a browser use its default form appearance, or display content in one column instead of two, is a small sacrifice. Users will still be able to use the form and read the content.

I was working with a fellow designer last year, who wanted the placeholder text in forms to be the same colour in all browsers (they are light grey by default). Changing the colour in certain browsers proved to be difficult or impossible. Eventually, as a team, we decided that it was a small change that was not worth the effort, would not improve the user experience, and, quite simply – that placeholder text should not be altered from its default, due to potential accessibility issues.

Building without a CSS reset

I believe it was in one of Jonathan Snook’s SMACSS videos that he made the point of not using normalise or reset CSS as a base because “you end up overriding it anyway”. I had never tested his hypothesis until recently, but he suggested removing your normalise.css or reset.css, and seeing how much actually changed. Chances are, there will be very little that has changed. Craig Buckler also makes this suggestion, along with the advantages and disadvantages of CSS resets.

CSS resets were designed to be modified and built upon, though if you’re just launching a quick-and-dirty prototype or simple website, it may make sense to use one. It depends on the situation. At my previous workplace, we used it as a base, and just laid styles on top of it, with the idea that – if reset.css was ever updated – we could easily overwrite our copy with the updated version without needing to worry about affecting the rest of our code.

I have tested in different browsers from the day I realised other browsers existed. When you’re young, in the early 2000s, and you’ve constantly built websites and only checked in one browser (usually IE), and finally learn that other browsers exist – everything kind of becomes a big deal. Because I’ve been meticulous about that kind of thing, CSS resets seem redundant to my workflow.

Removing normalise.css from my blog

Yes, I spell in British English, so for me it is “normalise”, not “normalize”.

A few days ago I pushed an updated CSS file to my blog. I only cut the file size down a tiny bit, but by removing normalise.css, I shaved off 2KB (minified).

I noticed that a lot of elements in normalise.css were elements I didn’t even use:

• some HTML5 elements, such as hgroup and summary,
• a lot of rules for forms that I didn’t consider important because I only have a couple of simple forms on my website,
• and table rules – there are no tables on my website at all.

There were a couple of miscellaneous things I did keep, but it’s true that a lot of it was overridden by my own rules, and normalise.css was just sitting under the rest of my code serving no good purpose.

Are CSS resets really necessary?

While I do have my own opinion on frameworks in general (an opinion many will disagree with), and prefer to avoid them, I feel that CSS resets fall into an ambiguous category. Boilerplates and frameworks like Bootstrap, as well as JavaScript tools, have an obvious template or base. They tend to work right out of the box, with the results immediately visible.

CSS resets don’t provide much presentation, and aren’t a “complete” framework, considering CSS is just one ingredient of an complete website. They are easily lost under everything else, and don’t really perform as a fire blanket or safety net the way other types of frameworks do.

I would go so far as to not call it a framework, not even a tool, but just a guide. A guide that can provide reference for what you may want to include in your CSS – but is entirely optional.