Using Normalize.css For Homogeneous Development

Browser compatibility is a big part of accessibility on the web. Developers need to consider the variance of their audience and browser versions that require support. Although CSS resets are an option, most devs prefer Normalize.css for its simplicity and cross-compatibility throughout all modern web browsers.

normalized.css

In this post I’ll cover the basics of Normalize and how it compares to general CSS resets. This isn’t a complicated library and it shouldn’t take more than a couple hours to understand. But the key to Normalize is learning how to implement it properly and judiciously.

Browser Resets vs. Normalize

For years I’ve used a customized version of Eric Meyer’s CSS resets. These have been enough for most of my projects and haven’t caused any major issues. However Normalize changed my view of resets because it works differently than a CSS reset. It’s important that you understand the differences.

Think of Normalize as a garment applied consistently to all browsers, and think of a CSS reset as a thermonuclear detonation across all browsers.

Normalize styles and formats headings, paragraphs, blockquotes, and common elements so they appear identical (or close enough) in all supported browsers. CSS resets completely wipe the slate clean so there are no defaults for anything.

With a CSS reset your headings can look the same as your paragraphs; elements have no padding, margins, or spacing of any kind. With a CSS reset you must supply new code to enhance the style. With Normalize you get a pre-designed style which can be built upon.

So is one of these better than the other? It’s a hotly debated topic, although one point of argument states that Normalize works better for compatibility and produces smaller file sizes.

“I would have to argue that normalization is better than resetting. It will result in less CSS being transferred across the wire, better use of UA defaults, and a better understanding of how elements are meant to display.”

Whether you fall in love with Normalize or prefer a typical reset, it’s important to at least understand both sides and pick whatever fits best. Very few developers start coding from scratch so Normalize or a CSS reset is almost required for modern frontend development.

If you want to try a CSS reset here are some popular choices:

Normalize Config

Normalize creator Nicolas Gallagher wrote an introductory post leading with this statement:

“Normalize.css is a small CSS file that provides better cross-browser consistency in the default styling of HTML elements. It’s a modern, HTML5-ready, alternative to the traditional CSS reset.”

Over the years this has grown into a trusted library used by developers worldwide. Normalize has even been used to some degree in Bootstrap and Pure CSS.

There are two ways to use Normalize in a project: edit the source to customize your own Normalize stylesheet, or use it as a base and add styles on top.

The former is a pick-and-choose strategy where you go through the Normalize.css file and delete whatever you don’t need to make your own custom stylesheet. This is best on a per-project basis to keep the filesize low.

Alternatively some developers include the whole Normalize.css file and build their own stylesheet on top of that. The full Normalize stylesheet spans 420+ lines of code which equates to ~6.8KB uncompressed.

Neither method is better than the other and it’s worth following whatever works best for each project, or your preferred workflow.

To get started either download a copy of Normalize from GitHub or host it from an external CDN. You can also pull the latest version of Normalize right from NPM like so:

npm install --save normalize.css

If you don’t want to download any files you can even make a new CodePen project which can append Normalize at the click of a button.

codepen screenshot normalize

Because Normalize is modular, you can remove sections temporarily or even make your own custom build of Normalize. Then you can start each project with select portions like the HTML5 display elements while removing styles for embedded content.

Each Normalize rule has a corresponding CSS comment explaining what it does and which issues/bugs it solves. Some are obvious like setting display:block on newer HTML5 elements.

Others are less obvious like this SVG code which hides overflow in Internet Explorer:

svg:not(:root) { 
  overflow: hidden; 
}

I highly recommend skimming the stylesheet to see exactly how it operates and to learn if Normalize would be right for your project.

Normalize.css In Web Design

The newest version of Normalize v4.0 offers widespread browser support.

  • Chrome (last two)
  • Edge (last two)
  • Firefox (last two)
  • Firefox ESR
  • Internet Explorer 8+
  • Opera (last two)
  • Safari 6+

From what I can tell, Normalize may support older versions of browsers with constant updates like Firefox. But the “official” support only includes the two most recent versions of Chrome/Edge/FF/Opera.

Also IE6+ and Safari 4+ are supported with Normalize v1, but that version is no longer updated.

It’s crucial that you check browser versions with a tool like Google Analytics. This will give you a better idea whether Normalize can be a useful tool for modern web design work.

Further Resources

There isn’t a whole lot to specifically teach about Normalize so most of the learning happens by doing.

And truthfully there’s not much to explain that you can’t pick up by reading through the stylesheet and copying/altering code as needed. But if you’re looking for other relevant info I’ve added some links below.

Related Articles

Intro Videos