In CSS, what is the difference between a reset stylesheet and a normalize stylesheet, and where in a project's stylesheet order does it belong?

## What browser defaults actually are Every browser ships a **user-agent stylesheet** — CSS the browser applies before yours. It is why an unstyled `<h1>` is large and bold, a `<ul>` is indented with bullets, and the page content does not start flush against the window edge. Typical declarations look like `body { margin: 8px }`, `h1 { font-size: 2em; margin-block: 0.67em }`, `ul { list-style: disc; padding-inline-start: 40px }`. These defaults are useful — an HTML document with no CSS at all is still readable — but they were never designed for your layout, and the exact numbers have historically differed between engines. Reset and normalize stylesheets are the two answers to that. ## The reset approach: erase A classic reset (Eric Meyer's `reset.css` is the canonical example) lists a large set of elements and flattens them: ```css html, body, div, span, h1, h2, h3, p, ul, ol, li, table, form { margin: 0; padding: 0; border: 0; font: inherit; vertical-align: baseline; } ``` You now start from a blank slate: nothing has spacing, nothing has a size, and everything renders at the inherited font. The tradeoff is that the erasure is indiscriminate. `font: inherit` also resets `font-weight` and `font-style`, so `<strong>` stops being bold and `<em>` stops being italic until you put them back. A reset therefore *requires* a base layer after it that restores the typography you actually want. ## The normalize approach: even out `normalize.css` (Nicolas Gallagher) takes the opposite stance. It preserves defaults that are worth keeping and targets only the specific elements and properties where browsers behave inconsistently or badly. Each rule carries a comment saying what it corrects. Nothing is flattened wholesale, so bold stays bold and lists stay lists, and you write less CSS to get back to a normal-looking document. The cost is the mirror image: you inherit a set of defaults you did not choose. If your design system says headings have no default margin, normalize will not do that for you. ## The modern middle ground Most teams now write a short reset of their own — a dozen or so rules, opinionated, entirely readable. Widely-copied versions (Andy Bell's and Josh Comeau's are two well-known published examples) tend to include: ```css *, *::before, *::after { box-sizing: border-box; } body, h1, h2, h3, p, figure, blockquote, ul, ol { margin: 0; } body { min-height: 100vh; line-height: 1.5; } img, picture, svg, video { display: block; max-width: 100%; } input, button, textarea, select { font: inherit; } ``` That last line matters more than it looks: form controls do not inherit the page font by default, so without it your buttons and inputs render in a browser-chosen font that does not match anything else on the page. ## Where it goes in the order The reset is the **first** thing in your stylesheet order, before base element styling, before components, before utilities. Two reasons: 1. **Cascade order.** Among declarations of equal specificity, the later one wins. Everything you author afterwards is meant to beat the reset, so the reset must come first. 2. **Specificity by construction.** A reset uses bare element selectors (specificity 0-0-1) or the universal selector (0-0-0). A component rule using a single class (0-1-0) already outranks it, so you never need an override hack to escape your own reset. If the project uses cascade layers, the reset goes in the earliest layer for the same reason. ## What a reset is not It is not your base layer. Page typography, the link colour, focus-visible styling, the type scale — those are design decisions and belong in a `base` file that loads immediately *after* the reset. Keeping the two files separate matters when you later upgrade or swap the reset: you want to replace the erasure without touching your typography. It is also not a performance measure. A reset is a handful of rules; adopting or dropping one does not meaningfully change how fast a page renders. Its whole value is predictability — starting every browser from the same known state so a layout bug is your bug, not a default you forgot about.