Written by Harry Roberts on CSS Wizardry.
Shaun Rashid’s 2015 article Normalize (CSS) No
More has been
making its way round the Twittersphere again recently, and it’s brought a few
questions to my mind. This post isn’t a direct rebuttal or criticism of Shaun’s
article, but rather my own take on things in the form of a response.
In Shaun’s article, the argument is made that normalising CSS (specifically via
Normalize.css, but presumably the
argument extends to anything of its ilk, like a more traditional reset) goes
against the philosophy that websites do not need to look the same in every
browser: a stance
we fought very very hard to achieve. Whilst I absolutely agree that websites do
not need to look the same in every browser—doing so is very time consuming,
usually very frustrating, and seldom worth the time or effort—this argument is
made on a false assumption: that Normalize.css exists to make websites look the
same in every browser.
When we talk about making websites look the same in every browser, we’re
usually discussing the fact that it’s okay for round corners to be absent in
browsers that don’t support border-radius, or that we can live with subtle
layout shifts from one browser to another, or that we can progressively enhance
visual features where possible. This is something I agree with wholeheartedly.
When we talk about Normalize.css, we’re not talking about making websites
look the same in every browser, we’re talking about providing a consistent and
bug-free baseline. We’re talking about making a consistent baseline to make
development easier. Normalize.css isn’t for our users or our clients, it’s for
us as developers. We should always put the user first, but developer convenience
is still a thing.
From Nicolas’ article in which he introduces
Normalize.css:
Resets impose a homogeneous visual style by flattening the default styles for
almost all elements. In contrast, [N]ormalize.css retains many useful default
browser styles.
So please, do keep using Normalize.css. It makes your life easier, and with an
absolute minimal overhead: v5.0.0 is a mere 984 bytes after gzip. For context,
that represents less than 1.3% of the average CSS
project.
Or, at the very least, try not to dismiss it based on an incorrect
understanding.
Leave a Reply