The cascade is a negotiation: specificity, layers and CSS architecture

A stylesheet is not a description of how a page looks. It is a set of claims about properties, each attached to a selector, and the browser decides which claim holds. An author who writes border: none has not removed a border. The author has entered a claim that other claims may outrank. Styling on the web is therefore not the application of a visual design. It is the resolution of a conflict between three authorities: the user agent, the user and the author. The maintainability of a stylesheet is a property of how that conflict is arranged. The strongest counter to this unit's thesis is that the arrangement is already settled by convention. Lazaris (2011), Snook (n.d.) and Stepanova (2012) hold that a naming discipline over selectors is the whole remedy. Specificity is a pure function of the selector (W3C, 2026), so a selector convention is a cascade convention. Unit 2 showed what the markup means. This unit shows what happens when two rules claim the same property.

A claim, not a coat of paint

The cascading module states that CSS attempts to balance power between author and user style sheets (W3C, 2022). Three parties write declarations for the same document. The user agent supplies defaults, the author writes the site stylesheets, and the user may write a stylesheet through browser or system settings (Mozilla Foundation, n.d.). An author who does not know the order of resolution cannot predict their own page's rendering.

Work one claim through that order. An author writes p { font-size: 14px !important } to stop a template shrinking their text. A reader who needs larger text runs a user stylesheet containing p { font-size: 20px !important }. The reader wins, because importance inverts the usual relationship: an important user declaration outranks an important author declaration.

Work the separation on one page. CSS Zen Garden collects designs for a single unmodified HTML document, and its rules state the demonstration plainly. A participant may change the stylesheet in any way and may not touch the markup (Shea, 2003). The markup holds still, and the cascade is the price of that separation.

Three authorities and one fixed order

The specification lists the precedence of origins in descending order: transition declarations, important user agent declarations, important user declarations, important author declarations, animation declarations, normal author declarations, normal user declarations, normal user agent declarations (W3C, 2022). Normally the author wins, because a normal author declaration beats a normal user declaration. Among important declarations the user outranks the author, and the user agent outranks both.

The specification calls this an accessibility provision, because it gives users with larger-text or reduced-motion needs control over presentation. A user's important declaration therefore beats the author's important declaration for the same property (W3C, 2022). Below origin and importance sit the criteria an author usually has in mind: layer, then specificity, then order of appearance (Mozilla Foundation, n.d.). The browser consults specificity only after origin and layer are settled.

Specificity as arithmetic over three columns

Specificity is a weight computed from a selector, and it is written as three columns: identifiers, then classes, attributes and pseudo-classes, then element types and pseudo-elements (Mozilla Foundation, n.d.). Selectors Level 4 defines the same triple and fixes the comparison: left to right, decided at the first difference (W3C, 2026). The columns are not digits, so no quantity of classes overtakes an identifier. A class selector scores 0-1-0, and a type selector scores 0-0-1 (Mozilla Foundation, n.d.). The language also allows a match that costs nothing, because :where() contributes no weight (W3C, 2026).

Work one collision. An author writes .card .title { background: pink } and, lower in the file, .title { background: teal }. The later rule still loses. The first selector scores 0-2-0 and the second scores 0-1-0, and the three columns are compared left to right, so the class column settles the collision before source order is read. Rewrite the first selector as :where(.card) .title and :where() contributes no weight, so the score drops to 0-1-0. That hands the tie back to the later teal.

Layers move the argument out of the selector

Layers are the newer mechanism, and the specification describes their purpose in the language of the balance of power. Origins balance user and author styles, while layers provide a structured way to balance concerns within a single origin (W3C, 2022). Rules in one layer cascade together and do not interleave with rules outside it, so an author can re-order layers explicitly (W3C, 2022).

Declarations outside any layer take precedence over declarations inside a named or anonymous layer, even where the unlayered declaration has lower specificity and appears earlier (W3C, 2022; Mozilla Foundation, n.d.). Layer order then decides between layers. The last declared layer wins for normal declarations, and the priority reverses for !important, so an important declaration inside a layer beats one outside (Mozilla Foundation, n.d.). A vendor stylesheet can therefore be placed in a layer and made to lose gracefully, while a legacy unlayered rule of the author's own beats everything tidied into a layer.

Work one import. A site loads a third-party widget sheet and wraps it as @layer vendor { .btn { background: grey } }. The site keeps an unlayered rule of its own, .btn { background: teal }. Specificity is equal, and the unlayered rule still wins, because anything outside a layer outranks everything inside one. Declaring @layer reset, components and writing each set in its own layer restores control the other way. At equal specificity the components beat the reset, and no selector was rewritten to achieve it.

The maintenance evidence counts stylesheets, not architectures

The empirical literature measures stylesheets as they are, and does not test architectures. Mazinanian, Tsantalis and Mesbah (2014) built a technique that detects three kinds of declaration duplication. It recommends refactorings whose preconditions preserve the rendered result, and the authors evaluated it on 38 real-world web systems and 91 stylesheets, where duplication was widely prevalent. Their framing is that inheritance, cascading and specificity make CSS hard to maintain.

Three further studies measure adjacent ground. Mazinanian and Tsantalis (2017) present CSSDev, a tool suite that detects refactoring opportunities. They state it as a response to CSS still lacking adequate tool support for everyday maintenance. Charpentier, Falleri and Reveillere (2016) extract reusable mixins automatically from existing stylesheets. They evaluate the approach on more than a hundred stylesheets, and cite projects of several thousand lines with weak support for reuse. Bleisch (2018) collected stylesheets from several hundred sites built with each of 19 frameworks, identified the framework from CSS smells with 39 per cent accuracy, and found the smells highly prevalent.

Architecture by convention where the language gives none

The canonical architectures are answers to that diagnosis, and they are conventions rather than platform features. Object-oriented CSS rests on two principles: separating structure from skin, and separating containers from their content. Repeated features then become reusable modules rather than one-off rules (Lazaris, 2011). SMACSS categorises rules as base, layout, module, state and theme, each with its conventions, and it calls itself more style guide than framework (Snook, n.d.). BEM came out of Yandex, where a naming convention was sketched around 2007. It names blocks, elements and modifiers, so a class reveals its origin and, with it, a predictable selector (Stepanova, 2012). All three constrain what an author may write, and the constraint is a convention.

Contested question: discipline by convention, or remedy in the language?

The literature disagrees about where the remedy lies, and both positions sit in this unit's sources. The practitioner frameworks hold the convention position: predictability comes from the naming and categorisation an author imposes. Its technical warrant is that specificity is a function of the selector, so a selector convention is a cascade convention (Lazaris, 2011; Snook, n.d.; Stepanova, 2012). The language and tooling position holds that the remedy belongs to the platform and to tools. The specification provides layers so authors can re-order the cascade explicitly without altering specificity (W3C, 2022), and the research papers treat the problem as engineering that tools address (Mazinanian and Tsantalis, 2017; Charpentier et al., 2016).

The two positions predict different things. If convention is sufficient, stylesheets following one of the frameworks should cost less to change than stylesheets that do not. The difference should then be attributable to naming rather than tooling. If the language is doing the work, an explicit layer order should reduce change cost whether or not selectors were flattened. What would settle the question is a study that takes comparable stylesheets, one organised by convention and one by layers, and measures time to make a specified change, regressions and duplication introduced, across several developers. No such study is in this unit's sources. Mazinanian and colleagues (2014) count duplication and Bleisch (2018) counts smells, and neither compares architectures. The frameworks report no evaluation.

While the question is open, a designer should keep the cascade legible by whichever route the team can enforce. Put third-party styles in a named layer, declare the layer order at the top, and keep the author's own unlayered rules few. Prefer the selector with the lowest weight that does the job, and record in the code why a rule outranks another.

Where the argument is heading

Two directions are visible. The first moves management of the cascade from memory into the declaration itself. Layers are in the specification as a way to order concerns explicitly (W3C, 2022), and they reached browsers in March 2022 (Mozilla Foundation, n.d.). The second moves management into machines. Duplication detection, automated refactoring and mixin extraction repair the cascade's cost automatically (Mazinanian and Tsantalis, 2017; Charpentier et al., 2016). If both continue, the naming conventions this unit treats as architecture may come to look like a workaround of a period that offered nothing better.

The sources this unit rests on

• W3C (2022). CSS Cascading and Inheritance Level 5. W3C Candidate Recommendation Snapshot, 13 January 2022. https://www.w3.org/TR/css-cascade-5/ It fixes the order in which competing declarations are resolved by origin, importance, layer, specificity and order of appearance, and introduces cascade layers. Being normative, it says what the cascade must do rather than how it works in practice, and its open issue list shows unlayered styles are still under discussion.
• W3C (2026). Selectors Level 4. W3C Working Draft, 22 January 2026. https://www.w3.org/TR/selectors-4/ It defines selector syntax and the three-column specificity score, including the left-to-right comparison and the fact that :where() adds no weight. It is the normative source for this unit's worked calculation, so it says how the score is computed, not what it costs.
• Mozilla Foundation (n.d.). Specificity. MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Cascade/Specificity It states the three weight columns, that specificity is consulted only after origin and layer, and that a source-order tie goes to the later declaration. It documents current browser behaviour rather than measuring its consequences, so it explains an outcome without evaluating it.
• Mozilla Foundation (n.d.). @layer. MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/CSS/@layer It documents the at-rule that declares named and anonymous layers, states that unlayered styles override layered ones and that the last declared layer wins, and records that important declarations reverse that order. It dates the mechanism as recent, with support reaching browsers in March 2022.
• Mazinanian, D., Tsantalis, N. and Mesbah, A. (2014). Discovering refactoring opportunities in cascading style sheets. Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. doi:10.1145/2635868.2635879 They detect three types of declaration duplication and recommend refactorings that preserve the rendered result, evaluated on 38 real-world web systems and 91 stylesheets, where duplication was widely prevalent. It is the strongest evidence that the cascade creates countable maintenance cost, while the maintainability gain is expected rather than measured.
• Mazinanian, D. and Tsantalis, N. (2017). CSSDev: Refactoring Duplication in Cascading Style Sheets. 2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE-C). doi:10.1109/icse-c.2017.7 They present CSSDev, a tool suite that analyses CSS to detect refactoring opportunities, motivated by the claim that CSS lacks adequate tool support for everyday maintenance. It is a tool rather than a user study, which is the position the unit reports.
• Charpentier, A., Falleri, J. and Reveillere, L. (2016). Automated Extraction of Mixins in Cascading Style Sheets. 2016 IEEE International Conference on Software Maintenance and Evolution (ICSME). doi:10.1109/icsme.2016.15 They extract mixins automatically from existing stylesheets to help projects migrate to preprocessor languages, evaluating the approach on more than a hundred stylesheets and citing projects of several thousand lines with weak support for reuse. Its evidence is technical performance rather than developer outcomes.
• Bleisch, T. P. (2018). An Empirical Study of CSS Code Smells in Web Frameworks. Master's thesis, California Polytechnic State University. doi:10.15368/theses.2018.105 Bleisch collected stylesheets from several hundred sites built with each of 19 frameworks and identified the framework from CSS smells with 39 per cent accuracy, with smells highly prevalent. It supports the claim that CSS authoring is difficult in practice, though as a master's thesis it weighs less than the peer-reviewed work.
• Lazaris, L. (2011). An Introduction to Object-Oriented CSS (OOCSS). Smashing Magazine, 12 December 2011. https://www.smashingmagazine.com/2011/12/an-introduction-to-object-oriented-css-oocss/ The article sets out the OOCSS principles of separating structure from skin and containers from their content, crediting Nicole Sullivan as the originator, so repeated features become reusable modules. It is a practitioner argument with no evaluation, and the clearest statement of the convention position.
• Snook, J. (n.d.). SMACSS: Scalable and Modular Architecture for CSS. Online book. https://smacss.com/ The book categorises rules as base, layout, module, state and theme, with conventions for each, and describes itself as a style guide rather than a framework or a library. It offers a discipline where the language supplies none.
• Stepanova, V. (2012). BEM: A New Front-End Methodology. Smashing Magazine, 24 April 2012. https://www.smashingmagazine.com/2012/04/a-new-front-end-methodology-bem/ The article presents block, element and modifier naming as developed at Yandex, where the convention dates from around 2007 and became the basis of an internal component library. Its claim is that a class name makes a style's origin legible and its selector predictable, and it reports no measured evaluation.
• Shea, D. (2003). CSS Zen Garden. Online demonstration. https://csszengarden.com/ The site collects designs for one unmodified HTML document, and its submission rules allow the stylesheet to change in any way while forbidding changes to the markup. It is a demonstration rather than a study, and the strongest case for the separation of content from presentation.