A stylesheet, end to end

A page with nothing, and a checklist

This is the exam that is not an exam. The page below has structure and no style at all; the stylesheet is empty. Everything needed to make it good has been covered — and the order to do it in is the order the course taught.

Style from the outside in: the page first (font, spacing, measure), then the components (cards, buttons), then the states and the smaller screens. Changing the page after the components means restyling the components.

The checklist is ordered on purpose. A page that is readable before it is decorated will stay readable when the decoration changes, and a page whose components come first tends to inherit whatever the first component happened to need. Work down the list once, then make a second pass for the details the list cannot see: alignment, rhythm, the way a heading sits above its paragraph.

The checklist

• A font stack and a comfortable line height on the body.
• A capped reading width, so lines stay between 60 and 75 characters.
• Space using padding and gap, not guesses.
• A layout for the cards — flex or grid — that works at 360 pixels and at 1440.
• One media query where the layout genuinely has to change.
• States for anything interactive: hover, and a visible focus ring.
• Colours with enough contrast, and no more than a small, named palette.

The order is the cascade

Styling the page first is not a ritual. Font, colour, line height and spacing on body are inherited by almost everything, so every component you write afterwards starts from the right defaults. Style the cards first and you spend the rest of the file overriding choices that should have been made once.

Keep specificity low for the same reason. A class on the component beats an element selector, and a descendant selector adds weight you will have to match later. If a rule will not apply, fix the selector rather than reaching for !important — the next rule will need it too.

Layers you can read

A stylesheet that is easy to change has an order you can name: custom properties, a base or reset, the page shell, components, states, and queries. Comments marking those sections are not decoration; they are how the next person finds the rule that owns a value.

Within a component, write the layout first, then the surface, then the states. That is also the order a reader expects to find them, so the shape of the component is visible before its decoration. A file organised this way makes the cascade an ally instead of a series of surprises.

A pass through the file

The first pass is the page: body gets the font stack, the line height, the text colour and the padding, and main gets a max-width in ch. Nothing here is specific to a component, which is the test of a page-level rule — if it would still be true on a different page of the same site, it belongs at this level.

The second pass is the layout: the cards become a grid, the header becomes a flex row at its breakpoint, and the gaps come from gap rather than from margins on each child. The third pass is the surface — background, border, radius, padding — and the fourth is the states: hover, focus, and whatever a pressed control should look like. Each pass only adds; none of them has to undo the one before.

The last pass is the narrow window. Set the width to 320 pixels and read the page as a reader would, then press Tab from the top and watch the focus ring move. Those two checks find the problems a wide screenshot hides, and they are the ones worth doing before the file is called finished.

Try these next

• Add a print block that hides the navigation and turns the palette black on white.
• Move every colour and spacing value into custom properties, then change the accent once.
• Check the page at 320, 768 and 1440 pixels, and write down one fix for each width.

Before you call it done

Narrow the window until the layout is phone-sized and check that nothing overlaps, nothing is cut off, and the buttons are still comfortable to hit. Press Tab through the page: every control should show where the keyboard is. Zoom to 200% and confirm the text does not collide with itself.

Then read it. If the page makes you want to turn the line height down or the sizes up, do that — CSS has no compiler to argue with, only readers.