Stop Defending Mobile-First CSS Like It's a Religion

I spent three months last year fighting with a design system that was built on the religion of mobile-first CSS. Every time we needed to adjust something for tablet or desktop, we'd add another min-width query, inherit styles we didn't want, and then have to override them with increasingly specific selectors. By month two, I was running regression tests that felt like archaelogical digs—poking at one breakpoint only to find I'd broken something three levels up. That's when I realized: we'd confused "mobile-first design" (which is smart) with "mobile-first CSS" (which might not be).

The article that got me thinking about this challenges something the industry has treated as gospel for years. And honestly? Reading it felt like someone finally said what I've been muttering in Slack channels.

The Promise vs. The Reality

Mobile-first CSS sounds right on paper. You start with the simplest version—mobile—and progressively enhance as viewports get wider. It forces you to think about what matters, prevents bloated desktop-first codebases, and keeps you from shipping experiences that don't work on phones.

But here's what happens in real projects: you write styles for mobile, then at 768px you override them, then at 1024px you override the overrides. Your cascade becomes a chain of exceptions. You add a class that resets a property to its default because you've already set it to something else lower in the breakpoint hierarchy. Your CSS specificity creeps up. Testing becomes a nightmare because changing something mobile-sized requires checking every larger breakpoint.

This isn't theoretical—I've lived this multiple times.

The Real Cost of Inherited Assumptions

The fundamental problem is this: when you start with mobile defaults and cascade upward, you're constantly fighting against values you set earlier. A property that's perfect at 320px but needs to be reset at 1200px creates code debt. You're not just writing new styles; you're rewriting old ones.

What I've started doing instead is thinking about breakpoints more like independent contexts rather than a hierarchy. Not abandoning mobile-first thinking—the design phase should still prioritize mobile—but accepting that CSS doesn't have to enforce that same order.

Using closed media query ranges (where you set both min-width and max-width) lets each breakpoint be relatively clean. Your tablet layout doesn't inherit unnecessary mobile styles. Your desktop styles stand on their own. Yes, there's some repetition, but the trade-off is clarity and maintainability.

What I'm Actually Doing Now

Here's a practical example of what I mean:

/* Default/fallback styles - truly shared across all breakpoints */
.card {
  padding: 1rem;
  border-radius: 8px;
}

/* Mobile: 0px to 767px */
@media (max-width: 767px) {
  .card {
    display: block;
    margin-bottom: 1rem;
  }
}

/* Tablet: 768px to 1023px */
@media (min-width: 768px) and (max-width: 1023px) {
  .card {
    display: grid;
    grid-template-columns: 1fr 1fr;
    gap: 1.5rem;
  }
}

/* Desktop: 1024px and up */
@media (min-width: 1024px) {
  .card {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    gap: 2rem;
  }
}

Notice: each breakpoint is self-contained. The tablet version doesn't inherit "display: block" from mobile and have to fight it. The desktop version knows exactly what it's doing without tracking what was set two breakpoints ago.

My Take: It's Not Either/Or

I'm not saying abandon mobile-first thinking. Our design process should absolutely prioritize mobile. User research should start there. The design comps should be mobile-first.

But the CSS development approach? That deserves skepticism. Classic mobile-first CSS works fine for simple projects, but on larger systems with complex components, the maintenance burden grows disproportionately.

What I do now is develop components across all breakpoints simultaneously—not as overrides, but as distinct implementations. This requires better upfront understanding of the design requirements, but it surfaces problems earlier. You catch incompatible layouts between mobile and desktop before you've written 2,000 lines of CSS.

The Question I'm Still Asking

The real lesson here isn't "switch to desktop-first" or "use closed ranges everywhere." It's this: evaluate your actual project needs instead of defaulting to whatever methodology everyone else uses.

Some projects genuinely benefit from the simplicity of classic mobile-first. Some projects—especially design systems, large component libraries, or complex responsive interfaces—benefit from treating breakpoints more independently.

What matters is that you've made a conscious choice, not inherited a dogma.

What's your experience? Have you hit the same walls with mobile-first CSS, or am I just building the wrong things the wrong way?

Source: This post was inspired by "Mobile-First CSS: Is It Time for a Rethink?" by A List Apart. Read the original article