Group media queries

[Soviut]

While the media query bubbling is great:

header {
    color: green;

    @media only screen (max-width: 500px) { color: red; }
}

footer {
    color: green;

    @media only screen (max-width: 500px) { color: red; }
}

Less generates fairly bloated code because it repeats the mediaquery selector each time its declared in the less file:

header {
  color: green;
}
@media only screen (max-width: 500px) {
  header {
    color: red;
  }
}
footer {
  color: green;
}
@media only screen (max-width: 500px) {
  footer {
    color: red;
  }
}

It would be nice if media queries could be grouped if they're identical:

header {
  color: green;
}
footer {
  color: green;
}

@media only screen (max-width: 500px) {
  header {
    color: red;
  }
  footer {
    color: red;
  }
}

[lukeapage]

How do you do that without potentially altering the meaning by having the statements re-organised?

[Soviut]

I don't think the meanings could be altered. This would be exactly the same as collapsing normal redundant tags. For example:

body {
    background: white;
}

body {
    padding: 0;
    margin: 0;
}

Would be collapsed to:

body {
    background: white;
    padding: 0;
    margin: 0;
}

This is even more the case with media queries because they're special top level selectors that act as an control layer on top of normal element selectors. Basically, they only have a single meaning and aren't affected by the rest of the css within the file.

Further, less already maintains the order of the bubbled media queries, it just creates a lot of redundant selectors for the exact same query. If they could be buffered and written to a single query at the end of processing it would be much neater and producer smaller css output.

[lukeapage]

What are the rules around selector complexity inside media queries? Do the
queries bump complexity up and override any ordering? Can you point at any
specs?

[Soviut]

Essentially, yes. Media selectors are like IF statements that wrap around normal style rules and only apply if the condition of the query is met. For example, if the width of the browser is less than a certain number of pixels then the rules within the query are turned on and override the existing rules.

So having lots of identical queries with a single style each would be functionally identical to one query with all the styles inside it. As long as the query is the same.

[Soviut]

Here's some documentation from Mozilla

https://developer.mozilla.org/en-US/docs/CSS/Media_queries

[lukeapage]

what I mean is in this example.. the div goes red - meaning re-ordering the media queries (both for screen) would change the meaning of the css

@media screen {
    div {
        background-color: green;
    }
}

div {
     background-color: red;
}

@media screen {
    div.pink {
        background-color: pink;
    }
}

[cloudhead]

It should only combine if the rulesets follow each other directly.

[lukeapage]

which they don't in @Soviut original example, making this feature request of limited use in IMO

[Soviut]

I agree, but I don't see how this would apply to bubbled media queries? Remember, bubbled queries are a bit of syntactic sugar; You can't normally embed a media query inside another selector. So it could safely be assumed that any time you encounter a bubbling query to group it with identical bubbling queries in the order they arrive in.

[lukeapage]

If you have two bubbled media queries next to each other that can be combined I think it would be very obvious to do that in the less.. can you give an actual example where it would be safe to combine the media queries and it makes sense to keep them separate in the less?

[kamranayub]

When dealing with retina images, we've wrapped the complex media query inside a mixin and created sprite mixins, so we have this all over the place... it increases the output CSS but it's more maintainable.

For example, here's our sprite mixin:

.sprite(@spritePath, @hdpiPath, @x, @y, @size: auto) {
    background-image: url(@spritePath);  
    background-repeat: no-repeat;
    background-position: -1 * @x -1 * @y; // Negativize the value
    .background-size(@size);
    @media @mediaRetina {
        background-image: url(@hdpiPath);
    }
}

Where @mediaRetina is:

@mediaRetina: ~"only screen and (-webkit-min-device-pixel-ratio: 1.3), only screen and (min--moz-device-pixel-ratio: 1.3), only screen and (-o-min-device-pixel-ratio: 4/3), only screen and (min-device-pixel-ratio: 1.3), only screen and (min-resolution: 124dpi), only screen and (min-resolution: 1.3dppx)";

Then below, we create more mixins to wrap each sprite element like this:

#sprite
{
    .header-logo()
    {
        .sprite(@globalSpritePath, @global2XSpritePath, 22px, 0, 384px 288px);
        width: 94px;
        height: 59px;
    }
}

And use it in other LESS file(s) like this:

h1 {
    width: 94px;
    height: 59px;

    a {
        #sprite > .header-logo();
    }

}

In this case, the generated CSS looks like:

h1 a {
  background-image: url("/images/sprite-global.png");
  background-repeat: no-repeat;
  background-position: -22px 0;
  -webkit-background-size: 384px 288px;
  -moz-background-size: 384px 288px;
  -o-background-size: 384px 288px;
  background-size: 384px 288px;
  width: 94px;
  height: 59px;
}
@media only screen and (-webkit-min-device-pixel-ratio: 1.3), 
       only screen and (min--moz-device-pixel-ratio: 1.3), 
       only screen and (-o-min-device-pixel-ratio: 4/3), 
       only screen and (min-device-pixel-ratio: 1.3), 
       only screen and (min-resolution: 124dpi), 
       only screen and (min-resolution: 1.3dppx) {
  h1 a {
    background-image: url("/images/sprite-global@2X.png");
  }
}

Now imagine this case being repeated many times. Without grouping, the only way to alleviate this extra weight is to move every retina style into a dedicated LESS file, which may work for small sites, but is unrealistic for a large site.

This is where it makes sense to group them and keep them separated, especially if you have a big site with a lot of modules (like ours).

I know what you mean about overriding styles, though, and I'm not sure you could safely implement this exact feature without potentially messing with the cascading a designer might want.

To me this sounds more like being able to define a "section" (a placeholder) and then defining styles to be placed in it, in whatever order they're written. This is pretty common in server-side templates, where you have a "scripts" or "head" section and then your pages can inject content into them when they're loaded.

So, I'd like to be able to do this in a LESS file essentially:

@media { // retina query
    @renderSection("retina")
}

// in another file
h1 {
    @section retina {
        // retina styles
    }
}

The @section would be replaced on compile with the current selector.

So, my sprite mixin would just become:

.sprite(@spritePath, @hdpiPath, @x, @y, @size: auto) {
    background-image: url(@spritePath);  
    background-repeat: no-repeat;
    background-position: -1 * @x -1 * @y; // Negativize the value
    .background-size(@size);
    @section retina {
        background-image: url(@hdpiPath);
    }
}

It doesn't need to be this syntax (or implementation), I'm basing it off the ASP.NET Razor syntax since that's what I'm familiar with and I like the syntax.

[lukeapage]

Its a good example.. and a good use-case.. You could do

@media-section

(or media-group) which would then tell less to group the media together (optionally merging it into the media query if it already existed which would allow you to pull the rules to where-ever you wanted to put them).. maybe thats what you mean?

I'm tempted to think its a good idea (and not too difficult to implement)

[Soviut]

+1 for @media-group