An Introduction to Mobile-First Media Queries

According to your implementation of the CSS. Whose to say a better person at CSS couldn’t clean that up and make it more robust? You aren’t used to desktop-down - you don’t do it.

Then “clean up” my example. Show me how to do an even moderately complex UI, use max width queries, and try to write less code than a mobile-first way. It can’t be done.

Which example? I see this

@PaulOB can get in on this too since he also follows desktop-down design.

Sure that will work. Go desktop down and use as much or less markup than I do.

http://codepen.io/ryanreese09/pen/oXbbjd

I basically reduced your bloat from

@media (min-width: 40em) {
  .first {
    float: left;
    width: 25%;
  }
  .second {
    float: left;
    width: 50%;
  }
  .third {
    float: left;
    width: 25%;
  }
}

To

@media (max-width: 40em) {
  .first, .second, .third {
    display:block;
  }
}

That was just within 2 minutes. Feel free to see what other savings I took advantage of.

I’ll leave it be for now. The code could probably be further cleaned.
As you can see, it’s not that hard to easily convert your mobile-first to desktop-first. They are mirrors of each other.

Do you really want to leave around differing block renderings? Leaving the parent with display: table and the children display: block? You’re mixing and matching in a way I don’t think is very responsible and open to problems. You also forgot the different widths that necessitated the different selectors.

Also notice you are turning on something (display: block) that is native to the element itself. You are ‘undoing’ something to return it to a native state whereas I didn’t have that issue. You’re degrading not enhancing the DOM.

That’s not an issue. Maybe in your imaginary world it is.

Point being, even if I reset that parent to the default, the code is the same if not less than what you had.

You are trying to insinuate that desktop-down is worse since it does more.

They are mirrors of each other. Your min-width is my max-width. Your imaginary issues about desktop-down are delusional.

If you cannot see this, then perhaps you can stay in your closed little world. I gave the reverse example to yours. If you cannot see how they are the same, then you can certainly have your opinion; it’s clear you aren’t open to think differently.

Goodbye :wink: .

Tell that to the agencies who supply me with 3 or 4 psds every week that their graphic designers have created. :smile: They don’t have the time, expertise or inclination to design in the browser which is why they hire me to do the dirty work.

Not everyone works the same way and the approach that you take usually reflects the way that your work is organised. If you are a designer and designing in the browsers then mobile first is fine. I have no issue with mobile first but just prefer the other way around because that’s the display I get presented to me. The code is much the same either way not to really matter. I code the PSD in a day and then move on to the next. No Less, no Sass, no problem.:slight_smile:

3 Likes

I actually prefer to use a combination of min and max. Crazy? Consider this: when designing your site, you have a set of items in mind that visitors will be able to interact with. For very small screens, some of these may need to be hidden so that just the article or whatever can be seen, or perhaps so that certain sections get moved to the bottom. A big concern is when trying to present tabular data, since the solution on mobile is to turn rows into cards with each data column prefixed with a ::before selector. Are you going to do all that for a mobile screen first before getting your table looking right?

The problem, of course, is complexity and keeping things straight; mixins are great for that. I still use min-width for most things like breaking up linear content and creating more columns, so that’s the default for my mixin; that way, I can work on the desktop first just by putting all the layout code within an include. If I find something needs to break earlier or works fine on mobile, I can just move it out of the include without losing context. Then when I look at things on mobile, I can concentrate on finding the issues that are specific to that media and use a ‘max-width’ version of the mixin for those. Of course, this would probably work the other way too, but I find this approach is the best way to avoid unnecessarily resetting values.

When it comes to responsive sites, I think it’s more a question of using a good preprocessor and looking at each objects display requirements as they fit into the site rather than worrying about top-down vs. bottom-up design. Here is my SCSS/SASS mixin with conversions and error-checking. @include mquery { } will creat a medium min-width media query by default. In addition to treating unitless numbers as ems, I also included a standard conversion of px to em so it can be used to cover for programmers who haven’t switched over yet. Feel free to remove that line if you want to enforce good programmer habits.

// _global.scss
$breakpoints: (
  small: 24em,
  medium: 56em,
  large: 96em,
  xlarge: 144em
);
 
// _mixins.scss
@mixin mquery($width: 40, $minmax: min) { 
  @if map-has-key($breakpoints, $width) {
    $width: map-get($breakpoints, $width)
  }
  
  @if type-of($width) == "number" {
  @if unitless($width) { $width: $width * 1em }
  @if unit($width) == px { $width: $width / 16px/em }
    @if unit($width) != em {
      @warn "Please use em values for breakpoints.";
	}
    @else {
      @media (#{$minmax}-width: #{$width}) {
        @content;
      }
    }
  }
  @else {
    @warn "The width could not be understood."
        + "Please provide a valid breakpoint.";
  }
}

// _components.scss example
div {
  padding: 0.5em;
  @include mquery(large) {
    float: left;
    width: 35%;
  }
  @include mquery(30, max) {
    display: none;
  }
}

Change the default width to whatever you want. Using this mixin, the code from ChrisPoteet and RyanReese can be cleaned up like so:

.container {
  width: 100%;
  display: table;
}
.container > div {
  padding: 0.5em;
  @include mquery {
    display: table-cell;
  }
}
.first, .third {
  background: PeachPuff;
  @include mquery {
    width: 25%;
  }
}
.second {
  background: MediumAquamarine;
}

or the media query abstracted out (I prefer to compile things semantically, and it’s possible to have media queries combined using a preprocessor)

.container {
  width: 100%;
}
.container > div {
  padding: 0.5em;
}
.first, .third {
  background: PeachPuff;
}
.second {
  background: MediumAquamarine;
}
@include mquery {
  .container > div {
    display: table-cell;
  }
  .first, .third {
    width: 25%;
  }
}

In fact, by selecting nth-child instead of using classes, this can be made even more compact! With SASS:

.container {
  width: 100%;
  display: table;
  > div {
    padding: 0.5em;
    background: MediumAquamarine;
    @include mquery {
      display: table-cell;
    }
  }
  :first-child, :last-child {
    background: PeachPuff;
    @include mquery {
      width: 25%;
    }
  }
}

Here is the codepen link:

If you want to go desktop-down, you would need to add two lines of extra reset code (after changing the mixin minmax default to max), here is that with the media query abstracted out so you can see that too:

.container {
  width: 100%;
  display: table;
  > div {
    padding: 0.5em;
    display: table-cell;
    background: MediumAquamarine;
  }
  :first-child, :last-child {
    width: 25%;
    background: PeachPuff;
  }
  @include mquery {
    > div {
      display: block;
    }
    :first-child, :last-child {
      width: 100%;
    }
  }
}

—Easier if you’ve got your desktop layout already, but it’s unnecessary bloat when designing from scratch with this approach, even when you are working from a desktop mockup.

1 Like

And there won’t ever be any circumstances where you would need commit this cardinal sin working mobile first?
I think this is more about personal preference. The arguments for and against can be turned on their heads and looked at the other way. Its the same road, just a different direction.

1 Like

It’s a fictitious issue anyway. Not sure why he brought that up as a talking point.

Given that most mobiles (if not all) understand how to use Media Queries and a lot of legacy desktops do not, coupled with the fact that most traffic is still coming from desktops, as it stands there is nothing wrong with designing for desktop first for simple 1-2 step responsive sites. The only real problem with this is you have to account for 3g/mobile networks and find a away of serving your smallest images and media first.

I personally use mobile first because when you start taking into consideration height as well as the width it gets far too messy.

What? There are “legacy” phones that don’t support media queries. Just like there are “legacy” browsers that don’t support it. Those legacy browsers are under 1% (closer to 0) (IE8 and down) so this argument in itself is…strange. Could you please elaborate? I’m not sure what makes this a point of consideration.

Phones that do not support Media queries include : Old Blackberry phones, Some Windows Mobile and thats about it. We are talking 0.0something% The rest do, and have an eco system where updating the browser is easy.

Desktops and it gets a little harder. IE8 for example (5% http://caniuse.com/#feat=css-mediaqueries, up to 15% on alot of our sites) needs a polyfill so with js disabled it will not work. Not to mention polyfills slow the site down.

My parents have those phones. I know others do too.

Ultimately we are talking 1-2% difference.

IE6/7/8 COMBINED overall is placing around 3.4%. Considering how hard it is to upgrade phones due to a multitude of reasons, I’d imagine old phones are within 1-2% of that figure.

So maybe it’s just me, but that’s not even a talking point.

Just an update. Our government website that I work on (hundreds of thousands of hits) is reporting 1.5% usage in IE8.

I’d say that’s right equal with legacy mobiles.

As many as that? I have (on a much less popular site) 0.85% over the last month. Compared to 4.77% for the same period a year ago.
Old browsers are dying out. Won’t be long before we can bin the polyfill.

Are you government though? I’m assuming my market is much different than yours. Also is your website getting a few million hits a month?

I actually figured it’d be closer to 1% but I’m not complaining.

No, they are not a like for like comparison at all. It would be a minority, niche interest site with nowhere near so many hits. It has mainly local appeal, though we do get some world-wide visitors too.

Just for fun yesterday, I thought I would try this out. I dug out of a drawer my old Windows Mobile (v2003) Pocket PC Phone, charged it up to see how it handled my desktop first responsive design. Needless to say it looked a mess, but I did not expect anything else, just curious.
But I honestly don’t believe that people using phones to browse the web today are using those phones. I know it works OK on Windows Phone 7 which hasn’t the best css3 support, so I’m happy enough with that.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.