Chapter 1: Cascade, specificity, and inheritance

Introduction

The chapter introduction explains why CSS requires a grasp of underlying principles and reviews the syntax terms used throughout the book.

• Principles behind CSS decisions: Explain why CSS problems often require more than a memorized trick or recipe: the best approach depends on the project's constraints and edge cases.
  Why it matters: Principles help you choose an approach when a CSS answer depends on the situation.
• CSS syntax terminology: Describe how a declaration, declaration block, selector, and ruleset relate, and distinguish a CSS property from an HTML attribute and an at-rule from a ruleset.
  Why it matters: These terms make later explanations of CSS rules easier to follow.

Key terms: principles, constraints, edge cases, declaration, property, value, attribute, declaration block, selector

1.1 The cascade

This section introduces the cascade as CSS’s predictable way to resolve conflicting declarations and identifies the criteria it considers.

• Predictable conflict resolution: Explain why conflicting CSS declarations need the cascade, and describe the page-title example in which the ID selector’s font declaration wins.
  Why it matters: It lets you reason about why an element uses one style instead of another.
• Cascade precedence criteria: State the six criteria the section names, in precedence order, and describe at a high level what each compares without explaining its detailed mechanics.
  Why it matters: These are the factors to check when a CSS declaration does not produce the result you expect.

Key terms: cascade, conflicting declarations, ID selector, stylesheet origin, inline styles, layer, selector specificity, scope proximity, source order

1.1.1 Stylesheet origin

This section explains how stylesheet origins and !important declarations determine which conflicting CSS declarations win, while the cascade resolves each property separately.

• Stylesheet origins and priority: Explain the three stylesheet origins and their normal priority order. Describe how author styles can override browser defaults, even when several linked stylesheets are used.
  Why it matters: This explains why your stylesheet can replace browser defaults without removing them first.
• Important declaration priority: Explain how !important changes origin priority, including the reversed order among important origins.
  Why it matters: The usual author-over-browser rule has an important-declaration exception.
• Per-property cascade resolution: Describe how the cascade resolves declarations independently for each property of each element, so overriding one browser default does not discard the others.
  Why it matters: It explains why browser-provided spacing can remain after you style an element’s text.

Key terms: author styles, user styles, user-agent styles, origin, !important, important declarations, normal declarations, cascade, property, user-agent stylesheet

1.1.2 Inline styles

Explains how inline styles affect the cascade and when a stylesheet declaration can override them.

• Inline style precedence: Explain that declarations in an HTML style attribute apply only to that element and override conflicting declarations from a stylesheet or a <style> tag when origin has not already resolved the conflict.
  Why it matters: This explains why changing a selector-based rule may not change an element with an inline style.
• Overriding inline declarations: Describe the exception given for overriding an inline declaration from a stylesheet and the stated limit when the inline declaration itself is important.
  Why it matters: It identifies the exception to the usual precedence of inline styles.

Key terms: inline styles, style attribute, selector, !important, higher-priority origin, inline declarations

1.1.3 Selector specificity

This section explains how selector specificity resolves CSS conflicts and how to avoid escalating specificity when a rule does not take effect.

• Selector specificity hierarchy: Explain how the browser compares conflicting selectors by counting IDs first, then classes, then tag names, rather than judging selector length. Apply that order to explain why an ID selector can beat a selector with many classes.
  Why it matters: This comparison explains why a CSS declaration may lose even when its selector looks longer.
• Specificity notation and weights: Describe the ID, class, and tag counts in three-number specificity notation, and state how pseudo-classes, attribute selectors, the universal selector, and combinators affect those counts.
  Why it matters: The notation makes comparisons explicit, including for selectors with components that are easy to miscount.
• Managing specificity conflicts: Explain why the featured link's class rule loses to the navigation rule, and compare the section's fixes: using !important, raising the overriding selector's specificity, or lowering the original selector's specificity.
  Why it matters: Keeping specificity low helps prevent an escalating series of overrides as a stylesheet grows.

Key terms: specificity, ID selector, class selector, tag selector, pseudo-class selectors, attribute selectors, universal selector, combinators, #main-nav a, .featured

1.1.4 Source order

This section explains how source order resolves tied CSS declarations and how that affects selector choices, link states, and maintainable styles.

• Source order tie breaker: Explain when source order determines which CSS declaration applies, including stylesheets included later on the page.
  Why it matters: It lets you recognize when rearranging rules will fix a conflict—and when it will not.
• Featured selector tradeoff: Describe why using the compound selector `a.featured` can fix the nav link yet produce incomplete styling on a featured link elsewhere, and how that affects the choice of selectors.
  Why it matters: A fix that looks right in one place can create unintended styling elsewhere.
• Link state ordering: Explain why equally specific link-state rules are commonly ordered link, visited, hover, active, and what happens when states overlap.
  Why it matters: It explains the familiar link-rule order rather than treating it as a rule to memorize blindly.
• Cascaded value meaning: Define a cascaded value and distinguish a property with a winning declaration from one with no cascaded value.
  Why it matters: It names the result of resolving competing declarations for each element and property.
• Override friendly style choices: Justify caution with IDs, `!important`, and JavaScript-applied inline styles when writing CSS others may need to change.
  Why it matters: Choosing styles that others can override makes a site or shared component easier to maintain.

Key terms: source order, order of appearance, specificity, compound selector, a.featured, featured class, :link, :visited, :hover, :active

1.2 Inheritance

Explains when CSS properties inherit from ancestors, which kinds of properties normally inherit, and how DevTools reveals inherited and overridden styles.

• Inheritance from ancestor elements: Explain how an element can receive an inherited property value and when a cascaded value overrides it. Describe why setting font-family on the body can style descendants without separate declarations.
  Why it matters: It explains why a single declaration can affect many descendants without being written for each one.
• Properties that normally inherit: Distinguish properties that commonly inherit from properties that do not, using the section’s text, list, and border examples.
  Why it matters: It helps you predict whether styling an ancestor will affect its descendants.
• Inspecting applied and inherited styles: Describe how to use the browser’s DevTools style inspector to identify rules affecting an element, inherited properties, and overridden declarations.
  Why it matters: It gives you a practical way to trace a surprising style back to its source.

Key terms: inheritance, cascaded value, ancestor element, descendant elements, inherited properties, font-family, list-style, border-collapse, border-spacing, DevTools

1.3 Special values

Introduces four special CSS values that can be applied to any property to manipulate the cascade.

• Special values and the cascade: State that inherit, initial, unset, and revert are special values that can be applied to any CSS property to help manipulate the cascade.
  Why it matters: This gives you the shared purpose of the four values before their individual behaviors are explained.

Key terms: inherit, initial, unset, revert, cascade

1.3.1 The inherit keyword

This subsection shows how `inherit` overrides a cascaded value so an element takes a property value from its parent.

• Overriding a link color: Explain how setting the footer link’s color to `inherit` overrides its existing link color and makes it use the footer’s color.
  Why it matters: The link can stay visually consistent with the footer without needing its own fixed color.
• Inheritance of other properties: State that `inherit` can also force a property that does not normally inherit, such as `border` or `padding`, to take its value from the parent.
  Why it matters: It clarifies that `inherit` is an explicit choice, not just a way to restore properties that normally inherit.

Key terms: inherit, cascaded value, parent, border, padding

1.3.2 The initial keyword

Explains how `initial` resets a CSS property to its property-wide default value, including why that may differ from an element’s usual display.

• Resetting properties with initial: Explain that assigning `initial` to a CSS property resets it to that property’s default value, and why this is useful when undoing a style.
  Why it matters: It gives you a consistent way to undo a property value without memorizing its default.
• Property defaults versus element defaults: Distinguish a property's initial value from the value typically associated with an element, using `display: initial` as the example; explain why `auto` is not a universal reset.
  Why it matters: It prevents resets that either have no effect or produce a different result than you expected.

Key terms: initial, initial value, auto, display: initial, display: inline, revert

1.3.3 The unset keyword

Explains how `unset` clears a CSS value according to whether its property is inherited, and why it cannot restore every element default.

• Inherited and noninherited unset behavior: Explain that `unset` acts like `inherit` on inherited properties and `initial` on noninherited properties. Describe how this fixes link colors in the footer.
  Why it matters: You can clear different kinds of property values with one keyword without choosing `inherit` or `initial` separately.
• Limits of restoring link underlines: Explain why `unset` does not restore the footer links’ underlines and why the section explicitly declares `text-decoration: underline`.
  Why it matters: Clearing a declaration with `unset` is not the same as restoring the appearance you expect for an element.

Key terms: unset, inherit, initial, inherited property, noninherited property, initial value, text-decoration: underline, text-decoration

1.3.4 The revert keyword

The section explains how `revert` undoes author styles while retaining browser defaults, and notes that it remains subject to the cascade.

• Revert and browser defaults: Explain how `revert` differs from `initial` and `unset`, and describe why the footer example applies it only to `text-decoration`.
  Why it matters: You can restore a browser default for one property without discarding the rest of your styling.
• Cascaded status of keywords: Explain why a declaration using one of these keywords can still be overridden.
  Why it matters: Using a reset keyword does not make a declaration immune to later cascade conflicts.

Key terms: revert, initial, unset, author styles, user-agent stylesheets, text-decoration, cascaded values, higher specificity

1.4 Shorthand properties

Defines CSS shorthand properties, illustrates the longhand properties they group, and notes their benefit for concise code.

• Shorthand and longhand properties: Explain that a shorthand property sets several other CSS properties at once, using font, background, or border as an example, and say why that can make code clearer.
  Why it matters: Recognizing what a shorthand groups together helps you read and write compact CSS declarations.

Key terms: shorthand properties, font, background, border

1.4.1 Beware shorthands silently overriding other styles

This subsection explains why omitted values in CSS shorthands can silently override other styles.

• Omitted shorthand values: Explain that a shorthand sets omitted values to their initial values, rather than leaving them unchanged. Describe how omitting font-weight from the font shorthand can make a heading normal-weight and override other font styles.
  Why it matters: A shorthand may change more styles than the ones you explicitly write.

Key terms: shorthand properties, initial value, font, font-weight

1.4.2 Remember the order of shorthand values

This section explains how value order works in CSS properties, especially four-sided spacing and horizontal–vertical measurements.

• When shorthand order matters: Distinguish declarations whose values can be reordered from those whose values have position-dependent meanings.
  Why it matters: It explains why you cannot assume every CSS declaration accepts values in any order.
• Clockwise four-side value order: Describe the order of four values for properties such as margin and padding, and apply it to a declaration.
  Why it matters: The clockwise order lets you identify which side each value changes.
• Truncated four-side declarations: Explain how one, two, or three values assign spacing to all four sides, including the omitted sides.
  Why it matters: These shorter forms are common, and the three-value form is particularly easy to misread.
• Horizontal then vertical measurements: Distinguish the order of horizontal–vertical measurements from the two-value order for four-sided properties, and explain why it differs.
  Why it matters: Thinking “clock” for sides and “Cartesian grid” for directional measurements prevents reversing two-value declarations.

Key terms: shorthand properties, border, margin, padding, top, right, bottom, left, TRouBLe, truncated notations, vertical padding, horizontal, background-position

1.5 Progressive enhancement

Introduces progressive enhancement as a way to use new CSS features while preserving an acceptable experience in browsers that do not support them.

• Progressive enhancement with CSS: Explain how to provide an acceptable experience in older browsers while adding newer CSS features for browsers that support them.
  Why it matters: You can use newer CSS without requiring every visitor to have the newest browser.
• New feature adoption: Describe why browser support should inform when you use a new CSS feature, without assuming you must always wait for universal support.
  Why it matters: Checking support helps you decide whether an enhancement is safe for your users.

Key terms: progressive enhancement, forward and backward compatible, browser support, evergreen

1.5.1 Using the cascade for progressive enhancement

Shows how the cascade provides a usable fallback when a browser does not understand a newer CSS declaration.

• Cascade-based progressive enhancement: Explain how placing a newer CSS declaration after a fallback lets supporting browsers use the newer value while older browsers retain a usable result.
  Why it matters: You can offer newer styling without sacrificing a usable page in browsers that lack support.

Key terms: progressive enhancement, cascade, declaration, cascaded value, 8-digit hex color code

1.5.2 Progressively enhancing selectors

Explains how to use new CSS selectors without letting unsupported selectors suppress styles that older browsers could apply.

• Selector compatibility and separate rulesets: Explain why grouping a new selector with a supported one can prevent both from applying in an older browser, and describe how separate rulesets preserve the supported styles.
  Why it matters: A new selector should not accidentally disable a working fallback in browsers that do not recognize it.

Key terms: ruleset, selector, unsupported or invalid, pseudo-class

1.5.3 Feature queries using @supports()

Explains how @supports lets CSS provide fallback styles and enhanced styles according to browser support, and why that supports progressive enhancement.

• Feature query behavior: Explain how @supports tests a CSS declaration and determines whether the rules inside its block apply.
  Why it matters: This is the basic behavior that makes feature-dependent styling possible.
• Fallback and enhanced styles: Describe how to place broadly usable styles outside a feature query and feature-specific layout styles inside it.
  Why it matters: A usable fallback need not prevent newer browsers from getting a fuller layout.
• Alternative query conditions: Distinguish the conditions expressed by not, or, and, and selector() in feature queries.
  Why it matters: These forms let a feature query express more than a single supported declaration.
• Resilient CSS enhancement: Explain why feature queries help a page remain usable across browsers with different CSS support.
  Why it matters: Resilience is why newer CSS features can be introduced without requiring every browser to support them.
• Experimental feature access: Explain why browsers may require developers to opt in to experimental CSS features and describe the access methods mentioned.
  Why it matters: Opt-in access allows early testing while a CSS feature is still being developed.

Key terms: feature query, @supports, declaration, fallback, progressive enhancement, grid, not, or, and, selector()

1.6 Summary