1. Mobile-first or desktop-first: the choice has consequences
In CSS, mobile-first means writing base styles for small screens and adding rules as the screen grows (using min-width). Desktop-first does the opposite: starts from the wide layout and uses max-width to scale down.
In a builder project the distinction is often subtler: builders expose responsive settings visually rather than through raw CSS. But the underlying logic holds: starting from the most constrained context is almost always harder and almost always produces more robust results.
2. Mapping design breakpoints to CSS
Design files almost always define just two breakpoints: desktop and mobile. The problem is that every screen between 375px and 1440px is one neither the designer nor the developer ever looked at together.
An approach that works:
- Start from the design breakpoints: 360–390px for mobile, 768px for tablet if specified, 1280–1440px for desktop.
- Add breakpoints where the layout actually breaks, not where a generic framework says to.
- Use relative units (rem, em, %) for padding and typography where the design allows.
- Fix in pixels only what must stay fixed: navigation heights, borders, shadows.
3. Where builders complicate responsive work
Elementor, Bricks and other builders generate responsive styles differently. A common issue: each visual change in the mobile panel creates a CSS rule for that specific breakpoint, which later becomes difficult to maintain or override.
Two frequent mistakes:
- Forcing every component into a specific mobile layout when a fluid grid would already work.
- Using fixed pixel values for fonts and spacing in the responsive panel instead of adjusting the base settings.
4. Typography and spacing across screen widths
Responsive typography is the part of CSS that fewer developers get right on the first attempt.
The cleanest approach is clamp(): define a minimum value, a maximum and a fluid progression between them. A heading moves from 28px to 48px with no jumps, without writing font-size at five separate breakpoints.
The same principle applies to spacing (padding, margin, gap): a consistent scale applied reliably. On mobile the practical rule is to halve vertical values compared to desktop and increase horizontal internal padding so text does not press against the edges.
5. What to check before handoff
Chrome DevTools alone is not enough. Real devices or emulators that replicate real browsers are needed.
Browsers worth checking: Safari on iOS (still different from Chrome for scroll behavior, position fixed and input zoom on small fonts), Firefox, Edge.
A reasonable minimum check: 360px and 390px for mobile, 768px for tablet, 1280px and 1440px for desktop. A site that works at these five points covers 95% of real users.
Frequently asked questions
Does every component need styles at every breakpoint?
No. Many components work fine with a fluid layout and no explicit responsive rules. Breakpoints are only needed where the layout actually changes: navigation, columns, hero images, contact forms.
Do builders make responsive work easier or harder?
It depends. Builders speed up desktop work. Responsive with a builder requires discipline around classes and accumulated overrides, otherwise it becomes hard to maintain over time.
Next step
Working on a WordPress project with precise responsive requirements?
The Design-to-WordPress service page shows how I work on full design-to-build conversion, responsive included.
Open the Design-to-WordPress service