Chapter 7: Responsive design

Introduction

The chapter introduces responsive design as a way to make one website work across devices and identifies its three guiding principles.

• One Website Across Devices: Explain why responsive design favors one website that adapts to different viewport sizes over separate desktop and mobile websites.
  Why it matters: This explains the problem responsive design is meant to solve.
• Three Responsive Design Principles: Describe what mobile-first design, media queries, and fluid layouts each contribute to a responsive page.
  Why it matters: These three ideas give you a framework for understanding how a page can adapt.

Key terms: responsive design, viewport size, mobile-first approach, @media at-rule, media queries, fluid layouts

7.1 Mobile first

This section explains why responsive design starts with a mobile layout and shows how content order and shared HTML can support larger-screen designs.

• Mobile-first design rationale: Explain why the mobile layout is planned and built before the desktop layout, and how larger-screen experiences can build on it.
  Why it matters: Designing around mobile constraints from the start is easier than trying to squeeze a finished desktop experience onto a phone.
• Mobile content and HTML order: Justify placing important content early in the HTML for a mobile design, including the accessibility benefit.
  Why it matters: HTML order affects how quickly mobile and assistive-technology users reach the content they came for.
• Shared markup across screen sizes: Describe why the page needs one HTML structure that accommodates both mobile and larger-screen layouts, and identify the structural choices described here.
  Why it matters: Thinking ahead about the shared markup avoids a structure that works at one screen size but cannot support another.
• Breakpoints and layout changes: State what a breakpoint is and describe the larger-screen changes planned for this page.
  Why it matters: Breakpoints let the layout use additional room without abandoning the mobile starting point.
• Hero text shadow values: Describe what each value in the hero image's text-shadow example controls.
  Why it matters: Reading the values makes the hero text's shadow easier to adjust deliberately.

Key terms: mobile first, progressive enhancement, main content, sidebar, screen reader, HTML, nav-menu, main, column, breakpoint

7.1.1 Creating a mobile menu

This section builds a mobile navigation menu and explains its layout, toggle behavior, accessibility, and usability tradeoffs.

• Navigation structure and positioning: Explain why the nav and header remain siblings and how the menu button can still appear inside the header.
  Why it matters: The markup can support the page’s natural layout without dictating exactly where the button appears.
• Discoverable navigation toggle: Explain why the button that reveals the menu belongs inside the nav element.
  Why it matters: A hidden dropdown should not leave screen-reader users at a seemingly empty navigation landmark.
• Class controlled dropdown visibility: Trace how pressing the toggle button opens and closes the dropdown.
  Why it matters: This separates the button’s interaction from the CSS that controls what is visible.
• Hamburger button text replacement: Describe how the button displays a hamburger symbol instead of its text.
  Why it matters: The button can display the compact icon used in the mobile design.
• Navigation list and tap targets: Describe the menu-list styling and the reason for generous link padding.
  Why it matters: The links need both appropriate menu styling and usable touch targets.
• Hamburger menu visibility tradeoff: Explain the benefit and potential cost of hiding navigation behind a hamburger button.
  Why it matters: A compact mobile menu is not automatically the best choice for every page.

Key terms: <nav>, <header>, menu-toggle, containing block, absolute positioning, landmarks, display: none, menu-dropdown, is-open, JavaScript

7.1.2 Adding the viewport meta tag

This section explains why a mobile design needs a viewport meta tag and how its settings affect page width and zoom.

• Viewport meta tag behavior: Explain why a mobile design needs a viewport meta tag and what the recommended content settings tell the browser to do.
  Why it matters: The browser needs this instruction to display your small-screen design as intended.
• Device width over fixed width: Justify using device-width rather than a fixed viewport width such as width=320.
  Why it matters: Mobile screens vary, so one assumed width is a poor fit for all of them.
• Preserving user zoom: Explain why the section discourages user-scalable=no in the viewport meta tag.
  Why it matters: Keeping zoom available lets readers enlarge content when they need to.

Key terms: viewport meta tag, device-width, initial-scale, width=320, user-scalable=no, zoom

7.2 Media queries

This section explains how media queries conditionally apply responsive styles, how those styles interact with the cascade, and how units and breakpoints affect their behavior.

• Conditional responsive styles: Explain how an @media rule applies enclosed CSS rules only when its condition matches, such as a minimum viewport width.
  Why it matters: Conditional rules let a page use different styles at different screen sizes.
• Cascade behavior inside queries: Explain how rules inside a media query interact with rules outside it.
  Why it matters: A matching query does not automatically make its styles win over other CSS.
• Breakpoint unit choices: Distinguish px and em breakpoint values, including what an em is based on and why the author might choose either unit.
  Why it matters: The unit you choose can affect how breakpoints respond to a reader's browser settings.
• Title breakpoint behavior: Describe what happens to the example page title as the viewport crosses 560 px, and identify that threshold as a breakpoint.
  Why it matters: The title makes a breakpoint's visible effect concrete.

Key terms: media query, @media, min-width, viewport, cascade, selector specificity, source order, px, em, rem

7.2.1 Understanding types of media queries

This section explains how to combine media-query conditions and use different features, ranges, preferences, and media types to adapt page styles.

• Combining media query conditions: Distinguish a query joined with and from one separated by a comma: and requires both criteria, while a comma targets either criterion.
  Why it matters: Choosing the right join prevents styles from applying to the wrong viewports.
• Media features beyond width: Describe what width, height, orientation, resolution, and pointer media features can test, including why resolution or pointer precision might affect styling choices.
  Why it matters: The feature you test should reflect the device characteristic your design needs to respond to.
• Range syntax and boundaries: Explain how comparison signs express a width threshold or bounded range, and distinguish inclusive from exclusive boundaries.
  Why it matters: Explicit boundary choices help prevent two breakpoint rules from matching unintentionally at the same width.
• User theme preference queries: Describe how a media query can respond to the operating system’s light or dark setting and how consistently used custom properties can carry that change across a page.
  Why it matters: Theme styles can follow a user’s setting without changing each use of a color separately.
• Print media styles: Describe how to target printing and identify useful print-specific changes, including hiding nonessential content and simplifying colors and backgrounds.
  Why it matters: A few print-specific rules can make the content users want easier and less wasteful to print.
• Media query placement limits: Distinguish applying a media condition through a stylesheet link from reducing downloads, and state why a custom property cannot supply a media-query breakpoint.
  Why it matters: These limits prevent mistaken assumptions about stylesheet downloads and reusable breakpoint variables.

Key terms: and, comma, or, media feature, min-width, max-width, orientation, resolution, pointer: coarse, range syntax

7.2.2 Adding breakpoints to the page

This section shows how to add mobile-first breakpoints and use a medium-width breakpoint to adjust spacing and turn a mobile dropdown into a persistent horizontal menu.

• Mobile-first breakpoint structure: Explain how mobile styles outside media queries provide the baseline, while successive min-width queries build on and override those styles for wider screens.
  Why it matters: This structure lets wider layouts build on a working narrow layout instead of replacing it wholesale.
• Breakpoint override order: Explain why a media query should follow the styles it changes when its selectors have the same specificity.
  Why it matters: Correct rule order makes breakpoint changes take effect without requiring more specific selectors.
• Selective breakpoint rules: Describe when an element needs no additional breakpoint rule and when a max-width query can be a useful exception to the mobile-first pattern.
  Why it matters: Adding only necessary rules keeps responsive CSS easier to manage.
• Medium-breakpoint menu transformation: Describe how the medium breakpoint changes the mobile menu into an always-visible horizontal menu, including why some mobile positioning values need no explicit override.
  Why it matters: It shows how a breakpoint can change a component’s behavior and layout without undoing every mobile declaration.

Key terms: mobile-first, min-width, breakpoint, media query, selector specificity, override, max-width, dropdown, static positioning, Flexbox

7.2.3 Adding responsive columns

This section shows how to introduce columns at a suitable breakpoint and keep responsive styles manageable.

• Responsive column layout: Explain how the three-column layout changes across the breakpoint: the elements stack in normal document flow below it and form grid columns above it.
  Why it matters: The layout gives columns room on wider screens without cramping them on narrow ones.
• Content driven breakpoints: Justify choosing a breakpoint by testing when the columns become too narrow, rather than matching a particular device width or using the same breakpoint everywhere.
  Why it matters: Content-driven breakpoints can work across the many device sizes you cannot test individually.
• Shorter media query blocks: Describe how custom properties or a preexisting grid can keep media query blocks short by changing only the values that need to vary.
  Why it matters: Smaller media query blocks make responsive styles easier to follow.
• Layouts without media queries: Explain how natural wrapping can sometimes make a layout responsive without media queries, using the flexbox and grid options named in the section.
  Why it matters: Letting items wrap naturally can avoid breakpoint rules when the layout does not need them.

Key terms: media query, breakpoint, grid container, normal document flow, 650 px, columns, custom properties, media query blocks, grid columns, grid rows

7.3 Fluid layouts

This section explains how fluid containers and columns preserve a page’s ability to fit different viewport widths.

• Fluid versus fixed layouts: Distinguish a fluid layout from a fixed layout and explain why a fixed-width container can cause horizontal scrolling on a smaller viewport.
  Why it matters: This distinction helps explain why a page that fits on one screen may scroll sideways on another.
• Fluid container and column sizing: Describe how the main container and its columns can be sized to fit changing viewport widths, including the condition the section gives for flex items.
  Why it matters: Sizing containers and columns in fluid terms lets the layout adapt without relying on one screen width.
• Default page responsiveness: Explain why an unstyled web page starts out responsive and what responsibility follows when adding CSS.
  Why it matters: It frames responsive styling as preserving a useful default, not creating responsiveness from nothing.

Key terms: fluid layout, liquid layout, fixed layout, viewport, main page container, percentage, flex-grow, flex-shrink, responsive by default, block-level elements

7.3.1 Adding styles for a large viewport

This section adds a large-viewport breakpoint while keeping the page fluid and using the extra space for more generous padding.

• Fluid large viewport layout: Explain why the layout remains fluid at each breakpoint: containers grow to the available width minus spacing, while a grid divides the three-column area into thirds.
  Why it matters: This is what lets the layout continue adapting between breakpoints.
• Large breakpoint padding rules: Describe the styling added at the 800px breakpoint and explain why its media-query blocks follow the equivalent smaller-breakpoint rules.
  Why it matters: The larger padding makes use of the available space, and rule order ensures it takes effect.

Key terms: breakpoint, containers, grid, three-column portion, (min-width: 800px), media query, padding, .page-header, .hero, main

7.3.2 Dealing with tables

This subsection explains why wide tables are difficult on mobile screens and describes a block-layout fallback when the data must remain a table.

• Mobile table layout choices: Explain why tables can be problematic in fluid mobile layouts and describe alternatives to retaining a table.
  Why it matters: Considering another presentation may avoid forcing a wide table into a narrow viewport.
• Stacked table fallback: Describe how the section turns a necessary table into a stacked mobile layout and why it hides the header visually rather than using display: none.
  Why it matters: This provides a fallback for data that must remain a table without removing its headings from screen readers.

Key terms: fluid layouts, tiles, visual graph or chart, display: block, max-width media query, <thead>, display: none, screen reader

7.4 Responsive images

This section explains why responsive images need attention to both screen fit and download size.

• Image compression for mobile users: Explain why images should be compressed for responsive pages and name a way to do it.
  Why it matters: An image that fits the screen can still be unnecessarily expensive for a mobile user to download.
• Viewport-appropriate image resolution: Explain why the resolution needed for an image depends on viewport size.
  Why it matters: Matching image resolution to the viewport avoids serving a larger file than the display needs.

Key terms: bandwidth limitations, well compressed, Save for Web, resolution, viewport size, scaled down

7.4.1 Using multiple images for different viewport sizes

This subsection explains why serving different image resolutions at different viewport sizes can reduce downloads without a visible change.

• Viewport-appropriate image resolutions: Explain why a page can use different-resolution copies of an image for different screen sizes, and what this saves on small screens.
  Why it matters: Choosing an image size that suits the screen can make a page faster without making the image look worse.

Key terms: resolution, media queries, breakpoint, hero image

7.4.2 Using srcset to serve the correct image

Explains how srcset lets browsers choose an appropriate HTML image and how to keep images within a fluid layout.

• Responsive HTML image selection: Explain how srcset supplies multiple image URLs and their resolutions for one <img>, allowing the browser to download an appropriate image, including for a higher-density screen. Describe how src provides a fallback for older browsers.
  Why it matters: This lets one HTML image serve different screens without requiring the same file for every device.
• Fluid image width constraint: Explain why the section recommends img { max-inline-size: 100%; } in a fluid layout.
  Why it matters: An appropriately selected image still needs to fit inside its container.

Key terms: srcset, src, pixel density, fluid layout, max-inline-size

7.5 Summary