As developers we should always work on “highly comprehensive maintainable code” and use a tool that will turn it into an “ugly optimized code”. That’s what minifiers do.
In our particular case, individual media queries should be automatically grouped as some persons have already said here.

Two major breakpoints in different CSS files. “Global” and “Wide”.

Each file has an index at the top and is split into easy to understand sections – eg: 4=outside structure, 5=individual pages.

At then end of each of those I have some minor breakpoints. These are based on the original design’s columns at fairly equal intervals. I find that constant resizing of the screen to see when things breaks will create too many breakpoints. Using common device widths is pointless as these will change.

I played with the idea of having each elements style (link in your example) have its own media query. The problem is you end up with millions of the same delarations of media queries – not good for bloat or in case you change your mind.

The “global” css file is served to all device widths – if there is something that I definitely don’t want the wide devices to see I hide it using a media query.

Both global and wide is served to lessthanIE9. BUT I make the website non-liqued for those browsers. That way I don’t have worry about advanced CSS that is used to lay the site out or that is served up by the inner media queries. What I do is make sure that lessthanIE9 can understand ALL the css it needs to lay out the “desktop” version.

Hope that makes sense! – It’s a method that I’m still tweaking and I don’t think anyone really has a one size fits all solution yet.

1. putting styles for various break points in a separate file means that you can quickly and easily turn off ALL styles for that screen width (or device width). It means that you don’t have to go hunting through a file with styles all over the place. It’s also cleaner looking.

2. Performance. Fewer media queries. Better for the user

3. All that being said – it IS much easier from a development perspective to edit all the various versions of an element at once. Without having to hunt through three (at least) different files.

So I guess it comes down to what the goal is for a particular project. And ultimately how extensive your media query styling will be. If you are adding one or two fixes for a particular screen size – why not put it all in the same file?

I’ve recently been leaning towards separate files. But I’m ready to be convinced otherwise.

Note that OOCSS has *two* main principles:

1. Separate structure and skin.
2. Separate container and content.

You already mentioned (2): avoid location-dependent styles. (1) is about organising your CSS so that you can reuse existing styles to create new variations.

For example, suppose you have a CSS3 button with gradients, shadows, and rounded corners. If you want to make a blue button and a red button, don’t repeat all that code. Instead, specify a base style (e.g. the red button) and extend it with a new class (to make it blue instead). This means using multiple classes on the HTML element.

Also note that OOCSS — when done well — typically results in a significant reduction in code, not an increase. Surprisingly, this holds true for the HTML as well as the CSS. The CSS reduction is much greater, however.

It may be clearer/easier for the developer to read, but if it affects the rendering time in the browser then should we not lump all rules together still?

Interesting point though to see if the extra stylesheets are actually loaded anyway, then just not used, or whether they are loaded on request, at certain widths. Surely if they are all loaded then it makes a mockery of the mobile-first approach.. As I understood, the very point of this is that extra css (and images) are only loaded on bigger viewports. I’m going to go and do some tests now…

However, upon reflection, I am wondering if grouping based on media queries rather than elements/classes might cut down on repetition of the @media criteria. in large complicated stylesheets might this have any significant impact on the stylesheet size?