DEV Community

Nashe Omirro
Nashe Omirro

Posted on

why using both mobile-first and desktop-first approach isn't bad practice

So I actually use both "max-width" queries and "min-width" queries.

Why use both though?

Now before answering why I do it this way we need to understand the reason for a mobile-first approach, and that reason is that our responsive-styling is much more intuitive when we gradually add more CSS instead of gradually removing CSS, and the consensus is that we would have more CSS the more larger the screen becomes.

But sometimes that isn't the case. The most common exception is a navigation menu which is much more complex for mobile devices, in mobile you need to have an absolute-positioned menu with toggle-able transitions, but in desktop it's just a static flex-box with some padding. In these scenario, if we truly want the benefit of a mobile-first approach we would then have to start the styling in a bigger screen size.

Using both properly

If you agree with my reasoning you might try it yourself and do something like this:

/* for convenience sake let's call this above('sm') */
@media (min-width: 480px) {
  // ...
}

/* and this below('sm') */
@media (max-width: 480px) {
  // ...
}
Enter fullscreen mode Exit fullscreen mode

But the problem with this is at 480px both queries work. Now that might not look like an issue, but let's say we hid our toggle button at above('sm') because we would like our nav menu to only be absolutely-positioned below('sm'). If the user is at exactly 480px they would not see the toggle button nor the navigation menu!

The mostly complete solution

So to fix that we have to only have one of the queries be inclusive (480 and above) and the other to be exclusive (just below 480), so you might try something like this:

@media (min-width: 480px) {
  // ...
}

@media (max-width: 479px) {
  // ...
}
Enter fullscreen mode Exit fullscreen mode

Now with this, our imaginary toggle button should be visible right at the moment that our nav menu becomes a static box. We only have one query active between above('sm') and below('sm').

But even then there is still a problem, browser screen sizes aren't integers.

The complete solution

Because screen sizes aren't fully integers (1028.4px, 721.6px, etc.), we have a problem yet again in cases where the screen size is between 479px and 480px.

For example, if the browser window is at 479.6px, then both the below('sm') and above('sm') queries would be inactive! Which means that in our theoretical situation the nav bar already becomes a static-box but the toggle button is still visible.

So to fix this, all we have to do is use floating points as well:

@media (min-width: 480px) {
  // ...
}

@media (max-width: 479.9px) {
  // ...
}
Enter fullscreen mode Exit fullscreen mode

In the above block, we set the query to only be active when we are 0.1px away from 480px. This way, no matter if the browser has a size of 479.6px or 479.9px, we would still have either the below('sm') query active, or the above('sm') query active.

Of course, you could argue that if the screen size is between 479.9px and 480px, then we would have the same problem yet again, but at that point I think its quite unlikely that that would happen. But you could still prepare for it if you set the max-width at 479.99px.

Conclusion

Apart from nav menus, I honestly can't think of other situations where the mobile-first approach needs to be flipped. I do think that the name should've been more closer to what it wants to do, so something like "additive approach" could have worked better.

Then again, the term "mobile-first" seems to have expanded it's meaning to caring more about the mobile view than the desktop view, this was around the time people discovered that more and more traffic is coming from mobile devices, so I can see why the name stuck.

But I want to emphasize that these are just guidelines and should not have to be followed strictly, as a developer it's important to understand why we follow guidelines in the first place and why in some cases it is actually much better to break them.

Top comments (0)