CSS Fundamentals: The Box Model, Specificity, Positioning, and Layout

Part 18 of 18 · ~4 min

Common Mistakes Worth Remembering

Every one of these is a bug this exact card had at some point in this reference, with the chapter that took it apart:

• No border-box reset in place. A fixed-width card grows past its own grid column the moment it earns any padding, because width was only ever describing the content box. (box-sizing)
• Two adjacent vertical margins treated as additive. The title-to-price gap, and the mobile "You might also like" stack, both came out smaller than the CSS seemed to promise, because the larger margin quietly absorbed the smaller one. (Margin Collapsing)
• A size set on something still display: inline. The price <span> ignored its own width entirely until it picked up inline-block. (Normal Flow)
• !important used to win an argument instead of settling it. It beat the sale-banner override for a day, then became the next person's problem to route around. (Cascade)
• Selector length mistaken for selector strength. A single forgotten ID from an old stylesheet outranked a freshly written four-class rule, despite being the shorter selector by a wide margin. (Specificity)
• A descendant selector cast wider than intended. .category-page p was written for one intro paragraph and ended up dimming every card's description on the page too. (Selectors Deep Dive)
• z-index applied to something that never got a position. The wishlist badge's 999 did nothing until position: absolute gave it a stacking context to actually compete in. (Positioning)
• transform quietly redefining what "fixed" means for its own descendants. A hover lift on the card turned it into the containing block for a toast that was supposed to sit fixed to the screen, not the card. (Stacking Contexts)
• em sizes nested inside other em sizes. The featured card's wishlist count compounded across two nested elements into something noticeably larger than either value alone suggested. (Units)
• The wrong layout model for the shape of the problem. An early draft forced the one-dimensional rail into Grid, then forced the two-dimensional grid into Flexbox — both worked, technically, and both were harder to maintain than picking correctly the first time. (Flexbox vs. Grid)
• A media query standing in for a container query. The same card read its own available width correctly in the grid and misread the viewport as its width in the rail, because those two numbers were never actually the same thing. (Responsive Design)

The same bugs, somewhere else entirely

One risk of building a whole reference around a single component: it's possible to walk away having learned "the card's bugs" instead of the actual, transferable mechanisms behind them. So here are two of the same bugs, wearing completely different clothes.

A dashboard's notification panel slides in from the side on a transform: translateX() transition, and it has its own "dismiss all" button, coded as position: fixed so it stays pinned to the bottom of the screen no matter how far the panel's own content scrolls:

.notification-panel {
  transform: translateX(0);
  transition: transform 0.2s;
}
.notification-panel .dismiss-all {
  position: fixed;
  bottom: 16px;
}

No product card anywhere in sight, and the exact same mechanism bites: because .notification-panel carries a transform, it's the containing block for its own fixed children, and "dismiss all" ends up pinned to the bottom of the panel, not the bottom of the screen — identical bug, unrelated feature.

And a settings form, stacking labeled fields vertically with no grid or flex container in sight:

.field { margin-bottom: 20px; }
.field label { display: block; margin-bottom: 20px; }

The label's margin-bottom and the next field's own top-of-block position collapse against each other exactly the way the card's title and price did, and the form ends up with noticeably less breathing room between a label and its input than the CSS appears to promise. Same rule, same fix — a Flexbox or Grid container with gap, or simply not stacking two adjacent margins that were never meant to add.

If both of those read as familiar on sight, the mechanism actually transferred — which was the entire point of building one card instead of twenty disposable examples.

---

This same box-model, cascade, and positioning machinery is exactly what a component framework like React renders on top of — see React Fundamentals for the JSX and composition side of that same relationship. And these patterns are worth actually typing out rather than only reading about — the code lab has them as runnable exercises with real feedback.