Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Group media queries #950

Closed
Soviut opened this issue Sep 11, 2012 · 64 comments
Closed

Group media queries #950

Soviut opened this issue Sep 11, 2012 · 64 comments

Comments

@Soviut
Copy link

Soviut commented Sep 11, 2012

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
Copy link
Member

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

@Soviut
Copy link
Author

Soviut commented Sep 11, 2012

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
Copy link
Member

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
Copy link
Author

Soviut commented Sep 11, 2012

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
Copy link
Author

Soviut commented Sep 11, 2012

Here's some documentation from Mozilla

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

@lukeapage
Copy link
Member

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
Copy link
Member

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

@lukeapage
Copy link
Member

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

@Soviut
Copy link
Author

Soviut commented Sep 11, 2012

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
Copy link
Member

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
Copy link

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/[email protected]");
  }
}

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
Copy link
Member

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
Copy link
Author

Soviut commented Oct 24, 2012

+1 for @media-group

@Leegorous
Copy link

+1 @media-group

@lukeapage
Copy link
Member

The other option would be to have a global option for grouping true/false.

@Soviut
Copy link
Author

Soviut commented Mar 22, 2013

Hmm, this is probably a good idea. Would there be any case where selective grouping would be necessary?

I think in most cases, people just want their media queries more compact so a global option for now might be the way to go. Should any one claim to need selective grouping, new keywords could be added later.

+1 for a global grouping option.

@lukeapage
Copy link
Member

yes.. because we saw with @import that adding multiple keywords was not the way to go and adding an option is less controversial.

@Soviut
Copy link
Author

Soviut commented Mar 22, 2013

I'd say add the option since it would be useful immediately and would be able to co-exist as an override with a selective import should it ever be created.

@Soviut Soviut closed this as completed Mar 22, 2013
@lukeapage lukeapage reopened this Mar 22, 2013
@AoDev
Copy link

AoDev commented Apr 17, 2013

Hello, I just saw this issue and wanted to share a little app I made when I needed to group media queries. This is not a finished app. More like some research for a future tool. So I just want to show you the idea, because I really think it's something that must be implemented. (there can be bugs and other problems) but I've tested with my last project which includes twitter bootstrap and it work properly. (no problem with the order of rules) let me know ;)

http://mqhelper.nokturnalapp.com

@ghost
Copy link

ghost commented Apr 29, 2013

Hello!

Is someone assigned to this? It's a great feature which could be very useful to decrease css file when created with less. And in this way, It will be easier for developers to work with all these @mqs.

@DaveKin
Copy link

DaveKin commented Apr 30, 2013

@AoDev mqhelper is definitely a step in the right direction, I could see it being useful as part of a CSS linting process for now. I think it just needs the core functionality extracting from the front-end stuff in your demo.

@AoDev
Copy link

AoDev commented Apr 30, 2013

Yes but the goal of my app is not to be part of some "real tool". I just saw a lot of people here wondering if grouping media queries could be a problem and wanted to show that it can be done. The code is there for the devs of less if they want to have an idea and use parts of it. But I can make it a "real" module if you want :)

@DaveKin
Copy link

DaveKin commented Apr 30, 2013

I already managed it, it's a neat piece of work, thanks.

@matthew-dean
Copy link
Member

@Soviut @lukeapage I think selective grouping makes the most sense. All or nothing wrecks havoc on trying to maintain the cascade. Should be something similar to extend, or maybe literally adding a group keyword. Like this syntax would be f'ing great:

@tablet: (max-width: 979px);

.a {
  color: yellow;
  @media @tablet group {
    color: red;
  }
}
.b {
  background: black;
  @media @tablet group {
    background: white;
  }
}

//output
.a { color: yellow; }
.b { background: black; }
@media (max-width: 979px) {
  .a { color: red; }
  .b { background: white; }
}

@JohnCashmore
Copy link

There is a solution for this https://github.com/buildingblocks/grunt-combine-media-queries however it only orders by min width at the moment so is mainly useful for mobile first sites.

@danielkatz
Copy link
Contributor

IMO it makes sense to generalize the problem to scope grouping control which will provide solution for issue #930

@ivankravchenko
Copy link

@FranckErnewein
Copy link

Great tool @Krava ! thanks

@NunoBentes
Copy link

Excelent!!! IMO it makes all the sense implement KRAVA´s feature on LESS

@FrankFang
Copy link

+1

@lukeapage
Copy link
Member

I want to do it as a plugin. should be not too hard. too much to do though!

@matthew-dean
Copy link
Member

I think plugins should take lower priority than having a system to auto-load plugins (options.json). But yes, a plugin makes sense as an additive feature.

@hitautodestruct
Copy link

Has this option been implemented yet?
This would probably cut down my outputted css by half as I use media queries within components and would be happy to have them grouped at the output stage.

Regarding slector reordering, if you use a "group" keyword to group something you are aware that it will be removed from the current logical flow and placed in a grouped area.

@FrankFang
Copy link

http://helloanselm.com/2014/web-performance-one-or-thousand-media-queries/
According to this article, it's not necessary to group the media querys.
But a plugin is good.

@Soviut
Copy link
Author

Soviut commented Mar 25, 2014

It's not so much an issue of performance as it is the size of the resulting CSS file. Dozens of @media screen and (max-width: 480px) strings start to add up in terms of CSS file size.

@hitautodestruct
Copy link

I have asked this question on SO and somebody gave a partial answer to this issue.

@Soviut
Copy link
Author

Soviut commented Mar 25, 2014

@seven-phases-max gave you the answer and referred back to this issue in his answer. Very meta ;)

@gyopiazza
Copy link

I definitely prefer the mixin method to merge the media queries, as opposed to post processing them. This allows for easier typing and more control over what gets merged and how.

Here in the comments you can see the solution I use in all my projects:
#950 (comment)

@Soviut
Copy link
Author

Soviut commented Mar 25, 2014

I just did a search and found two grunt plugins that do media query grouping:

https://github.com/buildingblocks/grunt-combine-media-queries

https://github.com/Se7enSky/grunt-group-css-media-queries

@hitautodestruct
Copy link

Combine media queries is also available for gulp.
http://github.com/konitter/gulp-combine-media-queries

@bassjobsen
Copy link
Contributor

@matthew-dean
Copy link
Member

Closing since this is supported by a plugin, and isn't a priority to move into core (AFAIK - @less/admin correct if this is wrong).

@nfq
Copy link

nfq commented May 18, 2015

@gyopiazza I have a question about #950 (comment) above: why do you need to initialise the mixin? I mean, the CSS compiles without the init. I guess I am trying to understand best practices and usage.

@seven-phases-max
Copy link
Member

@nfq This is not quite an initialization but just "default" empty definition. It's necessary in case you don't provide your custom .step*() mixins (i.e. it's assumed that you may have these things in different files, e.g. "default" .step*() definitions and their rendering are in some generic utility/library code, while custom .step*() definitions are in your theme/project specific code).

@gyopiazza
Copy link

@nfq It's actually not necessary. Edited :) Edited again, oh my.
As @seven-phases-max mentioned, it's useful to avoid errors in case you don't use the mixins in your code, since the media-queries will call the non-existent mixin.

Btw, the advantage of this technique is that combining media queries slows down compilation time (a bit).

@nfq
Copy link

nfq commented May 18, 2015

@gyopiazza Thanks for the quick reply. I don't mind the compilation time, and for huge projects, I definitely prefer grouping all media queries at the bottom of the main stylesheet. I tried a few of the plugins but found your way the easiest for our use case and the most convenient. Thanks!!

@nfq
Copy link

nfq commented May 18, 2015

@seven-phases-max Thanks, your answer makes sense. I use less a lot, but haven't yet understood the best way to achieve certain things!

@bassjobsen
Copy link
Contributor

Notice that also clean-css support @media merging since v3, and so does the less-plugin-clean-css

with main.less:

header {
    color: green;

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

footer {
    color: green;

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

lessc --clean-css="advanced" main.less outputs:
footer,header{color:green}@media only screen (max-width:500px){footer,header{color:red}}

less-plugin-clean-css sets the --skip-advanced true by default you should explicit set the advanced option for @media merging

@gyopiazza
Copy link

@nfq With the "mixin approach" media queries are still compiled at the bottom (or anywhere you declare them).

@nfq
Copy link

nfq commented May 20, 2015

@gyopiazza thanks, yeah. Happy with this approach!!

@bassjobsen I'll definitely use this on a bigger project. I haven't actually started using Less plugins yet. Thanks for the tips!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests