A list of a thousand comments renders slowly, so you reach for react-window – and in exchange for smooth scrolling you lose Ctrl+F, page printing, and part of screen-reader navigation, because elements outside the window stop physically existing in the DOM. content-visibility solves the same problem differently: elements stay in the DOM, the browser simply skips the expensive layout and paint work for them until they're near the visible area – and, surprisingly, it can temporarily reveal them when you search for text inside.
In the accessibility article, a modal built with display:none that still lingered in the accessibility tree was an example of a mistake that comes from building a modal from scratch out of divs. The real question is: why did it have to be built from scratch at all? I look at what native <dialog> and the popover attribute give you for free – top layer, focus trapping, light dismiss – and where these two mechanisms differ just enough that mixing them up is a quick path to an inaccessible interface.
The utility class .mt-4 loses to the rule .card .card__header .card__title, even though it logically should win, since it was added later. That's not an accident — that's specificity doing exactly what it was designed to do. @layer introduces an entirely new axis for resolving conflicts, one that runs before specificity, not alongside it — and it has one pitfall so unintuitive that even some documentation on the web gets it wrong.
A form field should highlight red when the input inside it is invalid. Simple enough — except CSS spent 25 years unable to ask an element about what's happening inside it, only the reverse. I look at how :has() flips that direction, how it differs from ordinary combinators, and where this new power genuinely costs you performance.
The same product card looks great in a grid and falls apart in a narrow sidebar — despite carefully tuned media queries. The problem isn't in your code, it's in the question a media query asks: about screen width, not about the space the component actually got. I look at how container queries move that question to where it should have been asked all along, and what actually happens under the hood when an element becomes a 'query container.'
CSS Houdini isn't a single technology — it's a collection of specifications at very different stages of maturity. Find out which part of it is actually production-ready today, how @property and the paint worklet really work, and why the rest is still experimental.
