Creative Juices

A blog by Matt Korostoff

Everything First

“Mobile first” is perhaps the hottest buzzword in web development today. The merits have been debated time and again, and I won't rehash them here except to say that I think the conversation has been positive overall. I think we're still kind of struggling as an industry to articulate just what “mobile first” means. Does a mobile first approach simply mean generating mockups in that order? Or does it mean writing the HTML/CSS in that order? Does it require quality assurance testing in that order? Perhaps it means none of these things—perhaps it simply means always giving mobile users first consideration at all phases of the project regardless of the actual chronology. In practice, the meaning seems to lie somewhere in the middle—a project might identify itself as “mobile first” while still designing, coding, or testing in some other order.

If there is serious interest in moving towards a mobile first approach industry wide, I think it's important that we take some time define our goals. Here I want to argue that, whatever “mobile first” means, it doesn't (or shouldn't) mean coding a mobile experience prior to the desktop experience. When it comes time to implement a design in HTML/CSS, “mobile first” versus “desktop first” is a false choice, and instead a holistic approach is necessary. It makes no more sense to code a website mobile first than it does to build a house “inside first.” Desktop, mobile, and tablet views are all “facets of the same experience” as Ethan Marcotte put it in the article that started it all—they are mutually dependent and influence each other. Trying to build one without considering the rest is an exercise in futility.

Take, for example, the following style guides:


Heading 2


Heading 2


Heading 2

If we were going to code the mobile stylesheet first as our “global” stylesheet, we would probably arrive at something like this:

Does anyone else think this is a strange approach? In this scenario, we must override three properties at the desktop and tablet size (color, text-transform, and text-decoration) to return them to their default, user-agent stylesheet configuration. That is to say, we wrote nine lines of code to achieve results that a “desktop first” approach would have achieved in three. It would be objectively shorter and, in my view, simpler to make the “global” styles those that are used the most not those that happen to affect one arbitrary resolution. In this case that would mean:

The same effect can be observed in HTML. Consider the following mobile design:

A fairly simple design for a mobile site

Ok, simple enough. Lets set up our HTML like this:

Now lets take a look at the tablet design:

A fairly simple design for a tablet site

Hmm, well, some of that HTML doesn't quite work anymore. Of course we'll have to serve larger images than originally planned. And we'll need a wrapper around the text inside each <article> element to pull off the transparent overlay effect. The large “featured” story shouldn't give us any trouble, because we can target it as a “first-child” pseudo-element. So lets make an adjustment:

All told, very little has changed. Now let's take a look at the desktop design:

A fairly simple design for a tablet site

Ok, quite a bit has changed here. We'll definitely need a unique class on each article to achieve the varied sizing. The fact that the menu extends to the edge of the page is going to be a problem, because it will prevent us from wrapping the menu and the logo together. There are a lot of ways to achieve this effect, but here we'll use “outer” and “inner” divs, with the inner divs set to a fixed width:

This HTML, in all likelihood, will serve well for all breakpoints. Now consider: which of these designs would have been proper to code first? It's unlikely that looking at any one of these designs would have resulted in HTML that serves all of them. Instead, the developer must consider all breakpoints simultaneously and find a solution that works for all. Particularly when producing a CMS driven site, the cost of recoding the site again and again as we've done here is very high.

The two basic assumptions that motivate mobile-first coding are that 1) desktop capabilities generally exceed mobile device capabilities and 2) a mobile site will be simpler and therefore easier to progressively enhance up to the desktop size. Both assumptions are false. Mobile devices have long exceeded desktop devices in CSS3 support, if for no other reason than the Android/iOS monoculture. iOS was supporting flexbox in v3.2 circa 2010; the same didn't come to Internet Explorer for two more years when IE10 arrived, and still few IE users have upgraded to this version. Not to mention the unique features accessible almost exclusively on mobile devices, such as shake gestures, GPS, voice recording, and multitouch. Mobile devices don't do “less” than desktop devices—they just do things differently. The notion that mobile sites are simpler is sort of hard to rate, because there's so much diversity in site design. In some cases it might be easy to add bells and whistles at larger resolutions, but often the simplest thing to do is use display: none to hide elements that are too finely detailed for small screens.

Facing Up to the Problem

While many still regard mobile first as a content strategy or design strategy, mobile first coding is increasingly pervasive. For instance, the widely used (and brilliant) Omega responsive theme for Drupal ships with five editable stylesheets labeled “narrow,” “normal,” “wide,” “default,” and “global.” Gobal.css kicks off with this comment:

sending a clear message that the right coding strategy is to apply mobile styles everywhere, and then override them for desktop devices. While I love Omega, I have to differ on this point specifically. By the time one starts producing stylesheets, more often than not the mobile-first battle has already been won or lost. Putting your mobile styles in a global stylesheet is a fine thing to do if it happens to make sense for your content strategy, but in cases where this results in code that is more verbose or less logically organized, I can't help but wonder: what's the point?

The popular (and brilliant) CSS framework Foundation proudly describes their mobile first strategy on their website: “Now you can build for small devices first. Then, as devices get larger and larger, layer in more complexity.” Bootstrap 3 similarly labels itself a “sleek, intuitive, and powerful mobile-first front-end framework.” I still struggle a bit to understand just how a CSS framework could be mobile first. A content strategy, sure, I get that, but a framework? Just what does that mean? In the case of these frameworks, it seems to mean two things 1) putting mobile styles inside a global @media only screen {} query and 2) building up from there with a series of @media (min-width: Npx) queries. In virtually every case I can think of min-width queries would be trivially simple to rewrite as max-width queries, so why prefer one over the other across the board? Surely the right solution depends on the individual site.

The list of supposedly mobile first products goes on, but a clear pattern has begun to emerge: increasingly, coders are getting the message that a mobile first design requires mobile first code, and to do otherwise is somehow wrong (even when it works). This is beginning to have real business consequences. A colleague at another firm recently phoned to complain that his client had supplied dozens of mobile sized PSD designs along with an instruction to the effect of “this should get you going until the desktop designs are done.” What an awkward position. He had to choose: insist on having all designs up front (which would delay the project and risk branding him as desktop-first dinosaur) or just start coding and pray that the desktop designs more-or-less fit into his mobile solution (he chose the former). This is the sort of dilemma that universal mobile first coding creates. When ground-level code decisions are made through sweeping generalizations, very often those decisions will be wrong.

In many ways, “mobile first” is an understandable reaction to years of desktop domination. But we must be careful not to pull too far in the other direction—an optimal solution will provide a high quality experience for all users equally, regardless of device. In short, we don't need to put desktop or mobile first; we need to do everything first.

Matt Korostoff is a web developer and cartoonist from New Brunswick, NJ. He works for Blink Reaction and you should too.