Remove color math
nex3 opened this issue · comments
Sass's support for mathematical operations on RGB colors is misleading and not very useful. Channel-by-channel arithmetic is very difficult to use effectively when trying to produce a given human-comprehensible color transformation, and in all cases the color functions are better suited to the job.
We should begin by emitting a deprecation warning whenever a binary operation is performed for the +, *, -, /, or % operators when one of the operands is a color and the other is either a color or a number. Once the deprecation period is up, we should make all previously-deprecated operations emit errors.
It would be more consistent with the behavior of +, -, and / on other types to have them emit strings for colors once the deprecation period is over. Nevertheless, I think erroring out is the right thing to do. It makes it clearer that something's going wrong for anyone who didn't see the deprecation warnings, and I don't think there are any real use-cases for using those operators in a stringifying way.
Tasks:
- Deprecate existing behavior in
stable. - Remove behavior from
master.
Could you please explain how to port each sass-3 color math operation to a sass-4 equivalent? It is hard to port code when it is unclear how the functions work. Here I try for subtraction:
After much experimentation, I figured out how to port code using the subtraction operator to sass-4:
Original:
.a {
x: white - grey;
}Modified:
.a {
x: adjust_color(white, $red: -(red(grey)), $green: -(green(grey)), $blue: -(blue(grey)));
}Output:
.a {
x: #7f7f7f;
}I find the new code quite needlessly verbose. I’m going to file a bug asking for a new subtract_color() function I guess because that would be helpful and result in much clearer code.
I’ve put example functions which implement all the operators except for mod in #2501
I disagree with the reasons OP has given. While #fff - 10% might not look like it could make sense to anyone, it is quite obvious that it darkens it by 10%. It is much easier to type that than darken(#fff, 10%). I think the feature should be depreciated, however i'd like some way to enable it for those who actually use it. We want to make styling apps easier and faster after all, right? I hope this is reconsidered to some extent, it would really cheer up my dev team and me.
My 2 cents.
I'd like to dispute this change, if that is possible. As i've mentioned in my previous comment, i'd argue that color arithmetic does make sense and that it can reduce code footprint drastically. There was no reason for the removal of this feature, as i'd call it. My team has complained about having to change hundreds of lines of code only because a well-welcome feature was removed because some one thought it wouldn't make sense.
@justablob I added a dissenting opinion here.
Thank you very much, you broke thing what was working for years, and you do it without any real reason, and proposed "alternative" is not a real alternative, because it is not compatible with other Scss dialects.
after a updating some old projet I notice this depreacation.
Personaly I use it a lot and I don't beleve it is hard to learn.
I found that #ff0000 + #abcabc not so hard to read.
I'm sad to see them leave.
If vote are not close I will vote for remove this deprecation.
Sass's support for mathematical operations on RGB colors is misleading and not very useful.
Is it? I always found it very obvious what adding two colours together would do. So far I'm 15 minutes in to trying to find out what the current Sass API is for the alternative. It hasn't been explained well anywhere on any of the links I've followed yet, and the code I've tried to copy and paste isn't working.
We can't assume that people who are having to deal with deprecations like these are familiar with the current API, or (in my case) have even written a line of Sass in the last 5 years.
Please please please stop churn that you don't have to make (this is really a plea to the entire open source web community). The global cost is in lost productivity doesn't bear thinking about. Yes, I realise maintenance needs to be done, and we can't drag old APIs around forever, but we shouldn't deprecate things unless the maintenance cost is very significant to the maintainers.
Once you've released API in a popular project don't you have a responsibility to everyone using it to maintain it? I feel that I do, on my projects.
I've spent most of the day releasing a new version of an open source CMS that broke because Haml has seen some serious breaking changes. Fair enough, that was a big architectural change. But now, the first site I deploy the new version to is spitting out deprecation warnings because I've added two hex values together. Sad 🐼
Once you've released API in a popular project don't you have a responsibility to everyone using it to maintain it? I feel that I do, on my projects.
Right? Browser authors & maintainers literally take statistics on what sites are using certain features they're considering deprecating or making breaking changes to.
Even if something is considered bad semantics, bad implementation, bad practice, a foot gun, violates spec or is the wrong way to do something, if enough sites/large sites are using it a certain way, they will often go out of their way to "not break the web"
Admittedly, sometimes this can be painful as it can slow down updates and implementation of new features.
In this case, I don't see it causing any issues regarding that. People seem to like it / use it; the reactions on the OP show pretty clearly the sentiment.
I have no opinion on the specific issue really; it seems potentially useful though.
But after reading through a few issues I do have concern with how some decisions are being made with SASS arbitrarily without any developer consultation especially when community consensus seems against the decision and maybe even introducing breaking changes against semver norms. This will alienate developers and is one of the main ways projects die. I understand that this is free and opensource software and I'm sure everyone appreciates the work, but the reason software is made free is to benefit the community and is made opensource for the community to contribute, not to just be 'my way or the highway'.
I've used and loved SCSS for years and have never had reason to create an issue or even check them out; I saw the behavioral differences from Ruby SASS or whatever on the NPM page and opened some of them out of curiosity, not that any affect me or my developments and just reading the way the maintainers have responded to peoples input and complaint - regardless of whether or not the maintainers agree or if the issue is wontfix - has shocked me a bit, not anything related to the technical aspects of the decisions/changes, but how some things have been handled has come across like, "We're right, you're wrong and I don't care if it breaks your stuff".
It's your project, do what you will; again I don't have any specific quarrels but I did want to provide some insight into how the attitude appears to someone who is reading these issues for the first time and has loved using SCSS for years without any issue or complaint (and has been writing/using CSS since the first day CSS was available in browsers) - I'd hate to see SASS die because of something like this; just look at the recent backlash against Rust for their proposed changes regarding the use of the name, etc.
I mean no disrespect and this is meant to be just purely constructive criticism.
But after reading through a few issues I do have concern with how some decisions are being made with SASS arbitrarily without any developer consultation
This claim is absolutely unfounded. We have a detailed and painstaking process for changing the language that always involves time for community comment and review. This issue predates that process, but every single change to the language that happens today is done with explicit time carved out for feedback.
It's also worth noting that we almost never get feedback in practice. This issue is a great example: it took two years from the time the issue was filed and a deprecation warning was introduced before someone complained about it here. Even if that comment had made an extremely compelling case for the value of color arithmetic, adding it again would have had substantial additional hurdles given the effort we'd just gone through to remove it.
Ultimately, language design is a matter of making judgment calls on the benefits and drawbacks of every change. It's not that we don't understand that removing this feature will cause pain—we do, and we would like to avoid that where possible. But the existence of this feature also causes pain in a much more subtle way to everyone for whom it's not the right solution. Every feature has a cost: it takes up space in documentation and in users' mental models.
This feature in particular means that if color values sneak into arithmetic expressions unexpectedly the user will just get nonsense CSS instead of a useful error. It also means that users are more likely to write something like $color - 10% believing it will consistently make a color "10% darker" in some meaningful way when in fact it will always produce dramatically worse results than color.scale($color, $lightness: -10%).
Whether these downsides outweigh the downsides of a breaking change is, again, a judgment call we have to make. But when we expect Sass to live for many decades more, we will generally weigh the long-term costs of having footguns in the language quite heavily versus the short-term costs of asking users to migrate.