Much e-ink has been spilled in the debate between ‘mobile-first’ and ‘desktop-first’ approaches in responsive design. Thankfully in 2016 that battle is behind us, but before I get into the new way, let’s briefly explain what the old battle was about.


Even though the term didn’t become popular until five years ago, you could say that desktop-first thinking was the original approach to web design. Even though mobile devices were increasingly able to access some form of internet leading up the 2010, if you were serious about providing a good experience to these mobile users on their small screens, low bandwidth connections, and limited CSS support it often meant that you would maintain both a desktop and a mobile website, or at least a desktop and a mobile interface that accessed the same data. This is the way things were before 2010.


After the increasing popularity of smartphones, as well as enhanced support for web standards on mobile devices it became possible not just to build one website that both desktop and mobile users could access - but you could also tailor how that single interface displayed depending on how much room (screen size) the browser was able to take up. What ‘mobile-first’ means is that when building your layout, you designed the layout for phones and tablets first, offering overrides from screens with larger widths. There’s no functional benefit to arranging your styles this way, but it really helped clarify priorities for designers by forcing them to deal with the biggest constraints in the layout first.

So now that all devices are being accounted for - why change our approach? Because no matter how you look at it, both desktop-first and mobile-first mindsets still prioritize the layout over the individual design elements that that layout is comprised of. With element-first thinking we deal with the modules inside the layout first, and then put self-responsive modules into a very simple layout. We never have to worry what happens if the layout is displayed 600px wide, or 3000px, because we know that each module within that layout will always adapt to display itself according to the responsive styles it has been given, and also how the user and web page interact after the page loads.

Element-first layouts aren’t static, they are born when the page loads and live and adapt as the user and application interact


Element-first design is the spirit of the Atomic design principle, but looks very different in practice than how most people implement Atomic using their mobile-first mindset. Instead of writing styles on advance for every conceivable situation a widget my find itself in, we are able to allow individual parts of the layout to adapt responsively when those elements require it.

It makes more sense to say: “These are the styles for the menu when the menu has 300px wide, and these are the styles when the menu is more than 300px wide” than it does to say “These styles are in case the menu shows up in a layout outside a wrapper where it has less than 300px space, here’s how the menu shows up in a layout inside a wrapper with less than 300px space, here’s how the menu shows up in a layout without a wrapper but with a sidebar with less than 300px, etc…” and then also defining all those different layout variations at every breakpoint you want to support as well.

You can see why people have turned toward conventions like BEM to try to help them manage the complexity, but we’ve clearly gotten to a breaking point where our layouts are breaking under the weight of all of the classes and attributes we’re adding to them. We feel the need to use pre-processors which can’t help us after the page loads to try to output enough CSS ‘just in case’ we need it, then we have to deal with tons of CSS and minify and compress that down so it’s small again.

Why not just take an element-first approach?

Edit: For examples of element-first design, check out the following Element Query demos:

Element Query Demos

Documentation & Tutorials

4,383 8 40