Unsafe grouping

[marvinroger]

Hi,

I recently saw a couple of interesting comments about unsafe media query grouping. Correct me if I am wrong, but I think node-css-mqpacker is affected by this problem - I am not able to test for now -. There must be a way to solve this, by ensuring that media queries are not conflicted.

This is highly problematic as now the package may break website render and therefore is not suitable for production.

[hail2u]

You're right. But I don't think it can be solved in CSS without HTML. This problem depends on HTML class attribute's value.

But, yes, it's not safe for production. I'll add section to README about this problem. Thanks!

[marvinroger]

The issue goes deeper than that. Say:

• HTML

<div id="square">I am green</div>

• CSS

#square {
  width: 100px;
  height: 100px;

  text-align: center;
  line-height: 100px;
}

@media (min-width: 1px) { 
  #square { background-color: red; }
}
@media (min-width: 2px) { 
  #square { background-color: yellow; }
}
@media (min-width: 1px) { 
  #square { background-color: green; }
}

If viewport is higher than 2px, the square must be green. (http://jsfiddle.net/9upL6joa/)
However, after packed up with latest version as of now (v1.0.0), the square gets yellow. (http://jsfiddle.net/rb9Lkt7a/)

With only a common ID selector, so the problem don't depend on HTML class.
I perfectly agree with the fact that the @media (min-width: 2px) is unnecessary, we can safely remove it here. But in a bigger codebase, this could happen, and a post-processor cannot expect the code it processes to be perfectly optimized.

I am pretty sure this can be resolved by keeping rules ordered (and therefore some same mediaqueries would not be merged), but the logic behind might be pretty hard to implement (I don't have any experience in post-processing).

[hail2u]

I design this tool for a proper CSS codes. Buggy CSS like your second example should be fixed before post-processing.

[lunelson]

From what I can tell at the pleeease live demo, the grouping seems based on wherever a rule first appears; I would suggest an alternative, that media queries be combined based on their values: for min-width queries from lowest to highest, and for max-width queries the other way. This is a logic that one could work with I think, when writing the CSS

[oilvier]

+1 with @lunelson

My CSS file looks like this :

/* Grid system */
@import "grids.css";

/* Regular CSS */
.header {}
.footer {}
...

/* Responsive */
@import "tablet.css";
@media only screen and (max-width: 600px) {
    /* Specific rule for that specific breakpoint */
}
@import "phone.css";

In grids.css I have the following :

.grid-1 {width:100%;}
.grid-1-2 {width:50%;}
...

@media only screen and (max-width: 800px) {
    .tablet-grid-1 {width:100%;}
    .tablet-grid-1-2 {width:50%;}
    ...
}

@media only screen and (max-width: 400px) {
    .phone-grid-1 {width:100%;}
    .phone-grid-1-2 {width:50%;}
    ...
}

In tablet.css :

@media only screen and (max-width: 800px) {
    /* Specific style for tablets */
}

and in phone.css :

@media only screen and (max-width: 400px) {
    /* Specific style for phones */
}

Every rules are correctly rendered in my processed file, as the first media queries encountered in grids.css are the same that I use in tablet.css and phone.css.

The problem come from the additionnal media query @media only screen and (max-width: 600px) which is rendered at the end of the processed file because it's the last media query.
If I put something in that media query that I want to override in phone.css it won't work because this last media query is rendered after phone.css in the final file.

[Maks3w]

I've open the pull request #24 where it's suggested to follow a specific order of media queries for avoid this kind of collateral effects when grouping.

In fact the PR ensure if the CSS developer write the media queries with the proposed order then the post processed CSS file will maintain the same order.

I invite you to discuss this proposal in the PR comments

[Volker-E]

Same problem here, like the one of @oilvier - but I guess, it should be packed into another issue.
The media queries should at least be output in ascending order of min-width values IMHO.

[lunelson]

In the meantime you can hack the ordering by outputting the queries you are going to use, somewhere at the top of your stylesheet, with dummy rules if necessary, e.g.

@media screen and (min-width: 20em) { body:before { content: ''; } }
@media screen and (min-width: 30em) { body:before { content: ''; } }
@media screen and (min-width: 40em) { body:before { content: ''; } }
@media screen and (min-width: 50em) { body:before { content: ''; } }

... and the no matter in what order you use them later, they should appear in the mqpacker output in that order

[Volker-E]

@lunelson Exactly what I did too. :) But it's a hack, which contradicts the first and foremost usecase of css-mqpacker by inserting extra (unnecessary) rules in output

[lunelson]

True, but if mqpacker offers this as a feature it should be togglable somehow, and it's still not clear what mqpacker should do if you write both max-width and min-width queries, or if you write queries that use both

[Maks3w]

I suggest don't think in the large final result of all the possible things. Let's start the way step by step and improve the things when needed