Chapter 2: Working with relative units

Introduction

Introduces CSS lengths and explains the basic difference between absolute and relative units.

• Absolute and relative lengths: Distinguish absolute units such as pixels from relative units such as em and rem, explaining why the same relative value can produce different results.
  Why it matters: This distinction explains why relative units can initially seem less predictable than pixels.
• Meaning of CSS lengths: State what CSS calls a length and distinguish it from a percentage.
  Why it matters: The term “length” identifies the kind of CSS value being discussed in the chapter.

Key terms: absolute unit, relative unit, pixels, em, rem, length, percentages

2.1 The power of relative units

The section explains why web layouts cannot assume fixed dimensions: CSS is combined with content after authoring, and users can change how a page renders.

• Late binding of web styles: Explain that CSS styles and page content are brought together after both are authored, allowing one stylesheet to serve many pages while leaving the final rendering open to user changes.
  Why it matters: It explains why a web design must work across more than one predetermined rendering.
• Unfixed web layout constraints: Distinguish the web from media with known dimensions: a developer could lay out elements against a fixed program window or printed page, but cannot assume equivalent fixed constraints on the web.
  Why it matters: Fixed-size layout assumptions do not carry over reliably to web pages.

Key terms: late binding, stylesheet, final rendering, constraints, layout

2.1.1 The rise of responsive design

This section explains why CSS must adapt to changing screen sizes, how responsive design addresses that need, and how relative units help.

• Context-dependent CSS rendering: Explain why CSS rules must work across different window sizes and be calculated when the browser renders the page.
  Why it matters: This explains why a style that looks right at one size may fail at another.
• Responsive design choices: Describe responsive design and explain why a CSS solution should work across different screen sizes rather than only an ideal layout.
  Why it matters: It gives you a way to judge whether a layout choice will hold up beyond your own screen.
• Relative units for scaling: Explain how relative units can help CSS scale with the window or a base font size.
  Why it matters: Relative sizing is one tool for making a design adapt without specifying every size independently.
• CSS pixels and physical pixels: Distinguish a CSS pixel from a physical display pixel, and state why their relationship can vary.
  Why it matters: It prevents you from treating a pixel value as a guaranteed count of physical screen pixels.

Key terms: browser window, rendered, constraints, responsive design, relative units, base font size, pixel (px), CSS pixel, absolute length units

2.2 Ems and rems

This section explains how em lengths are computed from an element’s font size and how they let related dimensions scale together.

• Em values and computed lengths: Explain that 1 em is the current element’s font size and that the browser computes an em-based length by multiplying that size by the specified number of ems.
  Why it matters: It lets you predict the resulting size of an em-based property when an element’s font size changes.
• Font-scaled element dimensions: Describe how using ems for padding and border radius lets differently sized elements share the same dimensional rules while a font-size change scales those dimensions.
  Why it matters: It explains how one font-size change can resize several parts of an element consistently.

Key terms: em, font size, computed value, ems, padding, border radius, size modifiers

2.2.1 Using ems to define font-size

This section explains how em-based font sizes are calculated, why ems behave differently on other properties, and how nested em-based font sizes can compound.

• Inherited font size calculation: Explain that an em value on font-size is calculated from the inherited font size, and use that size to convert between ems and pixels.
  Why it matters: This lets you predict the rendered font size instead of treating an em value as a fixed size.
• Different em reference sizes: Distinguish how ems are calculated for font-size versus properties such as padding on the same element.
  Why it matters: The same declared em value can produce different pixel values on one element.
• Nested list font compounding: Trace why applying an em-based font size to every nested list repeatedly changes text size, and describe the section’s correction for shrinking lists.
  Why it matters: It explains a common source of unexpectedly shrinking—or growing—text in nested elements.

Key terms: em, font-size, inherited font size, padding, current element’s font size, nested lists, compounding

2.2.2 Using rems for font-size

This section explains how rem-based font sizes use the root element as a stable reference, when to choose rems over other units, and why relative font sizes matter for accessibility.

• Root-based rem font sizing: Explain that rem values are calculated from the root element’s font size, so a rem-based font size stays the same when an element is nested. Describe how the example’s 0.8 rem becomes 12.8 px.
  Why it matters: A stable root reference makes rem-based font sizes predictable even in nested content.
• Root element and selector: Describe what the root element is in the document tree and how CSS can select it.
  Why it matters: Identifying the root clarifies which element provides the reference font size for rems.
• Unit choices by property: Explain the section’s suggested starting choices for font sizes, borders, and other measures, and why those choices differ.
  Why it matters: Choosing units by the behavior you want is more useful than applying one unit everywhere.
• Relative font size accessibility: Distinguish browser zoom from changing the browser’s default font size, and explain why the section recommends relative units or percentages for font sizes.
  Why it matters: Relative font sizes allow text to respond to a browser preference that some readers rely on.

Key terms: rem, root em, root element, computed value, Document Object Model (DOM), root node, <html>, :root, specificity, rems

2.3 Stop thinking in pixels

This section argues against resetting the root font size to simplify pixel-to-rem conversion and encourages choosing relative sizes by how they relate and look rather than by their exact pixel equivalents.

• Root font reset antipattern: Explain why setting the root font size to 62.5% to make rem conversions easy is discouraged: it creates repeated text-size overrides and keeps decisions anchored to pixel values.
  Why it matters: Easy conversion is not worth widespread overrides or continued dependence on pixel thinking.
• Relative sizing mindset: Describe how to choose em-based sizes without calculating every pixel equivalent, while recognizing when concrete pixel values remain useful.
  Why it matters: Thinking in relative sizes makes it easier to work with ems without repeatedly converting them back to pixels.

Key terms: root font size, 62.5%, rem, pixels, ems, inherited font size, base font size, rems

2.3.1 Setting a sane default font size

This section sets a page-wide font size at the root, then uses that inherited size and relative units to style a panel.

• Root default font size: Explain how to set a 14 px page-wide default at the root using the ratio between the desired size and the browser’s inherited default, and why ems preserve user font settings.
  Why it matters: A root default gives the page a consistent starting size without overriding a user’s font preferences.
• Panel units and inheritance: Describe which units the panel styles use and why its body needs no separate font-size rule.
  Why it matters: Inheritance lets the panel body use the page default without an unnecessary CSS rule.
• Direct child heading selector: Explain what the direct descendant combinator selects in the panel heading rule.
  Why it matters: It clarifies which heading the panel rule styles.

Key terms: root, <html>, ems, inherited value, browser’s default, rem, px, panel-body, root font size, direct descendant combinator

2.3.2 Making the panel responsive

The section shows how media queries can change the root font size so a panel styled with relative units scales across screen sizes without changing the panel’s styles.

• Responsive root font sizing: Explain how media queries change the root font size at different screen widths and why that makes a panel styled in ems and rems scale without changing the panel’s rules.
  Why it matters: You can resize a relative-unit component for different screens by changing one shared font-size setting.
• Relative units and global adjustments: Justify using relative rather than pixel units for this responsive strategy, including how a shared font-size change affects the page.
  Why it matters: Relative units can reduce repeated responsive rules and make site-wide size adjustments easier.

Key terms: media query, @media rule, root, em, rem, base font size, relative units, pixels, media queries

2.3.3 Resizing a single component

The section shows how to resize one panel with relative units and explains why CSS is a living standard rather than a single numbered specification.

• Single-component scaling with ems: Explain how setting a panel’s base font size and defining its internal measurements in ems lets a single font-size override resize that panel without resizing other panels.
  Why it matters: You can offer normal and large versions of a component on the same page without changing every measurement separately.
• Selective scaling of properties: Distinguish when to use ems or rems within the panel if some properties should scale with its font size and others should not.
  Why it matters: A larger component need not enlarge every one of its visual details.
• CSS as a living standard: Explain why CSS is described as a living standard rather than one specification with a single version number.
  Why it matters: It helps you interpret CSS version labels without assuming every feature belongs to one release.

Key terms: ems, rems, font-size, panel, large class, border radius, living standard, modules, CSS3, W3C specifications

2.4 Viewport-relative units

Introduces viewport-relative CSS units, shows how they size elements against the visible browser area, and explains why mobile viewport changes complicated the use of vh.

• Basic viewport-relative units: Explain what the viewport is and how vh, vw, vmin, and vmax define lengths relative to its dimensions. Describe why using 90vmin for both width and height makes a square that fits in portrait and landscape viewports.
  Why it matters: Choosing the right viewport dimension lets you size an element for different window shapes.
• Mobile viewport resizing problem: Explain why using vh to fill the viewport could make a mobile page jump as a user scrolls, and describe how most mobile browsers changed their interpretation of vh.
  Why it matters: It explains why a viewport-height element may not track the currently visible space on mobile.

Key terms: viewport, viewport-relative units, vh, vw, vmin, vmax, largest possible viewport size, layout thrashing

2.4.1 Selecting from the newer viewport units

This section explains how to choose among large, small, and dynamic viewport units, including their trade-offs and limitations.

• Large and small viewport choices: Explain how large and small viewport units differ and choose between them for a full-height element.
  Why it matters: The choice determines whether a full-height element prioritizes filling the screen or remaining fully visible.
• Dynamic viewport behavior: Describe what dynamic viewport units do and why the section recommends using them sparingly.
  Why it matters: A unit that tracks the changing screen size can also make the layout shift during scrolling.
• Viewport unit limitations: State the practical caveats the section gives for viewport units, including width, scrollbars, and browser-dependent behavior.
  Why it matters: These caveats help explain unexpected overflow or differences between browsers.
• Logical viewport dimensions: Describe what the inline and block viewport unit types correspond to.
  Why it matters: Inline and block units let dimensions follow writing direction rather than assuming horizontal text.

Key terms: large viewport, small viewport, lvh, svh, lvw, svw, dynamic viewport, dvw, dvh, dvmin

2.4.2 Using viewport units for font size

This section shows how to make font sizes scale smoothly with the viewport while keeping text within usable, accessible bounds.

• Fluid viewport font sizing: Explain how a viewport-relative font size changes as the viewport changes, and why using a viewport unit alone can make text too large or too small.
  Why it matters: Fluid sizing is useful only if the resulting text remains readable across screen sizes.
• Accessible calc font scaling: Describe how calc() combines an em-based value with svw to produce a smoothly scaling font size, and why the calculation should include ems or rems.
  Why it matters: The combination makes type responsive without ignoring the reader's font settings.
• Bounded clamp font sizing: Explain how clamp() sets a preferred responsive font size between a minimum and maximum, and how a responsive base font size affects other em- or rem-sized values.
  Why it matters: Bounding fluid type avoids extreme text sizes while allowing related dimensions to scale with it.

Key terms: viewport-relative units, svw, breakpoint, calc(), ems, rems, font settings, clamp(), minimum value, preferred value

2.5 Unitless numbers and line-height

This section explains where CSS permits unitless numbers and why a unitless line-height usually behaves better when inherited.

• Unitless CSS values: Distinguish properties that accept unitless numbers from length values that can omit a unit only when the value is zero. State that unitless zero does not apply to angles or times.
  Why it matters: It helps you tell when leaving off a CSS unit is valid.
• Inherited line-height behavior: Explain why a unitless line-height on the body typically gives descendants appropriate spacing even when their font sizes change, whereas a line-height with a length unit can cause overlap.
  Why it matters: A unitless body line-height can keep text well spaced across elements with different font sizes.

Key terms: unitless values, unitless 0, length values, line-height, unitless number, computed value, inheritance

2.6 Custom properties (aka CSS variables)

This section shows how to declare and use CSS custom properties to reuse values, and explains fallback and invalid-value behavior.

• Declaring and reusing custom properties: Explain how to declare a custom property and use var() to reference its value, and why this helps when the same value appears throughout a stylesheet.
  Why it matters: A shared value can be changed in one place instead of edited throughout the stylesheet.
• Fallback values in var: Describe when the optional second argument to var() is used, using the section’s defined and undefined property examples.
  Why it matters: A fallback supplies a value when the named custom property has not been defined.
• Invalid var result behavior: State what happens when var() produces a value invalid for the property receiving it, as in the padding example.
  Why it matters: A defined custom property does not guarantee that its value is valid wherever it is used.

Key terms: custom property, var(), --main-font, :root, single source of truth, fallback value, --secondary-color, invalid value, initial value, padding

2.6.1 Changing custom properties dynamically

The section shows how inherited custom properties let the same panel styling produce different colors in different parts of a page.

• Context-dependent panel colors: Explain how values defined on :root and redefined on a dark container give two identically styled panels different text and background colors.
  Why it matters: One component can adapt to its surroundings without needing a separate set of styles for each variant.

Key terms: custom properties, :root, cascade, inherit, dark container

2.7 Summary