How do you choose the breakpoint values for a responsive CSS layout, and why are device categories like "tablet" a poor basis for them?

## The method, concretely Open the page at roughly 320px wide — narrow enough to represent a small phone — and drag the window edge slowly wider. Do not think about devices at all. Watch for the first width at which the design becomes *worse* rather than merely bigger. That is your breakpoint. Add the query, fix the design above that width, and continue dragging. Repeat until you run out of width. The breakpoint set that falls out belongs to that specific layout, and two different components on the same site will legitimately want different values. The useful part of this method is that it forces you to name **what** breaks. Common triggers: - **Line length.** Body text becomes hard to read past roughly 45–75 characters per line. A full-width paragraph crosses that around the same width on most type scales, so a max-width or a second column is due. - **Squashed elements.** A card, a form field or a nav item has a width below which it stops working — labels wrap onto three lines, a button's text clips. That minimum is a property of the component, not of a device. - **Wasted space.** A single column with enormous empty margins on both sides is the signal to add a sidebar or a second column. - **Overflow.** A table, a code block or a long unbroken string starts pushing a horizontal scrollbar. ## Why device names are the wrong axis Four reasons, all checkable: 1. **Widths are a continuum.** Plot real viewport widths and you get a smear, not three clusters. Every gap between named presets is a width that real users have. 2. **Devices produce several widths each.** One tablet is two widths depending on orientation, three if the OS supports split-screen, and a desktop browser is *every* width because windows are resizable. 3. **The famous numbers are archaeology.** 768 and 1024 are the portrait and landscape widths of a specific early tablet; 320 is an early phone. They persist as habit, and where they happen to be right it is coincidence, not derivation. 4. **They encourage the wrong count.** "Phone, tablet, desktop" implies three breakpoints for everything, including layouts that need one and layouts that need four. The deeper objection is that a device name tells you nothing about the failure. "It breaks on tablet" is not actionable; "the card grid squashes below 15rem per card, which happens at about 46rem of container width" is. ## Units: prefer rem or em Inside a media query condition, `em` and `rem` both resolve against the **initial** font size — the browser's default, as modified by the user's preferences — not against the root element's computed `font-size`. That is a genuinely useful property: ```css /* fires at 720px for a default 16px, and earlier if the reader raised it */ @media (min-width: 45rem) { .layout { grid-template-columns: 18rem 1fr; } } ``` A reader who set their default text size to 20px effectively gets a viewport that holds less text, and the `rem` breakpoint moves with them, handing over the simpler layout at a wider pixel width. A `px` breakpoint ignores that setting entirely. It is a small robustness win that costs nothing. ## Fewer breakpoints, not more Each breakpoint is a state that has to be designed, reviewed and re-checked for every component that crosses it. Before adding one, ask whether the layout can absorb the change continuously instead — wrapping rows, flexible track sizing and fluid spacing all reduce the number of discrete jumps a design needs. Breakpoints are for the moments where the layout must genuinely *rearrange*, not for every size adjustment along the way. ## Testing the choices Having derived breakpoints from content, verify with content — real copy, the longest product name in the catalogue, a user with two given names. Placeholder text has uniform length and hides exactly the wrapping failures that breakpoints exist to fix. ## What a strong answer sounds like A process, then a reason, then a caveat: "drag the window until it breaks, put the breakpoint there, because widths are a continuum and device presets only sample it — and keep the count low, because every breakpoint multiplies the states you have to check."