postcss-merge-rules can be unsafe in certain conditions

[kizu]

Merging rules with common declarations can be unsafe when the selectors have different browser support:

a{color:blue}b:nth-child(2){color:blue}

becomes

a,b:nth-child(2){color:blue}

While the support for those selectors is different, so if you'd merge them, IE8 won't render anything, while in the non-optimized case it would render the first rule.

[ben-eb]

Good call. What do you think about making this optional for those consumers who don't want IE8 support?

[kizu]

Ideally, there should be a way to detect such things for any optimization and then look at the general browser support option (like for autoprefixer) decide what to use. There could be a lot of optimizations that are possible only for a limited set of browsers, or which could possibly break something for older browsers, so it should be a single framework that could be used through all of the cssnano plugins.

[ben-eb]

https://github.com/ben-eb/postcss-merge-rules/pull/9

[choffmeister]

We found another situation, where this rule is unsafe. Consider this less source:

.list-unstyled {
  list-style-type: none;
  margin: 0;
  padding: 0;
}

ul {
  .list-unstyled;
  margin-top: 10px;

  li {
    .list-unstyled;
  }
}

This yields the following css source:

.list-sorting-item ul {
  list-style-type: none;
  margin: 0;
  padding: 0;
  margin-top: 10px;
}

.list-sorting-item ul li {
  list-style-type: none;
  margin: 0;
  padding: 0
}

After minifying it with postcss-merge-rules one gets:

.list-sorting-item ul {
  margin-top: 10px;
}

.list-sorting-item ul,.list-sorting-item ul li {
  list-style-type: none;
  margin: 0;
  padding: 0
}

Due to reordering now the margin: 0; again overwrites the margin-top: 10px.

[ben-eb]

@kizu If you cannot be bothered to review the functionality which I wrote for you back in October, I guess that I cannot help you with this issue.