<issue_start><issue_comment>Title: "p{foo:bar;foo:baz}" and "p{foo:bar}p{foo:baz}" are minified differently
username_0: 'p{foo:baz}'
```

If I pass `{advanced:true}` to the constructor, the second example produces `"p{foo:bar}p{foo:baz}"` instead.

I'm using `clean-css` to normalize style sheets to test a [JS to CSS compiler](https://github.com/username_0/j2c/) (probably an anathema for designers, I know), but I can't get it to behave accordingly in [this case](https://github.com/username_0/j2c/blob/95fe389f98b1c06fa719b53c85c596a95e00968d/test/test.js#L129), where my code generates `"p{foo:bar}p{foo:baz}"`.
<issue_comment>username_1: This is in fact intentional, as take the following two declarations:

```css
a{display:inline-block;display:block}
```

```css
a{display:inline-block}/* some other properties */a{display:block}
```

In the first one, you declare two display properties adjacent to each other so it's highly likely you want to do a fallback, when one is not understood (more on this in a second) then the other one is picked. It's a common pattern in CSS. 

In the 2nd one these are in two different selectors so it's less likely the author intention was to have a fallback, thus the display:block overrides display:inline-block.


However this is far from perfect so we started merging properties based on understandability, where less understandable properties (take `color:rgba(...)` which IE<9 does not support) cannot be overridden by more understandable, e.g. `color:red`. This is already done for `background`, `color`, `marging`, `padding`, and others: https://github.com/username_1/clean-css/blob/master/lib/properties/compactable.js#L35

Ultimately it will be implemented for all properties, see #290, but you can get a safer behavior using `aggressiveMerging: false` in the meantime.

Hope this helps!
<issue_comment>username_0: That behavior makes sense when processing hand-crafted CSS, which is not my use case.

`j2c` is dumb, and things that are close together in the JS source may end up in consecutive but separate declarations for the same selector.

I ended up switching to `crass` which produces the same output for both inputs.
<issue_comment>username_1: You can get the same behavior in clean-css by using `advanced: false` flag.
<issue_comment>username_0: My bad, I meant `advanced:false` in the first post, and it doesn't suit my use case because it still outputs two rule sets rather than one with both properties. I could have changed the reference output in my test to match it, but in the long run, I wanted a CSS normalizer, which produces identical output for semantically equivalent, but syntactically distinct input, and `clean-css` doesn't do that.

A casting error on my side :-)
<issue_comment>username_1: Ok, makes it makes sense now! I'll close the issue now.<issue_closed>