Adobe Certified Professional Dreamweaver study materials
Adobe Certified Professional Dreamweaver study resources

Breakpoint That Breaks the Navigation

Adobe Certified Professional Dreamweaver ยท Put your knowledge to work in context.

All case studies

Breakpoint That Breaks the Navigation

A responsive site uses a single fluid grid with a max-width: 1200px wrapper and a horizontal nav that fits on one line down to about 900px. The developer adds one breakpoint at max-width: 768px that stacks the nav vertically. Testing on a 1024px tablet in landscape, the nav wraps awkwardly onto two lines and the logo overlaps the first link; at 800px it gets worse, then snaps to the stacked layout at 768px. On a 375px phone, the stacked nav works, but a two-column feature section stays two columns and each column is too narrow to read. The developer's plan is to add more breakpoints until every device "looks right." The client ships to a broad consumer audience and wants the fewest possible media queries.

1. Explain why the 768px-only strategy fails between 769px and ~900px, and propose a better breakpoint philosophy.

Read the worked answer

The layout has a content-driven failure range (roughly 769โ€“900px) that the single breakpoint never addresses: the nav is still horizontal but no longer fits, so it wraps and collides with the logo. A breakpoint at 768px only fixes widths below 768; the 769โ€“900 band is an unhandled gap.

The fix is to set breakpoints where the design breaks, not at device widths. Add a breakpoint at the width where the nav first wraps (measure it - say ~900px) that either shrinks nav spacing or switches to the stacked menu there. Then the 768px query becomes unnecessary or can be folded in.

"Add breakpoints until every device looks right" is the anti-pattern: device count is unbounded, so you chase forever. Instead, resize the viewport continuously and add a query only at each point the layout visibly fails. Fewest queries = one per genuine failure point, which also satisfies the client's constraint.

2. The two-column feature section stays two columns on a 375px phone. What is the likely cause, and how should it be corrected within the existing breakpoint structure?

Read the worked answer

Most likely the two-column layout is produced by a rule (float, flex, or grid) that the existing max-width: 768px query never overrides for that section - either the selector in the query doesn't match, or the columns are sized in fixed/percentage widths that don't collapse.

Correction within the current structure:

  • Inside the existing mobile query, explicitly set the feature container to a single column (e.g. display:block or grid-template-columns: 1fr) and let children take width:100%.
  • Verify the selector actually targets the feature section (a common failure is a mismatched class name, so the rule silently does nothing).

This does not require a new breakpoint - the 768px query already covers 375px. The problem is a missing/incorrect rule inside an existing query, not a missing query. Confirm by toggling the rule in DevTools at 375px before adding anything new.