How do you organize your CSS on Responsive SItes?

[mikey_w]

In another thread, I have come under some fire for how I organize my CSS in my first-ever responsive website.

Actually what @felgall is referring to is slightly different than my own question, so here goes…

It seems to me that there are two different ways you could organize your CSS for a responsive website.

First, you could add media queries for each component. For example, I have an ID called #services which displays what the company does. It is fairly involved, and changes a couple of times depending on screen width, so I have my base CSS and then media queries that just pertain to #services below it so I can see how this “object” changes depending on the device.

Secondly, you could organize all of your CSS based on each break point. So I might have a section with all of my CSS for an entire web page when it is viewed on a mobile phone, and then I could have another section for all of my CSS when it is viewed on a desktop. It would almost be a list of CSS based on the device width.

How do you organize things?

All I know is that while my home page looks awesome so far, it is also very complicated, and I’m not sure how to organize everything so it is easy to read and find things.

To be honest, based on some former websites that were not responsive, I had a similar issue.

Part of me wanted to created a CSS file for each page on the website, because most styles seemed to just apply to a given page. But then you have some styles that apply everywhere. And now that I am doing responsive design, things are even more complicated to manage!!

[SamA74]

@mikey_w

If you have the default way in your main CSS, it is sometimes harder for me to link to to the media query, whereas my approach put both binary states right next to each other.

I get the idea of grouping references to the same selector together, it’s not my style, but accept a lot of people prefer to do that, each to their own. But don’t see the need for the opposite query.

#masthead{
    position: fixed;
    top: 0;
    left: 0;
    right: 0;
    z-index: 999;
    max-width: 1200px;        /**/
    margin: 0 auto;                                            /* Center element. */
/*    padding: 0 20px;        /**/
    border-collapse: collapse;                    /* Allows border. (Collapses margins/padding.) */
    font-size: 0.9rem;
    line-height: 1.1;
}


/* masthead: Row 2 (Top Menu)                */

/* Top Menu: Drop-down (Mobile) */
@media screen and (max-width: 700px){
    nav#topMenu{
        position: relative;
        display: block;
        width: 100%;
        height: 40px;
    }
}
/* Top Menu: Horizontal (Desktop) */
    nav#topMenu{
        position: relative;
        display: table-row;
}

This makes more sense, the two are still together on the sheet, but without a totally unnecessary query.

[felgall]

@mikey_w

How do you organize things?

Neither of those ways.

You start with all the CSS suitable either for the smallest width or the biggest width you want to support.

You then view the page in a desktop browser and resize the browser until the layout breaks.

You add a media query specifying that width and add the CSS to fix whatever broke to that media query.

You then continue resizing until it breaks again and again add a media query to specifically fix what broke.

repeat until all widths are covered

assuming you started with decent CSS in the first place the combined code in the media queries should be only a small fraction of the code outside the media queries (since it only relates to those positioning and width values that need to change).

[chrisofarabia]

I like the way Harry Roberts suggests doing it with ITCSS. There’s a logic to it in my mind.

Harry Roberts - Managing CSS Projects with ITCSS

[SamA74]

@mikey_w

First, you could add media queries for each component. For example, I have an ID called #services which displays what the company does. It is fairly involved, and changes a couple of times depending on screen width, so I have my base CSS and then media queries that just pertain to #services below it so I can see how this “object” changes depending on the device.

I think the reason I don’t use this method is I don’t like too much repetition. I don’t want to add the same query over and over for every selector that uses it.
But people like doing that because it makes stuff easier to find quikly when working on a particular element.

[mikey_w]

@SamA74

This makes more sense, the two are still together on the sheet, but without a totally unnecessary query.

/* masthead: Row 2 (Top Menu)                */

/* Top Menu: Drop-down (Mobile) */
@media screen and (max-width: 700px){
    nav#topMenu{
        position: relative;
        display: block;
        width: 100%;
        height: 40px;
    }
}
/* Top Menu: Horizontal (Desktop) */
    nav#topMenu{
        position: relative;
        display: table-row;
}

But as it is posted, your code wouldn’t do what you expect. For instance, if I have a device width of 320px, your media query would set display:block and then drop through and unset that and reset it to display:table-row.

If you flipped the order, it would work, but that is my point of defining all states - that way things are more symmetric!

[mikey_w]

@felgall

Neither of those ways.

You start with all the CSS suitable either for the smallest width or the biggest width you want to support.

You then view the page in a desktop browser and resize the browser until the layout breaks.

You add a media query specifying that width and add the CSS to fix whatever broke to that media query.

You then continue resizing until it breaks again and again add a media query to specifically fix what broke.

repeat until all widths are covered

But you just described my second method. (Or at least how I meant to say it.)

@felgall

assuming you started with decent CSS in the first place the combined code in the media queries should be only a small fraction of the code outside the media queries (since it only relates to those positioning and width values that need to change).

I don’t agree with that. If you have a light RWD, then yes, I agree. But my home page has about 6-7 stages/break-points to take it from 320px to infinity.

[mikey_w]

@chrisofarabia

I like the way [Harry Roberts][1] suggests doing it with ITCSS. There’s a logic to it in my mind.

Can you summarize it because this guy is long winded!

[SamA74]

@mikey_w

If you flipped the order, it would work,

Yes, neglected to swap the order. That was just lazy copy & paste without thought.
The point being, I don’t object to others grouping common selectors like this, but the opposite query is just seems like unnecessary overworking (nonsense).

[SamA74]

@mikey_w

Can you summarize it because this guy is long winded!

Yes, it’s over an hour and the PA’s not very good!

[mikey_w]

@SamA74

I think the reason I don’t use this method is I don’t like too much repetition. I don’t want to add the same query over and over for every selector that uses it.
But people like doing that because it makes stuff easier to find quikly when working on a particular element.

So it sounds you would like the second way I mentioned, i.e. grouping CSS into breakpoints. So all of your code for mobile from 320-480px would be in one media query, and all of the code for a desktop would be in a media query (queries) from 980px to 1920px (?)

I don’t have the perfect answer, but would like some insight before I write a large mess!

[Mittineague]

@SamA74

the opposite query is just seems like unnecessary overworking

Seeing as it could completely negate the first, I agree.
Bound to make things more complicated sooner or later and my bet is on the sooner.

eg. I could do this, but why would I?
…
line # 32 …someselector { color: #f00; }
…
line # 97 …someselector { color: #0f0; }
…
line # 147 …someselector { color: #00f; }

[SamA74]

@mikey_w

So it sounds you would like the second way I mentioned, i.e. grouping CSS into breakpoints. So all of your code for mobile from 320-480px would be in one media query, and all of the code for a desktop would be in a media query (queries) from 980px to 1920px (?)

The bulk of the css would not be in any media query. Using “desktop first” I would then identify a break point and create a query for screens smaller than that breakpoint, like felgal described.
The point is I don’t put anything in a query that does not absolutely require to be in a query. Nor do I create queries that are redundant or unnecessary.

[chrisofarabia]

@mikey_w

Can you summarize it because this guy is long winded!

Try this version instead you shouldn’t need to read it all before you pick up on the general gist of it - http://www.creativebloq.com/web-design/manage-large-css-projects-itcss-101517528

[SamA74]

@mikey_w

my home page has about 6-7 stages/break-points to take it from 320px to infinity.

I was going to say, that is too many, but to be fair to you, my first attempt at RWD ended up with 7, which is too many! When I get the time and motivation I will re-work it, as I’ve learnt a lot since then and believe I could do better.

@felgall

assuming you started with decent CSS in the first place the combined code in the media queries should be only a small fraction of the code outside the media queries (since it only relates to those positioning and width values that need to change).

I would agree. If the intial css is kept as fluid as possible, fewer queries will be needed. Too many queries can be a symptom of rigid elements.

[mikey_w]

@chrisofarabia

Try this version instead you shouldn’t need to read it all before you pick up on the general gist of it - http://www.creativebloq.com/web-design/manage-large-css-projects-itcss-101517528

Harry starts to get into things around minute 25.

Sounds like he is taking credit for an age-old idea… Go from general to specific.

[mikey_w]

@SamA74

I was going to say, that is too many, but to be fair to you, my first attempt at RWD ended up with 7, which is too many! When I get the time and motivation I will re-work it, as I’ve learnt a lot since then and believe I could do better.

Maybe this is a case of not knowing what I don’t know, but I don’t see this as bad. I have a specific way I want my web page to appear at different widths, and I don’t like “dead spots”, so I change things with each minor width change so things always look good.

@SamA74

@felgall

assuming you started with decent CSS in the first place the combined code in the media queries should be only a small fraction of the code outside the media queries (since it only relates to those positioning and width values that need to change).

I would agree. If the intial css is kept as fluid as possible, fewer queries will be needed. Too many queries can be a symptom of rigid elements.

Or it could be a sign of designing for “the look” first and the code second.

[felgall]

@mikey_w

I don’t agree with that. If you have a light RWD, then yes, I agree. But my home page has about 6-7 stages/break-points to take it from 320px to infinity.

So with the CSS properly designed those 6 or 7 media queries should make up somewhere between 10 and 20 percent of the total CSS. If it takes up more than 25% then your original CSS has problems.

[mikey_w]

@felgall

So with the CSS properly designed those 6 or 7 media queries should make up somewhere between 10 and 20 percent of the total CSS. If it takes up more than 25% then your original CSS has problems.

They take up less than 25%.