Notas de campo: la resolución de la cascada, de principio a fin

The article on Thursday detailed the order in which a browser resolves CSS conflicts: first origin and importance, then layer order, followed by specificity, and finally the source order, with inheritance below all of that. Describing an order is one thing; seeing it work in a real conflict is another. This is what it looks like.

The setup is simple: a button. Six declarations compete for the same property, covering each stage of the resolution sequence: UA stylesheet — browser default, author, @layer base (declared first), author, @layer utilities (declared after base), author, unlayered, #submit with a class of btn and text-blue, and finally button with id=submit and class=btn text-blue. What color wins?

Stage one: Origin and importance. This step is checked before consulting any other rules in the list and ends the conflict immediately. The green color (green) wins. It's not because it's the most specific selector. It's not even that specific - a simple selector like button is as generic as you can get. It wins because a user-origin !important (one with a user origin) overrides an author-origin !important (one with an author origin).

This is the only point where the usual logic flips: the user usually outranks the author. Why is the platform built this way? The reason is short and solid: sometimes users need a way to override author styles that might harm them. Whether a site specifies text that's too small to read, or a color combination that doesn't meet their contrast needs, if an author's !important always overrides a user's !important, that override would be impossible, no matter the browser settings or assistive technology.

Accessibility adjustments must retain their authority. That's why the cascade gives the final word to user !important, specifically to ensure that rule is followed. It's not an extreme edge case hidden in the specification. It's the very reason for this stage of the algorithm.

Stage two: Layer order. Eliminating the two !important overrides, the user's and the author's, we see what remains: four normal importance declarations spread across the user stylesheet stylesheet (UA stylesheet), two author layers (authored layers), and a rule without a layer (unlayered). The layer order resolves this before reaching specificity.

The unlayered #submit { color: red; } rule outranks any layered rule, without conditions. Red wins this round. For a moment, set aside the unlayered rule. The comparison becomes more interesting: base .btn compared to utilities .text-blue. Since utilities was declared after base, .text-blue would have won. Not because blue has a more specific selector than black - both are individual classes - but because the layer it resides in was declared later.

This is exactly the mechanism described in the article on Cascade Layers, now operating on real stages of the algorithm rather than being analyzed in isolation.

Stage three: Source order, in isolation. To simplify further, let's consider two identical layers, same specificity, and two declarations that only differ in which appears later in the file: @layer base { .btn { color : black; } .btn { color : navy; } }. The navy blue (navy) wins. There was nothing else available to decide, so the algorithm falls back to the last step: the rule that appears later in the source order (source order).

This is the step mentioned in the article 6 but never demonstrated. Here it is, isolated, doing exactly what the specification says and nothing more. What this really shows is six declarations, five distinct stages of a single sequence. Each one is only consulted because the previous ones didn't produce a decision. At the moment origin and importance resolved the external example, layers, specificity, and source order were irrelevant.

That's the real structure of the algorithm: not a sequence of tie-breakers, but a series of elimination gates. Most conflicts never surpass the first gate applicable.