Why does my site break at 320px even after I set a breakpoint?
You've probably done it: load the site on a tiny phone, see the layout crumble, and immediately add a breakpoint at 320px. I've been there. But that's just patching a symptom. The real problem is you're designing for fixed widths instead of a fluid system. Responsive design isn't about a handful of breakpoints; it's about fluid grids, flexible images, and media queries all working together. If you're only patching 320px, you're missing the point. Stop thinking in devices and start thinking in fluid containers.
Do I really need to go mobile-first?
Honestly, yes. Starting with the smallest screen forces you to prioritize what really matters: content and speed. A mobile-first approach builds for small screens first, then scales up with media queries. It's not just a trend—Google's mobile-first indexing uses your mobile version for ranking. If your mobile page lacks content that's on desktop, your SEO takes a hit. So, build mobile-first, and you'll naturally keep your mobile version lean and complete.
What's the deal with fluid grids and CSS units?
Fluid grids rely on relative units like percentages, fr, em/rem, and vw/vh instead of fixed pixels. This lets elements scale with the viewport. For example, instead of setting a sidebar to 300px, set it to 25%. But beware: using viewport units alone for font sizes prevents zooming. Combine them with fixed units, like font-size: calc(1.5rem + 4vw). And for images, always use max-width: 100%; height: auto; to prevent overflow. It's a simple rule that solves a ton of layout headaches.
Is CSS Grid better than Flexbox for responsive layouts?
They're not competitors; they're tools for different jobs. Flexbox is great for one-dimensional layouts, like a row of buttons that wrap. Grid is for two-dimensional layouts, like a full page structure with rows and columns. Use Grid's fr unit to distribute space across tracks. For most responsive sites, you'll use both. My advice: use Flexbox for components, Grid for page-level layouts. Don't force one when the other is more natural.
What about breakpoints—should I use 375px, 768px, 1024px?
Those are common reference values, but the rule is to add breakpoints when your content demands it, not at arbitrary device sizes. If your layout looks fine at 375px and starts to cramp at 500px, that's your breakpoint. Don't add a breakpoint just because a tablet is 768px. Test with real content at various widths, and let the design guide you. For instance, I recently built a site where the nav needed to collapse at 640px, not 768px, because that's when the links started to wrap.
Isn't 320px the magic number for accessibility?
This is a common myth. The WCAG 2.1 Reflow requirement (SC 1.4.10) says content must not require two-dimensional scrolling at a width equivalent to 320 CSS pixels (or 256 for horizontal content). That's a minimum, not a target. But accessibility goes beyond reflow. You also need to ensure text can resize up to 200% without loss, and that's where fluid typography and flexible layouts come in. So yes, test at 320px, but don't stop there. I once saw a site that passed the 320px test but failed at 200% zoom because the text overlapped.
What are the most common mistakes that break responsive designs?
Three big ones: ignoring touch targets, forgetting about contrast, and not handling images properly. Touch targets should be at least 44x44 pixels for mobile usability—Apple and Android both recommend around 44-48 points/dp. WCAG 2.2 requires a minimum of 24x24 CSS pixels, with exceptions. Contrast is another issue: low-contrast text is the most common accessibility error, present on 83.9% of home pages. And for images, use srcset and sizes for resolution switching, and the picture element for art direction. Also, set width and height attributes to reserve space and reduce layout shift. I once had a layout shift so bad that a button moved just as I was about to tap it.
Bottom line
Stop chasing 320px as a magic bullet. Instead, adopt a fluid, mobile-first approach with flexible grids, images, and media queries. Prioritize accessibility basics—touch targets, contrast, and keyboard support—and you'll not only pass the 320px test, but you'll create a better experience for everyone.
Sources
- MDN Web Docs - https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
- WCAG 2.1 (AA) - https://www.w3.org/WAI/WCAG21/quickref/
- W3C WCAG 2.1 Understanding Reflow - https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
- W3C WCAG 2.2 Understanding Target Size (Minimum) - https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
- WebAIM Million - https://webaim.org/projects/million/
- Apple Human Interface Guidelines - https://developer.apple.com/design/human-interface-guidelines/accessibility
- Android Developers (accessibility) - https://developer.android.com/guide/topics/ui/accessibility/apps
- Google Search Central - https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!