-
Notifications
You must be signed in to change notification settings - Fork 320
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
Improve property merging algorithm #168
Comments
One way would be to scan for vendor prefixes and functions. This would include cases like |
In your example, if |
NOTE: It seems that in IE, this fallback technique doesn't always work, see this SO question. :( There is a hacky workaround, though. |
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 Same goes for |
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 |
That's the way it should work. Well done 💯 |
@GoalSmashers I was unaware of this, but whenever there's a URL in the input, I get something like I have two questions:
|
Actually any free text is escaped this way to avoid processing via regexps (so comments, URLs, So it is safe to make that assumption. |
Awesome, thanks! |
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)} I would not want this, since I need similar behavior for IE8 fallback unfortunately. |
@tomByrer Even in IE8 or older browsers, the foo{background:#fff url(aaa);background-color:rgba(1,2,3,0.5)} That is, put the "less understandable" syntax after the "more understandable" one: in this case, it will be compatible with older browsers and my property optimizer will not remove it either. |
That's true, ty @Venemo |
Fixed with #249. |
does not get minified into
That's because we assume adjoining properties to be used deliberately, e.g.:
or
The text was updated successfully, but these errors were encountered: