why mobile-first

Mobile-first css development is good a way to reduce performance issues on mobile. Instead of coding the desktop (largest view) design first and overriding the necessary properties for smaller viewports, you start with the smallest viewport and go from there. Mobile browsers are capable of ignoring all css that isn't necessary for them (as long as it's contained by a proper media query), so they get a significantly smaller set of css rules to apply and reapply (when javascript is doing its dom magic).

The result is a smaller css file, less code overhead and better performance on machines that only need a small chunk of the entire set of css rules to render their design (even though the css file is still loaded in its entirety, less rules need to evaluated).

mobile-first to the letter

When going the strict mobile-first route, you start by looking at the smallest viewport design and implement that outside of the scope of media queries. Then for each responsive change, you create a media query and add the necessary code to get to the new design. The result looks something like this:

It sure beats a desktop-first approach where the mobile browser would have to evaluate two rules instead of one, but what irks me about this setup is the fact that we need to reset the border to its default state on desktop. Even though the desktop styling needs no border styling rules at all, we've written two to make the design work on desktop. That's pretty silly.

Not only does it feel like overkill, it also impacts the readability of the code.

mobile-second

It's actually quite easy to fix this. Rather then look at the mobile design first, why not look at all the design variants at the same time and filter out the common elements. These are the rules that may exist outside the scope of any media query. Then add the custom styles for each responsive view in a second stage, beginning from the smallest view. The example above would look like this:

As the smallest viewport design is the only one who needs a border, we just apply it to this viewport in the mobile view and leave the desktop be.

conclusion

The problem with the mobile-first approach is most apparent when smaller viewport designs apply styles that have to be reverted to the default (browser) styles on larger viewports. It creates ugly overhead that hinders overall readability of the css.

You can be more lenient in cases where different viewports need explicit stylings (instead of no border at all, imagine a red border on the desktop view in the first example), especially if this saves you extra media query declarations, but that doesn't change the fact that it's better to start with looking at common stylings instead of staring blindly at the smallest viewport design first.

small disclaimer: whenever I'm talking about "mobile" and "desktop" views in this article, I'm referring to the smallest/biggest viewport designs available, not necessarily to the device on which a site is rendered. These terms are remnants of the days when mobile = 320px and desktop = 1024px. Sadly they have become somewhat of an industry standard, but at least people understand them (and they limit the use of overly verbose descriptions like "smallest responsive view"). It's a semantic discussion that's probably better suited for a different article.