The CSS Codex: The Laws of the Cascade

In every kingdom of styles, only one ruler may claim the throne.

Editor’s Note: Before becoming Part I of The CSS Codex, The Laws of the Cascade was originally published on RandomThoughtsInTraffic.com. This updated edition expands on the original article with additional lessons, practical examples, and a deeper exploration of the rules governing how CSS resolves competing styles.

The Invisible Throne

When developers first begin learning CSS, they usually encounter it as a collection of individual instructions. A selector targets an element. A property changes its appearance. A value produces a visible result in the browser. At first, the relationship seems straightforward because the browser appears to simply follow instructions and render a page. For small projects, that mental model is often sufficient. Stylesheets remain relatively simple, interactions are limited, and conflicts rarely attract much attention.

As projects grow, however, developers eventually discover that CSS is not merely a language of instructions. It is a language of decisions. Multiple rules begin targeting the same elements. Components interact with one another in unexpected ways. New features introduce additional layers of complexity. A declaration that appears correct fails to produce the expected result, while another declaration succeeds. The browser seems to be making choices, and those choices are not always obvious.

I have seen this frustration countless times. Developers who are perfectly comfortable working with databases, APIs, and application logic suddenly find themselves fighting a stylesheet. They inspect elements repeatedly, add increasingly specific selectors, rearrange declarations, and occasionally resort to !important in hopes of forcing a result. The issue is rarely a lack of technical skill. More often, it results from viewing CSS as a collection of properties rather than as a system governed by rules.

This week of The CSS Codex is called The Laws of the Realm because understanding CSS begins with understanding those rules. Before we discuss layout systems, architecture, maintainability, design systems, or scalability, we must first understand the mechanism that resolves conflicts. Every declaration participates in that mechanism. Every browser follows its rules. Every styling decision ultimately passes through it. That mechanism is known as the cascade.

The cascade is often treated as though it were merely another CSS feature. In reality, it is closer to the kingdom’s system of governance. Every selector, declaration, and property operates within its jurisdiction. When conflicts arise, the cascade determines which instructions take precedence and which must yield. Understanding that process transforms CSS from a source of mystery into a system that behaves with remarkable consistency.

Understanding the Physics Engine of CSS

Throughout this week, our theme is Understanding the Physics Engine of CSS. The comparison is intentional because physics engines govern how virtual worlds behave. A character in a role-playing game can run, jump, climb, and interact with the environment, but those actions only make sense because the game consistently applies rules governing gravity, movement, collision, and momentum. Players rarely think about those systems directly, yet every action depends upon them.

CSS operates in a similar manner. Most developers focus on the visible results of their work. They care about layouts, typography, colors, spacing, responsiveness, and visual hierarchy. Those outcomes matter, but they are only the surface layer. Beneath every rendered page lies a process that determines how competing instructions interact. The browser follows that process relentlessly, even when developers are unaware it exists.

One of the most important lessons I learned as a frontend developer was that CSS expects conflicts. The language was never designed around the assumption that every property would receive exactly one declaration. Instead, it assumes multiple declarations may target the same element and provides a framework for resolving those situations. The framework is not an afterthought. It is one of the foundational ideas upon which CSS was built.

Understanding this changes the way developers think about debugging. Newer developers often ask why a style failed to apply. Experienced developers tend to ask a different question. They ask why another declaration won. The distinction may appear subtle, but it fundamentally changes the debugging process by aligning our thinking with how the browser actually evaluates styles.

Gravity does not negotiate. Collision detection does not negotiate. The rules remain consistent regardless of what a player wants to happen. The cascade behaves in much the same way. The browser is not expressing an opinion about your CSS. It is applying rules. Once developers understand those rules, the browser becomes dramatically easier to predict.

I remember inheriting a stylesheet early in my career that contained thousands of lines of CSS accumulated over many years. At first glance, it appeared completely chaotic. Colors seemed to change unpredictably. Components behaved differently depending on where they appeared on the page. Simple modifications sometimes produced unexpected results elsewhere in the application. My initial assumption was that the stylesheet had become unmanageable because it was too large.

What I eventually learned was that the browser was behaving perfectly. Every outcome could be traced back to the cascade. Every unexpected result had an explanation. The challenge was not that the system lacked rules. The challenge was that I had not yet learned how to see them. That experience taught me a lesson that has remained valuable throughout my career. Large stylesheets rarely become difficult because the browser loses consistency. They become difficult because developers lose visibility into the rules that are already operating.

A few years later, I encountered a similar situation on a different project. This time, the stylesheet was not particularly large, yet developers still described CSS behavior as random. After spending time tracing the issue, the cause once again came back to the cascade. The browser was applying the same rules it had always applied. The difference was that multiple developers had been making assumptions about which rules were winning without verifying them. That experience reinforced something I now teach regularly: when CSS appears unpredictable, the problem is usually not the browser. The problem is that we have not yet identified the rule currently governing the situation.

The goal of understanding the cascade is not merely to solve styling conflicts. The goal is to learn how the browser thinks. Once that perspective develops, debugging becomes less about experimentation and more about investigation. The browser stops feeling unpredictable because its behavior starts making sense.

A Kingdom with Many Advisors

Imagine a king seated upon a throne in the center of a great hall. Throughout the day, advisors approach and offer guidance. A military commander recommends one course of action. A royal treasurer recommends another. A guildmaster offers a different perspective entirely. Each advisor believes their recommendation deserves consideration, yet only one final decision can be made.

CSS declarations operate in much the same way. Multiple selectors may target the same element and attempt to control the same property. Consider the following example:

</> CSS

p {
    color: blue;
}

.article-text {
    color: green;
}

#featured-paragraph {
    color: red;
}

</> HTML

<p id="featured-paragraph" class="article-text">
    Welcome to the guild hall.
</p>

Three separate declarations attempt to determine the color of the paragraph. One requests blue text. Another requests green text. A third requests red text. The browser cannot satisfy all three requests simultaneously. It must choose a single winner.

Many developers initially view this situation as a problem. They see competing declarations and assume something has gone wrong. In reality, this is normal CSS behavior. The language was designed to handle these situations. The browser simply follows the rules of the cascade and arrives at a decision. Once those rules become familiar, the outcome is no longer surprising.

What makes the cascade valuable is not merely that it resolves conflicts. Its true value lies in the consistency with which it resolves them. The browser follows the same process every time. Understanding that process allows developers to predict outcomes before opening the browser, which dramatically improves both confidence and productivity.

A useful mental shift occurs when developers stop viewing declarations as commands and begin viewing them as recommendations. Every selector approaches the throne and presents its case. Some recommendations carry greater authority. Some provide more specific guidance. Some arrive later than others. The cascade exists to determine which recommendation ultimately becomes law.

This perspective may sound simplistic, but it reflects how CSS was designed to function. The language assumes multiple voices will participate in styling decisions. The browser’s responsibility is not to eliminate those voices. Its responsibility is to evaluate them consistently.

The Browser’s Decision Tree

When styling conflicts occur, the browser does not randomly select a winner. Instead, it follows a sequence of evaluations. I often encourage newer developers to think of this process as a decision tree. Each step eliminates possibilities until a single declaration remains.

The first evaluation considers origin and importance. The browser examines where declarations originated and whether any have been marked as important. If a winner emerges at this stage, the process ends. If not, the browser continues to the next level of evaluation.

The second evaluation considers specificity. Selectors are not treated equally within the cascade. Some selectors provide more detailed targeting information than others. When competing declarations reach this stage, the browser determines which selector possesses greater specificity and grants that declaration priority.

If specificity fails to produce a winner, the browser evaluates source order. The declaration that appears later in the stylesheet takes precedence. While this rule may appear simple, it plays a significant role in real-world projects and often explains behavior that initially seems confusing.

Notice how methodical this process is. The browser is not improvising. It is not making subjective judgments. It follows a structured sequence of rules designed specifically for conflict resolution. Understanding that sequence allows developers to think more like the browser itself, which is one of the most valuable skills a frontend engineer can develop.

Most CSS frustrations begin to lose their power once developers understand this decision tree. The browser is not acting mysteriously. It is not ignoring code. It is not making arbitrary decisions. It is simply applying the laws of the realm.

The First Law: Importance and Origin

The first law of the realm concerns authority. Before the browser evaluates specificity or source order, it first determines where competing declarations originated and whether any of them have been granted elevated status. This part of the cascade is often overlooked because many developers spend most of their time working exclusively with author stylesheets. Yet understanding the origin helps explain why CSS was designed the way it was.

Browsers arrive with their own default styles. Headings appear larger than paragraphs. Links receive visual treatment that distinguishes them from the surrounding text. Lists display bullets or numbers. These defaults exist because browsers provide a baseline presentation layer before developers add their own styling. Users may also contribute styles through accessibility tools, browser extensions, or custom preferences. The cascade must balance all of these competing interests while still producing a predictable result.

Importance introduces another layer of authority. Consider the following example:

</> CSS

p {
    color: blue;
}

p {
    color: red !important;
}

In this situation, the red declaration wins because it has been marked as important. The browser treats that declaration differently during evaluation, elevating its priority over competing rules. The decision occurs before specificity is even considered.

Many developers discover !important early in their CSS journey and immediately recognize its usefulness. A stubborn style suddenly begins behaving correctly. A conflict disappears. A deadline is met. The temptation to reach for it repeatedly becomes understandable. Unfortunately, repeated use often creates new problems while concealing the original cause of the conflict.

Years ago, I inherited a stylesheet containing hundreds of important declarations scattered throughout dozens of files. Every developer who had touched the project before me had solved problems the same way. Whenever a conflict appeared, another important declaration was added. The code continued functioning, but understanding it became increasingly difficult. Every new change required tracing layers of competing priorities that had accumulated over time.

The resulting stylesheet reminded me of a kingdom where every advisor carried a royal decree declaring their recommendations more important than everyone else’s. At first, such decrees appear useful. Eventually, they lose meaning because everyone possesses one. The system continues operating, but governance becomes increasingly difficult.

The lesson is not that !important should never be used. There are legitimate situations where it provides value. The lesson is that understanding the cascade usually produces better solutions. Experienced developers learn to treat important declarations as specialized tools rather than routine problem-solving techniques. When the underlying system is understood, many styling conflicts can be resolved without unnecessarily elevating authority.

The Second Law: Specificity

If the first law of the realm concerns authority, the second concerns influence. Once the browser has evaluated origin and importance, it turns its attention to specificity. This is the part of the cascade that many developers encounter early in their careers, often without realizing what they are seeing. They notice that some selectors seem stronger than others. A class overrides an element selector. An ID overrides a class selector. The browser appears to favor certain declarations, and developers begin searching for ways to increase their own influence.

Specificity exists because not all selectors communicate the same level of intent. A selector that targets every paragraph on a page makes a broad request. A selector that targets a specific paragraph within a particular context makes a more focused request. The browser treats that additional focus as meaningful information. When conflicts occur, declarations with greater specificity receive priority because they describe a narrower target.

Consider the following example:

</> CSS

p {
    color: blue;
}

.article p {
    color: green;
}

The second selector is more specific because it targets paragraphs within a particular context. If a paragraph exists inside an element with the class article, the browser chooses the green declaration. Nothing mysterious has occurred. The browser simply followed the specificity rules defined by the language.

Specificity becomes even more obvious when IDs enter the conversation:

</> CSS

.article p {
    color: green;
}

#featured-paragraph {
    color: red;
}

The ID selector possesses greater specificity than the class selector. As a result, the paragraph appears red. The browser is not choosing favorites. It evaluates competing declarations according to established rules and selects the one with greater influence.

One of the most useful mental models for specificity is to think of it as precision rather than power. Developers often speak about selectors being stronger or weaker, which encourages the idea that specificity is a contest. In reality, specificity measures how precisely a selector identifies its target. The browser assumes that more precise instructions should generally receive greater consideration.

This distinction becomes important because developers who think in terms of power often create architectural problems. Developers who think in terms of precision tend to create maintainable systems. The cascade was designed to reward clarity. It was never intended to encourage arms races.

The Trap Hidden Beneath the Dungeon

One of the most common mistakes I see among newer frontend developers is treating specificity as a weapon. A declaration fails to apply, so they increase specificity. Another conflict appears, so they increase specificity again. Eventually, selectors become long chains of classes, IDs, and contextual relationships designed solely to overpower previous decisions.

The immediate problem disappears, which creates the illusion that the strategy is working. Unfortunately, the long-term consequences are often severe. Each increase in specificity makes future modifications more difficult because new declarations must compete against increasingly powerful predecessors. The stylesheet slowly transforms into an arms race where every new selector must be stronger than the last.

Consider the following example:

</> CSS

.card-title {
    color: navy;
}

Simple. Clear. Easy to understand.

Now imagine years of incremental changes:

</> CSS

.dashboard .reports .card .content .card-title {
    color: navy;
}

Later:

</> CSS

#main-dashboard .dashboard .reports .card .content .card-title {
    color: navy;
}

Each step may have seemed reasonable at the time. A conflict appeared. A developer solved it. Another conflict appeared. Another solution followed. Eventually, the selector itself becomes part of the problem.

I once spent the better part of an afternoon trying to understand why a seemingly harmless style change was affecting only certain pages within an application. The answer was buried beneath several generations of increasingly specific selectors. No single developer had intentionally created a problem. The complexity emerged gradually as each person solved the issue directly in front of them. Looking back through the project’s history, every decision seemed reasonable. Looking at the final result, the system had become difficult to reason about.

That experience taught me something important. Most CSS disasters do not arrive dramatically. They emerge slowly through hundreds of sensible decisions made in isolation. The specificity dungeon is rarely entered intentionally. Developers usually wander into it one override at a time.

This is why understanding the cascade matters so much. Developers who understand specificity tend to use it deliberately rather than reactively. They recognize that maintainable CSS depends less on resolving conflicts and more on preventing unnecessary ones in the first place. Architecture becomes a matter of creating clear relationships rather than accumulating influence.

We will explore this topic much more deeply in Wednesday’s article, Escaping the Specificity Dungeon. For now, it is enough to recognize that specificity is a tool for communication, not domination.

The Third Law: Source Order

When importance and specificity fail to produce a winner, the cascade turns to its final tiebreaker: source order. Although this rule appears simple, it explains a surprising amount of browser behavior.

Consider the following example:

</> CSS

.alert {
    color: red;
}

.alert {
    color: blue;
}

Both declarations possess identical specificity. Neither declaration is marked as important. The browser, therefore, selects the declaration that appears later in the stylesheet. The resulting text appears blue because the second declaration was encountered after the first.

Many developers underestimate the importance of source order because the rule feels almost too simple. Yet large stylesheets frequently contain hundreds or thousands of declarations. The placement of those declarations influences behavior throughout the codebase. A well-organized stylesheet uses source order intentionally. A poorly organized stylesheet often relies on source order accidentally.

Source order also explains why many design systems establish deliberate layering strategies. Base styles appear first. Components appear later. Utility classes appear last. Each layer builds upon the previous one in a predictable manner. Rather than fighting the cascade, these systems embrace it and use its rules to create clarity.

This highlights an important distinction between beginner and experienced developers. Beginners often view source order as an implementation detail. Experienced developers recognize it as an architectural tool. The organization itself influences behavior.

Reading Conflicts Like a Dungeon Master

At this point, we have examined the three primary mechanisms that govern the cascade: importance, specificity, and source order. The next challenge is learning how to apply that knowledge when debugging real-world problems.

Suppose a developer encounters the following situation:

</> CSS

button {
    background-color: gray;
}

.btn {
    background-color: blue;
}

#save-button {
    background-color: green;
}

And the corresponding HTML:

</> HTML

<button id="save-button" class="btn">
    Save
</button>

Many developers immediately begin experimenting. They add declarations, rearrange code, and repeatedly refresh the browser. While experimentation can sometimes produce results, it rarely produces understanding.

An experienced developer approaches the problem differently. They evaluate the situation as the browser would. First, they consider the importance. No declarations are marked as important. The browser moves to specificity. The element selector has the lowest specificity. The class selector has greater specificity. The ID selector has the greatest specificity. The browser, therefore, selects the green declaration.

Notice that this process requires no guessing. The outcome can be determined before the page is rendered. The developer understands the decision tree and follows it step by step. This ability transforms debugging from trial and error into investigation.

I often tell newer engineers that debugging CSS is remarkably similar to running a role-playing game. A good dungeon master does not invent rules in the middle of a session. They understand the governing systems well enough to consistently resolve unexpected situations. The cascade works the same way. Once its rules become familiar, unexpected outcomes become far less surprising.

A skilled dungeon master trusts the rules of the game and follows them to their conclusion. Experienced frontend developers learn to do the same. When a style behaves unexpectedly, they do not immediately assume something is broken. They investigate the governing rules and determine which declaration currently occupies the throne.

From Styling Rules to System Design

One of the most valuable lessons the cascade teaches has very little to do with CSS itself. It teaches developers how systems resolve competing instructions. Every sufficiently complex software system eventually encounters situations where multiple influences compete for authority. Databases resolve conflicting transactions. Operating systems prioritize processes. Network devices determine routing paths. CSS resolves styling conflicts.

This is one reason I often encourage newer developers to treat CSS as a serious engineering discipline rather than a collection of visual adjustments. The cascade is not merely deciding colors and margins. It is demonstrating how a well-designed system can remain flexible while still producing predictable outcomes. The browser allows multiple declarations to target the same element, yet the final result remains consistent because the governing rules are clearly defined.

As projects grow, this lesson becomes increasingly important. A small stylesheet can survive confusion because the number of interactions remains limited. Large applications do not have that luxury. Hundreds of components, thousands of declarations, and multiple developers all contribute instructions to the same system. Without a clear understanding of how authority is determined, maintaining that system becomes increasingly difficult.

This is why experienced frontend engineers often spend more time thinking about architecture than individual declarations. They understand that every styling decision eventually becomes part of a larger ecosystem. A selector is not merely solving today’s problem. It is establishing a relationship that future developers will inherit. Understanding the cascade helps developers create those relationships intentionally rather than accidentally.

Consider two different approaches to styling a growing application. In the first approach, developers continuously respond to conflicts as they appear. A new selector is added whenever an old selector causes trouble. Specificity increases gradually. Overrides become more common. The code continues functioning, but understanding becomes increasingly difficult. Eventually, even small changes require careful investigation because no one is entirely certain which declarations are influencing which elements.

In the second approach, developers understand the cascade well enough to anticipate conflicts before they occur. Components have clear ownership. Selectors remain relatively simple. Styling layers are organized deliberately. The browser still evaluates the same rules, but the architecture supports them rather than fighting them. The result is not merely cleaner CSS. The result is a system that remains understandable as it grows.

The difference between those two approaches becomes especially visible when developers inherit existing projects. Early in my career, I joined a team responsible for maintaining a large application that had evolved over several years. The original developers were talented engineers, but the stylesheet reflected the reality of countless deadlines and feature requests. Every new requirement had been layered on top of previous decisions. Every conflict had been solved individually. Nothing was obviously broken, yet the overall structure had become difficult to navigate.

One particular issue involved a card component that displayed differently depending on where it appeared within the application. The behavior seemed inconsistent at first. Developers frequently described it as random because the same component would render differently across various screens. After tracing the problem through multiple files, the explanation became clear. Several increasingly specific selectors had accumulated over time, each designed to solve a legitimate problem. Individually, they made sense. Collectively, they created a system that few people fully understood.

What struck me most was that the browser never made a mistake. Every styling decision could be explained by the cascade. The problem was architectural rather than technical. Developers had gradually obscured the governing rules beneath layers of overrides and specificity. That experience reinforced a lesson I still carry today. The cascade rarely creates complexity on its own. More often, complexity emerges when developers stop designing around the cascade and start fighting it.

The Difference Between Working and Understanding

One lesson I wish I had learned earlier in my career is that there is a significant difference between making CSS work and understanding why it works. Many developers can produce a correct visual result. Fewer developers can explain the sequence of decisions that produced that result. The distinction may seem academic at first, but it becomes increasingly important as systems grow more complex.

Imagine two developers solving the same styling problem. The first experiments until the page looks correct and then moves on. The second achieves the same result but also understands why the browser selected one declaration over another. Both developers completed the task successfully, yet only one gained knowledge that can be applied to future challenges.

This pattern appears throughout software development. Memorized solutions have limited value because they apply only to situations that closely resemble previous experiences. Understanding systems has far greater value because it allows developers to reason through unfamiliar situations. The specific problem may be new, but the governing rules remain the same.

The cascade rewards that deeper level of understanding. Once developers recognize its patterns, they begin predicting outcomes before writing code. They identify conflicts earlier. They debug more efficiently. Most importantly, they develop confidence grounded in knowledge rather than trial and error.

That confidence is one of the hallmarks of engineering maturity. It does not come from knowing every answer. It comes from understanding the systems well enough to find answers when new questions appear. The strongest frontend developers I have worked with are not distinguished by their ability to memorize CSS properties. They are distinguished by their ability to reason through unfamiliar situations because they understand the underlying rules.

This is ultimately why the CSS Codex exists. The goal is not to collect tricks. The goal is to understand the systems beneath them. Tricks become obsolete. Frameworks change. Methodologies evolve. The underlying mechanics of CSS remain remarkably consistent.

Why the First Law Matters

Every kingdom requires laws. Without them, governance becomes impossible, and disputes become unresolvable. CSS operates according to the same principle. The cascade is the first law of the realm because it establishes how authority is determined whenever competing instructions appear.

The browser evaluates origin and importance. If no winner emerges, it evaluates the specificity. If specificity fails to resolve the conflict, it evaluates source order. The process is systematic, predictable, and remarkably consistent. Once developers understand that sequence, many of the mysteries surrounding CSS begin to disappear.

More importantly, understanding the cascade changes how developers think about the language itself. CSS stops feeling like a collection of unrelated declarations and begins revealing itself as a coordinated system. Every selector participates in that system. Every property interacts with it. Every styling decision ultimately passes through it.

That perspective forms the foundation for everything that follows in The CSS Codex. Future topics such as specificity, layout systems, Flexbox, the box model, design systems, CSS variables, and long-term maintainability all depend upon understanding the rules established here. The cascade is not merely another CSS concept. It is the mechanism that allows the rest of CSS to function.

Whenever a style wins, loses, overrides, inherits, or conflicts, the cascade is present. It is the invisible throne at the center of the kingdom, quietly governing every decision. Developers may not think about it every day, but every stylesheet depends upon it.

Understanding the cascade does not solve every CSS problem. It does something more valuable. It teaches developers how authority is established within the realm. It reveals the physics engine operating beneath every page. Once that engine becomes visible, the browser’s decisions begin to feel logical rather than mysterious.

The browser is still applying the same physics it applied on day one. The challenge is learning to see them.

Closing the Codex

As developers, we often search for shortcuts. We look for the property, framework, utility class, or technique that will solve the immediate problem standing before us. There is nothing inherently wrong with that instinct. Practical solutions matter. Projects must be completed. Deadlines must be met.

Yet lasting growth rarely comes from collecting more shortcuts. It comes from understanding the systems beneath them. The strongest frontend engineers I have worked with are not distinguished by an encyclopedic knowledge of CSS properties. They are distinguished by their understanding of the rules that govern those properties. When unexpected behavior appears, they know where to investigate because they understand how the browser thinks.

The cascade is the foundation of this week’s theme, Understanding the Physics Engine of CSS. Every declaration participates in it. Every browser follows it. Every stylesheet depends upon it. Learning the cascade is not simply learning another CSS feature. It is learning how the kingdom itself is governed.

Unfortunately, developers rarely stop there. Once they discover that specificity influences authority, many begin seeking more power. A selector becomes slightly more specific. Then another becomes even stronger. A conflict is resolved today, only to create a larger conflict tomorrow. Over time, the pursuit of control creates increasingly complex hierarchies that become difficult to understand and even more difficult to maintain.

The cascade establishes who sits upon the throne, but many developers are not content to leave succession alone. What begins as a reasonable attempt to solve a problem often evolves into a contest for influence. Selectors become more specific. Overrides become more common. The kingdom remains functional, but governance becomes increasingly complicated. Before long, developers find themselves navigating a maze of their own creation.

Many journeys into CSS complexity begin with a perfectly reasonable decision that solves a legitimate problem. The difficulty is that these decisions rarely remain isolated. Each additional override, each increase in specificity, and each shortcut taken to satisfy an immediate requirement becomes part of a larger system. Over time, the kingdom accumulates layers of competing authority, making it increasingly difficult to govern.

That progression leads directly to the next lesson in our journey through The CSS Codex. In Wednesday’s article, Escaping the Specificity Dungeon, we will explore how developers accidentally create selector hierarchies that become difficult to maintain, why those traps form so easily, and how experienced engineers avoid them before they become architectural liabilities.

The laws of the realm have now been revealed. We have examined the invisible throne at the center of every stylesheet and the decision-making process that governs every conflict. Understanding those laws is the first step toward mastering CSS because every other concept in the language ultimately depends upon them.

The browser is still applying the same rules it applied when CSS was first introduced. The challenge is not changing the laws of the realm. The challenge is learning them well enough to build confidently within them. Next time, we venture beneath the kingdom and into the Specificity Dungeon, where many well-intentioned developers discover that gaining power is often easier than maintaining control.