Paths Subjects Questions Quizzes Pricing Search
Intermediate Open Free

Diagnosing a Layout That Breaks Between Breakpoints

Your team inherited a marketing site built as three fixed, pixel- exact layouts — one targeted at 375px, one at 768px, one at 1440px — switched between at those exact widths with no adjustment in between. Users on an iPad Mini (viewport ~810px, technically between the 768px and 1440px targets) report that the layout "looks broken," with a two-column grid leaving a large awkward gap on the right and text that appears too small relative to the available space.

  1. Using the responsive vs. adaptive distinction, explain precisely why this specific bug happens on an 810px viewport but not on a 375px or 1440px device.
  2. What would change, mechanically, if this layout were rebuilt as responsive rather than adaptive?
  3. Is adaptive design ever still the right choice? Give one legitimate use case.
Solution

1. Why the bug happens specifically between breakpoints

Adaptive design serves a fixed, discrete layout at each named breakpoint width, with no adjustment for viewports in between — a viewport at 810px falls between the 768px-targeted layout and the 1440px-targeted layout, so it gets whichever fixed layout the breakpoint logic assigns it (most likely the 768px version, since 810px hasn't crossed the 1440px threshold), rendered exactly as it was designed for a 768px-wide screen. That 768px-targeted layout was never designed to fill 810px of width, so the two-column grid — sized and positioned for 768px — leaves the extra ~42px as unused gap rather than the columns growing to fill it, and text sized for that fixed layout doesn't scale up either, which is why it reads as too small relative to the visibly larger available space.

2. What changes if it's rebuilt responsive

A responsive rebuild replaces the fixed pixel widths inside each layout with relative units — percentages or fr for the grid columns, rem for type — so the two-column grid's columns are defined as proportions of the available width rather than fixed pixel values. At 810px, the columns would simply be proportionally wider than they are at 768px, continuously, with no gap left unaccounted for, because the layout isn't switching between discrete states at all between 768px and the next real structural breakpoint (wherever the design calls for e.g. a third column or a different grouping). The visual breakpoints (768px, 1440px) might stay as reference points for when the structure changes, but the space in between them would no longer be a dead zone the design never actually accounted for.

3. A legitimate remaining use case for adaptive design

Adaptive design still makes sense when a small, fully-known, fixed set of target environments needs pixel-precise control that a fluid layout can't guarantee — for example, a native app UI built for a short, enumerated list of specific device models/screen sizes the team explicitly supports (rather than the open-ended range of viewport widths the public web has to handle), where the designer can hand-tune each of a small number of known layouts exactly rather than trusting a fluid grid to look right at every width in between.

Share this question

← Back to Responsive and Mobile Design practice

We use cookies for product analytics to improve OmniAtlas. See our Privacy Policy.