Reviewing CSS well keeps a codebase healthy and levels up the whole team. A senior reviewer looks past "does it work" to "will this scale, is it consistent, is it accessible". Here is what to check and how to give feedback that helps.
What to look for
A good CSS review runs through consistent dimensions: specificity, naming, token usage, accessibility, responsiveness and performance. A checklist makes reviews fair and thorough rather than dependent on what the reviewer happens to notice.
Catching the common smells
Specific things that should trigger a comment: a rising specificity selector, an <code>!important</code>, a raw hex where a token exists, a fixed pixel width that should be fluid, a removed focus outline, or a new component that duplicates an existing one. These are the recurring issues in most reviews.
How to give good feedback
Review the code, not the person. Explain the why ("this raises specificity, which makes future overrides harder"), suggest the fix, and distinguish blocking issues from nitpicks. The goal is better CSS and a better engineer, not just a list of complaints.
/* LGTM — it renders fine *//* checked specificity, tokens, focus, contrast, responsiveness */Approving CSS just because it looks right in the browser, ignoring specificity, tokens and accessibility. Reviews must look past the visual result to maintainability.
Review against a consistent checklist (specificity, naming, tokens, a11y, responsiveness, performance), explain the reasoning behind each comment, and separate blocking issues from nitpicks. Consistency in review produces consistency in code.
Take a chunk of CSS — your own or any sample — and review it against the checklist above. Note every issue you find and write one constructive comment for each, explaining the why and the fix.
1. Why use a review checklist?
2. Which should trigger a review comment?
3. Good feedback…
- Review for specificity, naming, tokens, a11y, responsiveness, performance.
- Watch for smells: !important, rising specificity, raw values, removed focus.
- Look past "it renders" to maintainability.
- Explain the why, suggest fixes, separate blocking from nitpicks.