Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Mobile-First vs. Mobile-Second: A Nuance

DZone's Guide to

Mobile-First vs. Mobile-Second: A Nuance

· Java Zone
Free Resource

Learn how to troubleshoot and diagnose some of the most common performance issues in Java today. Brought to you in partnership with AppDynamics.

After a surprisingly short transition period, the mobile-first CSS approach has become the de facto way of implementing responsive designs. Unless you're retrofitting a responsive design on an existing site, there really is no question about how to structure your CSS. But lingering underneath the reassuring cloak of best practice comfort there is a little nuance that is lost on some. There are basically two ways to approach a mobile-first CSS setup and only one of them is sane.

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:

/* mobile-first */ 
.class {border:1px solid #000;} 
@media (min-width:960px) { 
  .class {border:none} 
} 

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:

/* option 2 */ 
@media (max-width:959px) { 
  .class {border:1px solid #000;} 
} 

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.


Understand the needs and benefits around implementing the right monitoring solution for a growing containerized market. Brought to you in partnership with AppDynamics.

Topics:

Published at DZone with permission of Niels Matthijs, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}