You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thoughts on adding native support for exponents in Sass expressions? While a simple loop can easily calculate positive integers, other values are more difficult to calculate. It can be done but not efficiently in pure Sass.
What's the use case for non-integer exponents? I'm not sure we want to move towards adding a full complement of mathematical operations in core Sass. That seems like a good thing for extensions to do.
It would be pretty confusing if pow(5px, 2) didn't return a result in square pixels.
@nex3 I want to remove the need for Ruby in the modular scale extension. While CodeKit, Mixture, and other tools do support extensions, the process is far too complex for a significant portion of that audience. Distributing Ruby extensions via Bower is also problematic.
to be clear, pow(5px, 2) = 25px and pow(5px, 2.5) = 55.901699437px. Your example would result in square pixels. I have found half units to be useful when setting type on an exponential(modular) scale and the scale moves too quickly in that area.
@nex3 I want to remove the need for Ruby in the modular scale extension. While CodeKit, Mixture, and other tools do support extensions, the process is far too complex for a significant portion of that audience. Distributing Ruby extensions via Bower is also problematic.
What makes this so difficult? Ruby-based extensions are never going to be completely avoidable for complex operations. I'd like to make them easier to use rather than essentially unusable.
pow(5px, 2) = 25px
Your example would result in square pixels.
These two statements seem contradictory.
I have found half units to be useful when setting type on an exponential(modular) scale and the scale moves too quickly in that area.
What do you mean by "half units" and "the scale moves too quickly"?
Half units == decimal exponents, and "the scale moves to quickly" is behavior specific to the modular scale extension.
I think the main point is right now we can make an exponent function in an extension and distribute it, but it would be more convenient to have a native-to-the-parser syntax. Exponents are one step up from basic math, and a native syntax would encourage authors to use and experiment with them. So the decision is: should exponents be in Sass, or should they be provided by a function in an extension?
We're definitely not adding syntax support for exponents; the functionality isn't broadly applicable enough. We could potentially add a function for it, but there is a line of niche uses past which we won't add math functions. Should we add root functions? Logarithms? Trigonometry?
I'd much rather see a math package that encapsulates all of these and keeps them out of the core set of functions. Then they're available for libraries that need them, but they don't clutter up the default namespace with functions that just aren't useful to most users.
If the syntax doesn't support at least exponentiation - how does complex math get dealt with in libsass? Most of the examples that come to mind could be calculated by hand and assigned to a variable, but isn't that true of most Sass numerical operations?
I recently started to work deeply with color spaces and in order to build the w3c relative luminance function, a decimal power is required. This is non-trivial to calculate by hand and while having a Ruby function would allow this to work, it would do so at the loss of cross-compiler compatibility.
I was just working on the exact same thing @Snugug. At some point an x^2.4 was needed for almost all colors in that calculation. Using the Sass-native pow() function from https://github.com/terkel/mathsass 10 times resulted in a serious slowdown in compile speed. This was the only Sass-implementation I was able to find for decimal exponents.
My purpose with this was automatic color adjustment to ensure AA-compatible color contrasts. The contrast-calculating function was the one doing the ^2.4.
I managed to cook up something a bit faster, but still very slow:
x^2.4 = x^2 * x^0.4
x^0.4 = x^4/10 = x^2/5 = (x^1/5)^2
In other words:
x^2.4 = x^2 * (x^1/5)^2
x^1/5 = the fifth root of x.
I proceded to implement an nth-root-function: (note the hard-coded $guess!)
Integer exponents on a number with units should always compute to (base ^ exponent)(unit^exponent).
Decimal exponents with units are strange to me. Not sure whether it should be an error or include a fractional unit (which is unlikely to cancel, therefore is rarely going to be printable as a CSS unit -- another kind of error that's harder to debug).
If you want the same unit you'll need to do something like: pow($somevalueinpixels / 1px, 3) * 1px
@corysimmons No, 3 years to come up with a good, solid spec and implementation of namespacing and modules, while also handling all the other bugs and improvements that a popular living project like Sass generates.
Being rude can feel a little good in the moment, but it's never polite, and it's a major contributor to project-maintainer burnout. Next time you feel the need to leave a comment while annoyed, please consider waiting a while to cool down, and if you still feel like being a little rude, consider not posting at all.
Reacted by i. welch canavan, Iain Beeston, Scott Kellum, Sam Richard, Pierre Vanduynslager, Kaelig Deloumeau-Prigent, oli, sinisterstumble, Drew Powers, Joe Fusco and 19 more
I'm not part of the Sass project, nor was I replying to you. I was just updating the thread.
You need to seriously reconsider how you interact with project maintainers. Negativity generally has the exact opposite effect of what you want; it certainly doesn't encourage people to work on the thing you're "asking" about.
Reacted by Scott Kellum, Chris Blakley, Jakob Eriksen and Ron Wolf
Activity
robwierzbowski commentedon Mar 18, 2013
I very much like the ruby syntax. If there's an internal conflict that makes that difficult, most people understand the caret syntax too:
Snugug commentedon Mar 18, 2013
Would that be 25px or 25pxpx?
On Mar 18, 2013, at 3:40 PM, Rob Wierzbowski notifications@github.com wrote:
robwierzbowski commentedon Mar 18, 2013
That is how Sass deals with a manual square right now. Obviously the intention would be for it to be 25px.
nex3 commentedon Mar 22, 2013
What's the use case for non-integer exponents? I'm not sure we want to move towards adding a full complement of mathematical operations in core Sass. That seems like a good thing for extensions to do.
It would be pretty confusing if
pow(5px, 2)didn't return a result in square pixels.scottkellum commentedon Mar 22, 2013
@nex3 I want to remove the need for Ruby in the modular scale extension. While CodeKit, Mixture, and other tools do support extensions, the process is far too complex for a significant portion of that audience. Distributing Ruby extensions via Bower is also problematic.
to be clear,
pow(5px, 2) = 25pxandpow(5px, 2.5) = 55.901699437px. Your example would result in square pixels. I have found half units to be useful when setting type on an exponential(modular) scale and the scale moves too quickly in that area.nex3 commentedon Mar 22, 2013
What makes this so difficult? Ruby-based extensions are never going to be completely avoidable for complex operations. I'd like to make them easier to use rather than essentially unusable.
These two statements seem contradictory.
What do you mean by "half units" and "the scale moves too quickly"?
robwierzbowski commentedon Mar 22, 2013
Half units == decimal exponents, and "the scale moves to quickly" is behavior specific to the modular scale extension.
I think the main point is right now we can make an exponent function in an extension and distribute it, but it would be more convenient to have a native-to-the-parser syntax. Exponents are one step up from basic math, and a native syntax would encourage authors to use and experiment with them. So the decision is: should exponents be in Sass, or should they be provided by a function in an extension?
nex3 commentedon Mar 22, 2013
We're definitely not adding syntax support for exponents; the functionality isn't broadly applicable enough. We could potentially add a function for it, but there is a line of niche uses past which we won't add math functions. Should we add root functions? Logarithms? Trigonometry?
I'd much rather see a math package that encapsulates all of these and keeps them out of the core set of functions. Then they're available for libraries that need them, but they don't clutter up the default namespace with functions that just aren't useful to most users.
robwierzbowski commentedon Mar 22, 2013
That's reasonable. @scottkellum, want to collab on a Sassy Math package?
Snugug commentedon Mar 22, 2013
@robwierzbowski Kinda like https://github.com/scottkellum/sassy-math 👅
If we're missing something, happy to add more.
robwierzbowski commentedon Mar 22, 2013
Ha, well look at that. Consider it ⭐'d
nyarly commentedon Aug 22, 2014
If the syntax doesn't support at least exponentiation - how does complex math get dealt with in libsass? Most of the examples that come to mind could be calculated by hand and assigned to a variable, but isn't that true of most Sass numerical operations?
Snugug commentedon Sep 23, 2014
I recently started to work deeply with color spaces and in order to build the w3c relative luminance function, a decimal power is required. This is non-trivial to calculate by hand and while having a Ruby function would allow this to work, it would do so at the loss of cross-compiler compatibility.
torkiljohnsen commentedon Dec 1, 2014
I was just working on the exact same thing @Snugug. At some point an x^2.4 was needed for almost all colors in that calculation. Using the Sass-native
pow()function from https://github.com/terkel/mathsass 10 times resulted in a serious slowdown in compile speed. This was the only Sass-implementation I was able to find for decimal exponents.My purpose with this was automatic color adjustment to ensure AA-compatible color contrasts. The contrast-calculating function was the one doing the ^2.4.
I managed to cook up something a bit faster, but still very slow:
x^1/5 = the fifth root of x.
I proceded to implement an nth-root-function: (note the hard-coded $guess!)
torkiljohnsen commentedon Dec 1, 2014
This is the first time I have come to the sad conclusion that I should have been using less :(
32 remaining items
chriseppstein commentedon Sep 28, 2015
Integer exponents on a number with units should always compute to (base ^ exponent)(unit^exponent).
Decimal exponents with units are strange to me. Not sure whether it should be an error or include a fractional unit (which is unlikely to cancel, therefore is rarely going to be printable as a CSS unit -- another kind of error that's harder to debug).
If you want the same unit you'll need to do something like:
pow($somevalueinpixels / 1px, 3) * 1pxcorysimmons commentedon Mar 15, 2016
This has been open a few years. Have you had time to consider it and make a decision? 🍕
corysimmons commentedon Mar 15, 2016
3 years to come up with a namespace?👏 💨Actually, nevermind. I'll write lib in something else. Have nice day.
tabatkins commentedon Mar 16, 2016
@corysimmons No, 3 years to come up with a good, solid spec and implementation of namespacing and modules, while also handling all the other bugs and improvements that a popular living project like Sass generates.
Being rude can feel a little good in the moment, but it's never polite, and it's a major contributor to project-maintainer burnout. Next time you feel the need to leave a comment while annoyed, please consider waiting a while to cool down, and if you still feel like being a little rude, consider not posting at all.
chris13524 commentedon Aug 27, 2017
So nothing on this yet? I just had a use for it.
bichotll commentedon Sep 20, 2017
Just wanted to say I was looking for it too 👍 I can wait.
...and seeing the comment on top, just wanted to thank the sass team! The world d not be the same without you! hah
robclancy commentedon Aug 6, 2019
tabatkins commentedon Aug 8, 2019
CSS has at this point approved and specced a pow() function (along with some trig and other exponential functions).
Note that CSS does not allow pow() (or sqrt()) to take a value-with-unit, only plain numbers. There's an explanation in the draft for that.
robclancy commentedon Aug 8, 2019
tabatkins commentedon Aug 8, 2019
I'm not part of the Sass project, nor was I replying to you. I was just updating the thread.
You need to seriously reconsider how you interact with project maintainers. Negativity generally has the exact opposite effect of what you want; it certainly doesn't encourage people to work on the thing you're "asking" about.
robclancy commentedon Aug 8, 2019
nex3 commentedon Aug 8, 2019
@robclancy This is your one and only warning. Keep this up and you'll be blocked from this org.
stof commentedon Mar 15, 2022
@nex3 this issue should be closed, as
math.powhas already been implementednex3 commentedon Apr 11, 2023
Closing this out as @stof suggested