Menu

1 / 2

Why I spent years trying to make CSS states predictable

DEV Community·Andrey Yamanov·6 months ago
#q2PmuEiO
#primary#css#webdev#surface#frontend
Reading 0:00
15s threshold

Have you ever changed the order of two CSS rules and broken a component without changing the logic?

.btn :hover { background : dodgerblue ; } .btn [ disabled ] { background : gray ; }

Enter fullscreen mode

Exit fullscreen mode

Both selectors have specificity (0, 1, 1) . When a button is both hovered and disabled, the browser falls back to source order. If the :hover rule comes last, the disabled button turns blue. If the [disabled] rule comes last, it stays gray.

That looks like a small edge case, but it points to a bigger problem: component state in CSS often works by overlap.

With only one or two states, that overlap feels manageable. Add :hover , :active , disabled , dark mode, breakpoints, data attributes, container queries, and overrides, and you are no longer just writing styles. You are maintaining a state-resolution system in your head.

I kept running into this while building component systems: real buttons, inputs, panels, dropdowns, and design-system primitives.…

Continue reading — create a free account

Join HashtagPLUS to read full articles, follow hashtags, vote, and join the conversation.