-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Feature Proposal: if()
function
#3019
Comments
For an implementer / pull request: I took some time to look at current parsing (which would need to be updated). Even though Tests will need to be added for:
To look at the evaluation of conditionals, you would look at the mixin definition node type in the lib/less/tree folder. |
@matthew-dean That way you could store the boolean result for later use in a mixin guard condition. This has some added value for writing cleaner, less repetitive code in cases where you cannot logic mixins together under one shared guard. E.g. when you are using one mixin to unlock a different set of other mixins, where you use a kind of partial application by taking parameters from the top mixin and using them to set guard conditions on the unlocked child mixins. |
That way it's probably better to be a separate wrapper named |
@rjgotten Yeah, I thought of something like that for repeated conditions on mixins, buuuut I kinda leaned where @seven-phases-max went, which is to just not over-complicate things. An |
I actually like that a lot better as well. ^_^ |
Closing as implemented in #3079 (further improvements -> new ticket). |
In the course of discussing changes to the
contrast()
function (which was changed and reverted, but will be changed again for 3.0 - see: #2754 (comment)), it came up that the legacy contrast function was really something of an if/then/else function, with the actual test condition simply one step removed from visibility.That is, given:
contrast(a, b, c, d)
this is the test:Therefore, with contrast changing, the proposal on the table is to add, in the future, a generic
if()
function, with this signature:if(condition, thenResult, elseResult)
condition
has the same signature / format as awhen
condition in Less, with the exception that it cannot contain a comma as a logicalOR
, as that would denote an argument separator. However, Less now supports theor
keyword and it is now the preferred format for a logicalOR
.The above statement could then be replaced with something like the usage below:
@seven-phases-max noted that implementation is non-trivial (which I agree), but could be a very valuable addition to Less functions, since you could use it for other purposes besides only testing for a
luma()
value.The text was updated successfully, but these errors were encountered: