Improve property merging algorithm

[GoalSmashers]

a{color:white;color:black;color:red;}

does not get minified into

a{color:red}

That's because we assume adjoining properties to be used deliberately, e.g.:

a {
  color:rgba(0,0,0,0.5);
  color:#888;
}

or

a{
  background:#fff;
  background:-moz-linear-gradient(...);
  background:-webkit-linear-gradient(...);
  background:linear-gradient(...);
}

[XhmikosR]

Refs e25a329#commitcomment-4496293

[GoalSmashers]

One way would be to scan for vendor prefixes and functions. This would include cases like display:-moz-inline-box, color:rgba(...) and background:linear-gradient(...).

[Venemo]

In your example, if background:#fff comes after the other definitions, it will override them.
For example, in foo{color:rgba(0,0,0,1);color:#fff} the color:#fff wins even in browsers that support rgba(0,0,0,1) - we only have to worry about the cases when rgba(...) comes after #...

[Venemo]

NOTE: It seems that in IE, this fallback technique doesn't always work, see this SO question. :( There is a hacky workaround, though.

[XhmikosR]

The fallback color is supposed to be a fallback one if it comes before rgba... Otherwise it's not our job to fix it in my opinion.

Clean-css should do what the browsers do; ignore the previous declaration regardless of what it is. This behavior is what the person who wrote the code expects, even though it's wrong.

[GoalSmashers]

@Venemo - correct, background:#fff should come first. It's fixed.

@Venemo, @XhmikosR - indeed we should not be smarter than the authors about their intents. If it fails in the browser then it is not our concern.

[Venemo]

@GoalSmashers Same goes for color. :)

[Venemo]

I've implemented a logic for this in my fork.

The idea is the following: "more understandable" properties always override "less understandable" properties but not the other way around. This ensures that the result will be optimal but will also keep any fallbacks where feasible.

Some examples

foo{color:red;color:rgba(1,2,3,0.5);color:#fff}
/* is transformed into */
foo{color:#fff}

/* but */

foo{color:red;color:#fff;color:rgba(1,2,3,0.5)}
/* is transformed into */
foo{color:#fff;color:rgba(1,2,3,0.5)}

/* combined with shorthand compaction */

foo{background-color:#fff;background:url(aaa);background-color:rgba(1,2,3,0.5)}
/* is transformed into */
foo{background:rgba(1,2,3,0.5) url(aaa)}
/* because background will clear out the preceding background-color anyway */

For colors, I define understandability like this: (named|hex) > rgb > (rgba|hsl|hsla)

For background image: none > url > anything else > none (so that none both overrides anything and is overridden by anything)

[GoalSmashers]

That's the way it should work. Well done 💯

[Venemo]

@GoalSmashers I was unaware of this, but whenever there's a URL in the input, I get something like __ESCAPED_URL_CLEAN_CSS0__ inside the property optimizer.

I have two questions:

• Can I safely assume that anything that begins with __ESCAPED_URL_CLEAN_CSS is a placeholder for a URL?
• Are there any other similar mechanisms?

[GoalSmashers]

Actually any free text is escaped this way to avoid processing via regexps (so comments, URLs, content:'...', selectors like [data-json='…']). See all modules under lib/text.

So it is safe to make that assumption.