Skip to content
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

Skip merging same properties while allowing same selectors to be merged? #730

Closed
corysimmons opened this issue Feb 7, 2016 · 16 comments
Closed
Milestone

Comments

@corysimmons
Copy link

I want to merge same selectors, but want to keep same properties for fallback reasons.

@jakubpawlowicz
Copy link
Collaborator

You may want to use --skip-aggressive-merging and --skip-compacting together. Hope that helps!

@corysimmons
Copy link
Author

I already tried --skip-aggressive-merging. It doesn't merge same selectors.

a {
  color: blue;
}
a {
  font-size: 16px;
  font-size: 1rem;
}

turns into

a {
  color: blue;
  font-size: 1rem;
}

when I'm looking for

a {
  color: blue;
  font-size: 16px;
  font-size: 1rem;
}

@corysimmons
Copy link
Author

Or is there a way to specify specific properties to ignore?

@jakubpawlowicz
Copy link
Collaborator

Unfortunately, there's currently no way to do that. However it sounds like an interesting option to add.

@jakubpawlowicz
Copy link
Collaborator

However in this very case you just need to specify a compatibility mode --compatibility ie8, since rem units are not supported in IE<9.

@corysimmons
Copy link
Author

I am specifying ie8.

Ah you're right! I was using cssnano which was obliterating it. Thanks!

@jakubpawlowicz
Copy link
Collaborator

👍

@jakubpawlowicz jakubpawlowicz modified the milestone: 4.0 Dec 12, 2016
@jakubpawlowicz
Copy link
Collaborator

On master (4.0 soon):

cleancss -O2 --skip-aggressive-merging --compatibility ie8 ...

Note --skip-aggressive-merging will be gone in 4.0 too, so you can skip this option when #290 gets fixed.

@alexlamsl
Copy link
Contributor

@jakubpawlowicz so with your example, all the level 1 options are still active?

On that note, given the recent proliferation of options at level 1, would it need something like the all shorthand in level 2 for convenience? Having said that, I realise not all of them are even boolean to begin with...

@jakubpawlowicz
Copy link
Collaborator

Fair point. The only two that are not boolean are roundingPrecision and specialComments. Could all perhaps apply to boolean options only? It's also interesting when you take the opposite case, e.g. all: 5, and try applying it to boolean options.

@alexlamsl
Copy link
Contributor

The only useful case I can think of for all at level 1 would be to turn on only specific optimisation at level 2. Would level:{1:false,2:{duplicateRulesRemoving:true}} do that? If so, I guess it's good enough.

@jakubpawlowicz
Copy link
Collaborator

Yes, that's the use case. Alternatively it could be level:{1:{all:false},2:{duplicateRulesRemoving:true}} to keep both options as hashes.

Actually with the 2nd way you could still selectively turn on level 1 optimizations if needed too, e.g. level:{1:{all:false,tidySelectors:true},2:{duplicateRulesRemoving:true}}

@alexlamsl
Copy link
Contributor

@jakubpawlowicz indeed that would be very powerful. Perhaps with #853 you can invert some of those boolean options in level 1 and change specialComments so they all accept false as meaning "leave the source alone"?

@jakubpawlowicz
Copy link
Collaborator

You made a good point about inverting options, because saying all: false on level 1 should mean "disable all" which is currently not the case.

@jakubpawlowicz
Copy link
Collaborator

The updated code on master should do the trick. Thanks @alexlamsl.

@corysimmons
Copy link
Author

👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants