Direction of responsive CSS break points

An abstract best practices question about responsive site design, one some what akin to asking where is left and where is right.

  • Which direction to you favour? In other words do you THINK “up to a a certain size” , “below a certain size” , “between a certain size”( tho personally I have found this one to end up rather convoluted )

  • How do you represent that in media query logic so as to have as few conflicts as possible?

Let me give you an example of what I usually do , maybe some can learn from it but I would love pointers as to how to improve, streamline and make “readable”.

Lets say you have selection of break points, feel free to substitute any values I am just indicating that there would be 6 states… one of which would be ‘X to infinty’.

  • if the site is smaller than 361px ( or I guess you could also say up to 360px)
  • from 361px to 480px
  • from 481px to 640px
  • from 641px to 800px
  • from 801px to 960px
  • greater than 960px

first things first. I have always worked with the idea that, in media queries:

  • you represent smaller than with ‘max-width’ as in: @media screen and (max-width: 360px ){ …}
  • and greater than with ‘min-width’

I also have to take the cascade into account. I suppose this is the part i sort of visualize but am struggling with. I try to order my rules in a specific direction , usually counter to the inequality. That is , if i am using less than rules, I arrange my queries with the smallest dimensions first. and vice versa. Thus employing the override/cascade.

eg.:

general rules {}
@media screen and (max-width: 360px ){ …}
@media screen and (min-width: 361px ){ …}
@media screen and (min-width: 481px ){ …} /* greater than 481 px, inherits/overrides 361 /
@media screen and (min-width: 641px ){ …}/
greater than 640 px, inherits/overrides 361,481 /
@media screen and (min-width: 801px ){ …}/
greater than 800 px, inherits/overrides 641,481,361, /
@media screen and (min-width: 961px ){ …}/
greater than 960 px, inherits/overrides 801, 641,481,361, */

this is because at a screen size of say 650px, (min-width: 361px ),(min-width: 481px ) AND (min-width: 641px ) would ALL be TRUE. So if all rules from the 481{} would be inherited , and I can override whatever I want changed in the 641 {}. TWO PET PEEVES:

  1. I need that 361 rule to account for the screen sizes >360<480. (not having a max-width query would leave 0-360 unstyled execpt for the general rules… I suppose that ‘mobile first’ thinking, but that also bugs me. So that break point requires TWO media quires… ugh!
  2. Because of that I often have to repeat stuff from the max-width.

the alternate approach:
is 100% mobile firs

general rules {}/for smallest width devices/
@media screen and (max-width: 800px ){ …}/* 800px and up /
@media screen and (max-width: 640px ){ …}/
640px and up, inherits/overrides 800 */
@media screen and (max-width: 480px ){ …} /*480px and up, inherits/overrides 800 , 600 */
@media screen and (max-width: 360px ){ …}/*480px and up, inherits/overrides 800 , 600, 360 /
@media screen and (min-width: 960px ){ …}/
960px and up, ALL previous rules must be overridden */

of course now the inheritance logic reversed and it almost gives you a head ache. And by the time you get to the min-width 960, you are mostly overriding rules rather than adding them ( this works fine if you didnt do much styling for the smaller screen sizes , but seems repetitive and makes it a pain to debug otherwise)

So what would be your break point strategy? What can I change it to make my code arrangement more intuitive/easier to grasp?

Hi Ray,

CSS tricks has a similar post on media queries which cover similar ground and may be useful.

I think you covered the logic quite well and it all boils down to either being “exclusive” (min and max-width on the same media query) or “over-riding” with your media queries and mobile first or desktop first approaches. The logic is much the same for “mobile first” or “desktop first” but just reversed; I don’t think there’s much in it logic wise but of course the mobile first approach is considered the way to go.

If you use “exclusive” media queries then you don’t have the cascade to worry about but you do have to style each region fully and will most likely end up with much more code. If you use the over-ride method then you are constantly over-writing rules but can use the cascade to cut down on bloat. It all depends on the job in hand to some extent and which approach is the leanest for the type of layout you are using.

It also depends if you construct modular elements that fit into any space and then you need to change little via the media queries so over-writing a rule here and there is much more efficient.

Where possible I tried to avoid set breakpoints anyway and have moved from “device dependent media queries” to “layout dependent media queries” and only apply a media query at the point where a layout breaks or needs to change. In this way you can make the layout scale from small to large with certain elements changing as required. What would be better is if element media queries could [URL=“http://blog.andyhume.net/responsive-containers/”]be supported instead of just viewport width media queries.

I’ve also taken to not grouping my media queries together at the end of the stylesheet but placing them next to the elements that they are over-riding/changing. This means that when I change an element I have all the rules for that element in the same place. The downside is that you end up with code than is otherwise needed.

CSS tricks has a similar post on media queries which cover similar ground and may be useful.
I came from that very post. That why I was saying the understood the logic but wondered about the direction; as CSS is a directional language, so it’s possible to get different results for ( x<8 ) vs ( x>6 ) .

If you use “exclusive” media queries then you don’t have the cascade to worry about but you do have to style each region fully and will most likely end up with much more code. If you use the over-ride method then you are constantly over-writing rules but can use the cascade to cut down on bloat. It all depends on the job in hand to some extent and which approach is the leanest for the type of layout you are using.

You confirmed what I thought. It’s just a trade off no matter what.

What would be an example of layout dependent; it’s sounds intriguing in many ways but am having a hard time visualizing an implementation of it ( that isn’t just simply a viewport dependent but targeting an element)

SIDE NOTE:
Maybe it’s showing my age, but despite the rise in popularity of mobile devises I always wonder about the logic behind mobile first. I keep seeing a scenario in which am in Zimbabwe being, chased b y russians, and my only computer access is a clam shell iMac… and am wondering why the embassy has website has such a messed up layout, lol. In my view I am more likely to encounter a laptop or tower that has a an browser which doesnt support media queries than I am to find a web-cap[able mobile device that doesnt support media queries.

Leaving the only advantage of mobile first to be keeping your code DRY. Then again because of the cascade I found that if I didn’t order my break points in the right direction, I would end up repeating myself anyway.

Yes, what I mean is that you have no pre-defined breakpoints at all. You create your fluid/elastic page and then you set a breakpoint at the point that the layout breaks or appears to look bad or awkward. It may be that the layout looks fine across a wide range but at say 833px wide one element gets to small to fit its content so you set a media query at that breakpoint and change that element so that it works better from 833px and down. In the end you end up with media queries springing into action when needed and not at just some pre-defined breakpoint that doesn’t relate to the layout you created…

Designing for breakpoints based on devices is prone to failure. Who knew about the ipad a few years ago? Now there are loads of tablets and other devices of varying sizes so you will never be able to future-proof your design to accommodate them unless you take them out of the equation. If your page scales from small to large then it automatically accommodates all devices no matter what their size so the emphasis is on changing the layout when the layout needs to change.

SIDE NOTE:
Maybe it’s showing my age, but despite the rise in popularity of mobile devises I always wonder about the logic behind mobile first. I keep seeing a scenario in which am in Zimbabwe being, chased b y russians, and my only computer access is a clam shell iMac… and am wondering why the embassy has website has such a messed up layout, lol. In my view I am more likely to encounter a laptop or tower that has a an browser which doesnt support media queries than I am to find a web-cap[able mobile device that doesn’t support media queries.

It’s a fair point and mobile users are prone to upgrade much more quickly than desktop users so it may be that older mobiles may be of little concern soon but the “mobile first principle” does create a limited fall-back for old desktop users also that don’t support media queries (ie8 and under). It’s probably at a tipping point and may not make much difference if you go mobile first or desktop first.

I think that we are all basically playing catch up and so the strategies we are using are evolving and changing daily as the goal posts keep getting moved and I don’t think there’s one real answer yet. In my mind its all still about creating a layout that goes from small to big.:slight_smile:

Further to that side note - isn’t mobile first as much about keeping in mind limited bandwidth, which would help you on that Zimbabwean iMac which is no doubt on dialup?

Also, apparently you’re twice as likely to be searching on a mobile than that clamshell iMac according to reports I’ve seen (see page 2 - although take it with a grain of salt as the findings are at least two years old)

The logic is much the same for mobile first or desktop first but just reversed.

I don’t think there’s much in it logic wise but of course the mobile first approach is considered the way to go.