Is There an Advantage in Grouping CSS Media Queries Together

Is there an advantage in grouping css media queries together?

A bit late to the party, but based on the tests below the performance impact seems to be minimal. The test shows the rendering times for an example page with 2000 separate and combined media queries, respectively.

http://aaronjensen.github.com/media_query_test/

The main benefit seems to be in file size more than anything else - which, if you're compressing your CSS for production, will be substantially reduced anyway.

But ultimately, as the linked post below puts it:

"If you have 2000+ media queries in your CSS, I think that you may want to reconsider your UI development strategy versus using a gem to re-process your CSS."

Blog post detailing the issue: https://web.archive.org/web/20140802125307/https://sasscast.tumblr.com/post/38673939456/sass-and-media-queries

Grouping styles by selector or media query first

After doing ample research, I've personally arrived at this answer

1. Keeping the styles for the same selector at different breakpoints is good for the developer experience - it keeps CSS more maintainable to be able to see a selector's behavior at every breakpoint all in the same place.
2. In vanilla CSS, the pattern for doing this can be a bit ugly and unwieldy - if it's not minified, it can also lead to some performance issues due to duplicate media queries. Ruling: avoid grouping selectors and their media query counterparts in vanilla CSS - it's probably more trouble than it's worth.
3. If you're using SCSS, absolutely nest your media queries inside your selectors. It's clean and more maintainable. With the right compilation you avoid duplicate media queries, avoiding the earlier discussed performance issues. Learn more here

Bootstrap mobile first and media query grouping

According to the style codeguide written by @mdo (the creator of bootstrap) http://codeguide.co/#css-media-queries media queries should be 'as close to their relevant rule sets whenever possible'

LESS, Media Queries, and Performance

Its almost impossible to give you a totally accurate answer.

When asking about performance the typical answer is to profile it and see what you get. Fix the slowest part first, then repeat.

You can profile CSS selectors in the Chrome Developer tools:

Ultimately I don't think the media queries will have anywhere near as much impact on performance compared to even a slightly complicated selector.

You can see more information about writing efficient CSS here:

https://developers.google.com/speed/docs/best-practices/rendering

Also with regards to file size and repeated CSS, gzip almost completely nullifies this as the gzip algorithm works best with repeated data.

Can media queries resize based on a div element instead of the screen?

Yes, CSS Container Queries are what you're looking for. The CSS Containment Module is the specification that details this feature.

You can read more about the decade of work, including proposals, proofs-of-concept, discussions and other contributions by the broader web developer community here! For more details on how such a feature might work and be used, check out Miriam Suzanne's extensive explainer.

Currently only Chromium 105+ supports Container queries out of the box, though Safari 16 will include support as well. Hopefully it won't be much longer before we see a robust cross-browser implementation of such a system. It's been a grueling wait, but I'm glad that it's no longer something we simply have to accept as an insurmountable limitation of CSS due to cyclic dependencies or infinite loops or what have you (these are still a potential issue in some aspects of the proposed design, but I have faith that the CSSWG will find a way).

---

Media queries aren't designed to work based on elements in a page. They are designed to work based on devices or media types (hence why they are called media queries). width, height, and other dimension-based media features all refer to the dimensions of either the viewport or the device's screen in screen-based media. They cannot be used to refer to a certain element on a page.

If you need to apply styles depending on the size of a certain div element on your page, you'll have to use JavaScript to observe changes in the size of that div element instead of media queries.

Alternatively, with more modern layout techniques introduced since the original publication of this answer such as flexbox and standards such as custom properties, you may not need media or element queries after all. Djave provides an example.

Media queries don't do anything

Tests are usually your best bet. Make sure your media queries are at the bottom most of your prioritized CSS file - to ensure they aren't being overwritten. Regardless how many thousand lines your code is:

1) Comment out all your media queries
2) Run a test, for example:

@media screen and (max-width: 600px) {
    body {
      background-color: black;
    }
  }

3) Resize your browser to a width smaller than 600px, if your background colour changes to black, chances are nothing is wrong with your preprocessors and its time to debug your code.

4) Comment out your media queries one code block at a time until you discover the block that doesn't work.

5) Fix it. Relief

Structuring CSS (SASS, LESS) files by elements, by function and by media queries: 3D code structure?

CSS is already a structured language. For better or worse, the order of your code changes it's meaning. Because of that, it's important that any CSS organization scheme is dictated primarily by the cascade. The other structural aspect of CSS is semantics. Use it to your advantage. The concern of organization is keeping things meaningful and maintainable. The best thing you can do to retain meaning is to show relationships. Relationships are already expressed by semantics.

Put those things together, and you end up with code organized by specificity first and then semantics, but never by external concepts such as type vs. layout or screen-size. Here's my naming scheme:

base/
  - Sass imports and settings - no CSS output.
  - e.g _grid, _colors, _rhythm, etc.
general/
  - Initial CSS baseline with resets, defaults, font imports, and classes to extend.
  - e.g. _reset, _root, _fonts, _icons, _defaults, etc.
layout/
  - The rough outline of the site structure.
  - Not "layout" as a set of properties excluding type, "layout" as the overall site template which might well include typography. 
  - e.g. _banner, _nav, _main, _contentinfo, etc.
modules/
  - All the details. First by effect (classes/general), then by widget (ids/specifics).
  - e.g. _users, _admin, _product-lists etc.

Media-queries should stay as close as possible to the code they affect. When possible, they go directly inline (with Sass media bubbling). If that becomes bulky, they move outside the block, but never outside the partial. MQ's are overrides. When you override code, it is especially important that you are able to see exactly what is being overridden.

On some sites, you may take this structure farther. I've occasionally added two folders at the end: plugins/ to manage 3rd-party code, and overrides/ to handle unavoidable (try to avoid them!) location-specific overrides to a widget. I've also gone deeper, adding a fonts/ folder with partials for each font family, or a users/ folder with partials for adding, editing, viewing, etc. The specifics are flexible, but the basic organization remains the same:

• Start general.
• Move towards specifics as slowly as possible.
• Never divide based on any external concepts (type/layout, screen-sizes, etc).

Media queries: Overriding CSS rules vs defining screen specific CSS rules

<link> tags with unmatched media queries are download with low priority so that they don't block page rendering, but are still downloaded in order to be available in case media properties change (for example by rotating a smartphone or by zooming out a desktop browser). There is an advantage in having separate stylesheets for different media types, but there is also a disadvantage in creating multiple HTTP requests.

Media blocks inside a stylesheet are already downloaded and I would assume that they are compiled anyway, so it's not really the same as a media query in the tag. But if a certain set of rules is only relevant to a certain width and is always overriden in wider screens, it makes sense to tell the browser that by encapsulating it inside a media query. It's not just about the original page rendering but about any change to the window or to the DOM that requires a redraw - the less rules the browser would need to evaluate, the faster it would be.

---

Related Topics