normalize.css: the rules it adds back, and the controls it tells you not to touch

The last commit is dated 2024-06-12 and the support list still names Internet Explorer 10+

The repository's last push is dated 2024-06-12, and there are no GitHub releases behind it, so there is no tagged history to compare a current build against. What you get instead is a support list: Chrome, Edge, Firefox ESR+, Internet Explorer 10+, Safari 8+, and Opera. That list is the honest signal about the project's age, because an Internet Explorer 10 baseline and a Firefox ESR floor describe a compatibility target that was set years before today's browsers, and nothing in the repository updates it. What the project cannot offer is a maintained browser support promise, and this matters more than it would for a runtime dependency, because a stylesheet's whole job is browser behaviour. If you ship to a defined browser set, read that list as a floor you inherit, not as a current guarantee, and re-check the form control rules yourself.

npm install resolves to a stylesheet, and the manifest ships nothing else

The manifest is unusually plain. Both the main and the style fields point at the same file, normalize.css, and the files array contains exactly two entries, LICENSE.md and normalize.css. There is no build script, no dependency list, and no compiled or minified output, because there is nothing to compile: the stylesheet is the product, and its version reads 8.0.1. The consequence for a consumer is that the entry point your bundler resolves is CSS rather than a module exporting anything, so a plain require in a Node context hands you a stylesheet, and a project that does not run a CSS aware pipeline will not get far. The upside is equally plain. There is no generated output that can drift from source, and reading the shipped file tells you exactly what is being applied.

Two of the three install paths are pointers, not pinned URLs

Only one of the three distribution routes is spelled out as a command:

npm install --save normalize.css

The other two are handed off as links to consult. For a CDN, the page points you to a package listing at yarnpkg.com, and for a direct download it points to a latest file under the project's own pages. The consequence is that the project does not document which version a CDN link serves, because the version is not part of the URL it gives you. If you pin a copy for reproducible builds, note that package.json reads 8.0.1 and that the download path is labelled latest, so the same address can hand you different bytes over time. The project's homepage sits at necolas.github.io/normalize.css, and that is where the downloadable copy lives.

The doubled monospace value is intentional, and the sub and sup line box shift never went away

The extended details exist to stop well meaning cleanups. For pre, code, kbd, and samp, the rule writes the monospace family twice:

font-family: monospace, monospace

The duplication is deliberate and it fixes inheritance and scaling of font size for preformatted text. Collapse it to a single value and the browser bug returns, which is the kind of failure that surfaces as unreadably sized code blocks months later. A second entry records that using sub or sup changes the line box height of text in browsers, with no browser singled out as exempt. The consequence for a reader is a general one: the stylesheet is dense with rules that look redundant or wrong until you know what they repair, so editing it from the top down and deleting what seems odd will undo work that took other people a long time to find. Read the comments before changing a value.

Checkboxes and radios are marked off limits because Firefox ignores box sizing on them

The entry for checkbox and radio inputs is a recommendation, not a rule, and it is blunt: do not style them, because Firefox's implementation does not respect box sizing, padding, or width. A design system that restyles every form control will hit that wall, and it will hit it in one engine while looking fine in the others, which is the worst way to find out. The neighbouring note on number inputs is a smaller version of the same trap: certain font size values applied to a number input change the cursor style of the decrement button from default to text. What the project cannot do is give you a working styled control here, and it says so. The consequence is a scope decision. If your components depend on restyled radios, normalize.css will not be the layer that makes that possible, so budget for per browser handling of those controls.

Search inputs resist styling, and the documented fix keeps the past searches list

The search input note is the longest in the repository and the most useful. By default the control is not fully stylable. In Chrome and Safari on OSX and iOS you cannot control the font, padding, border, or background at all. In Chrome and Safari on Windows you cannot control the border properly: the border width is applied, but only a border colour is shown for the outer one pixel, and that colour cannot be controlled. The documented fix is one declaration:

-webkit-appearance: textfield

It resolves those problems without taking away what makes a search input worth having, such as showing past searches. The consequence is a trade you accept knowingly. You get a control you can restyle and you keep the history affordance, at the cost of vendor prefixed CSS in your own stylesheet, and in exchange the project hands you no answer for checkboxes.

The file is a bug fix list with comments, not a design vocabulary

Five claims define the scope, and only one of them is about taste. It preserves useful defaults, unlike many CSS resets. It normalizes styles for a wide range of elements. It corrects bugs and common browser inconsistencies. It improves usability with subtle modifications. It explains what code does using detailed comments. Read together, that is a bug fix list with documentation attached, and there is no typography scale, spacing scale, colour decision, or utility class anywhere in it, nor anything in the files array beyond the stylesheet and its licence. The consequence is that normalize.css cannot answer how your interface should look, only how browsers disagree at the baseline. Pair it with your own decisions. Repository wise, the visible files are a test.html page, a .travis.yml, a CHANGELOG.md, and a CONTRIBUTING.md, and the manifest declares no test command, so checking behaviour looks like opening that page rather than running a suite.

Editorial conclusion

normalize.css earns its place in a fresh project when you want one commented stylesheet that fixes browser inconsistencies without stripping your defaults. Skip it if your framework already normalizes for you, or if you need a compatibility matrix someone keeps current, because the last commit landed on 2024-06-12 and the stated support list still names Internet Explorer 10+. Before adopting, read the extended details on form controls, because several of its own rules tell you not to style the things a design system will reach for first.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository