SCSS: Inline media queries vs separate media query blocks

[magicspon]

Hello…

Version A:

.hello {
    width:100%;
    @include custom-media($min: $desk-start) {
        width: 85%;
    }
    .hugh {
        display: block;
        @include custom-media($min: $desk-start) {
            display: inline-block;
        }
    }
}

Version B.

//_layout.scss
        .hello { 
            display: width: 100%
            .hugh {
                display: block;
            }
        }
    // _mq.scss
        @include custom-media($min: $desk-start) {
            .hello { 
                display: 85%;
                .hugh {
                    display: block;
                }
            }
        }

I prefer to write my media queries using version A. That way all the elements styles are bundled together. However I’ve found writing my media queries this was adds a fair wack to the file size. As each style is wrap in it’s own media query and selector… lots of repeating media queries.

I’ve heard gzip compresses repetitious code quite well. Would this make up for the increased file size?

Does anyone have any thoughts on this?

[Alen]

There shouldn’t be any file size difference. Whether you’re placing your include within element block or as a separate declaration. Both will generate same code.

On that note, don’t worry too much about CSS size… if you want to make speed improvements, optimize images instead.

As to your original question, I like to put my includes inline… so:

.el{
  color : red;
  @include mq($tablet){
    color : green;
  }
  @include mq($desktop){
    color : black;
  }
}

[magicspon]

Hello,

There shouldn’t be any file size difference. Whether you’re placing your include within element block or as a separate declaration. Both will generate same code.

The code generated won’t be the same. Version B would generate one media query. Version A would create two media queries.

[Alen]

You are wrong.

@mixin mq($media)
{
    @if $media == one{@media only screen and (min-width: 30em){@content}}
    @if $media == two{@media only screen and (min-width: 40em){@content}}
}

/* INLINE */
.el{
    color:red;
    @include mq('one'){ color:pink; };
    @include mq('two'){ color:orange; };
}
/* NOT INLINE */
.other{ color: red; }
@include mq('one'){ .other { color:pink; }};
@include mq('two'){ .other { color:orange; }};

Compiles to:

/* INLINE */
.el {
  color: red; }
  @media only screen and (min-width: 30em) {
    .el {
      color: pink; } }
  @media only screen and (min-width: 40em) {
    .el {
      color: orange; } }

/* NOT INLINE */
.other {
  color: red; }

@media only screen and (min-width: 30em) {
  .other {
    color: pink; } }
@media only screen and (min-width: 40em) {
  .other {
    color: orange; } }

Same?

[magicspon]

Sorry, I could have probably asked the question a little better….. version A generates this:

.hello {
  width: 100%;
}
@media only screen and (min-width: 1024px) {
  .hello {
    width: 85%;
  }
}
.hello .hugh {
  display: block;
}
@media only screen and (min-width: 1024px) {
  .hello .hugh {
    display: inline-block;
  }
}

version B generates:

.hello {
  width: 100%;
}
.hello .hugh {
  display: block;
}

@media only screen and (min-width: 1024px) {
  .hello {
    width: 85%;
  }
  .hello .hugh {
    display: block;
  }
}

So you see version A has two media query block (@media only screen and (min-width: 1024px) x 2), version B has one media query block )(@media only screen and (min-width: 1024px) x 1).

Thanks

[Alen]

Well you are writing one extra query in the first example and in the second you are manually placing all the styles within that media query. So it’s about 25 characters more (example A). With Gzip on, I wouldn’t worry about it. Gzip finds simila strings of text and caches them, then it just uses cached version to send to the browser.

For me writing inline let’s me stay in the same context and it’s very explicit in its meaning when you look at the code. I don’t have to jump around looking for my media queries.

Hope that helps,
-Alen

[Kitty Giraudel]

I think there is a misunderstanding: the OP makes a distinction between writing the @media directives in the selectors (version A), and have a single @media block (maybe in a specific file?) wrapping all rules for a particular screen width (version B). He’s right in saying version A will output several @media blocks (that could be merged) while version B will obviously only output a single @media block.

Now back to the original question: you should be serving your assets with gzip which is blazingly good when it comes to compress the same string again and again. If there is a difference in filesize before gzip, it will be hardly noticeable once gzip has done its thing.

If you’re really concerned about having multiple similar @media directives in your final CSS, you can still use a gem to merge those blocks like this one: https://github.com/aaronjensen/sass-media_query_combiner. However note there is a good reason why Sass doesn’t do this already: merging similar @media blocks can alter CSS order and as you know it can have repercussions.

Long story short: it makes no difference whatsoever. Do as you like.

PS: I use version A. It makes it easier to understand how components behave at different screen sizes. PS2: I should have read previous answer. Everything has been said already. :D

[Alen]

@HugoGiraudel a.k.a Sass Master, great point about the CSS order.

[magicspon]

@HugoGiraudel and @Alen

Thanks for your replies. I’ve not just got to convince the rest of my team to write there mq inline, oppose to writing them in a seperate _scss file.

Thanks

[torrey.scott]

Old post, but I still happened across it so hopefully it’s still relevant. The above answers talked about file size, and came to the same conclusion as me. Inline media queries will increase file size, but it’s negligible. I thought perhaps performance would also suffer with so many separate media queries, so I did a bit of checking into that and it looks like the browser caches separate media queries so it really shouldn’t impact performance. The caveat here is that if you’re using a ton of different media queries you will run into performance issues. My most helpful article on the matter was this: https://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/

[Author]

Posts