Less 4.0 Planned Changes (WIP)

[matthew-dean]

I'm currently prepping a 4.0 release that will include more incremental changes from what was planned.

1. As planned, the --math=parens-division option is now on by default. (Division is required to be in parens in order for math to be performed.) This aligns with both Sass and Stylus.

Example:

// input
prop1: 6 / 2;
prop2: (6 / 2);

//output
prop1: 6 / 2;
prop2: 3;

2. To be consistent with function calls and detached ruleset calls, mixins now require parens () after a call.

Example:

.mixin;    // error
.mixin();  // pass

3. ~Function calls now log an evaluation warning instead of an error, and will pass through the function call in your CSS output. This alleviates conflict between Less function names and functions added to CSS.~

EDIT: I think there's a better way for this, so instead, I'm just passing-through the function call for min / max the way that we do for rgba / hsla.

.foo {
  max: max(3em, 1em, 2em, 5em);
  max-native: max(10vw, 100px); // would throw an error in 1.x-3.x
}

// will log `Could not evaluate function 'max'. Will output as-is.`
.foo {
  max: 5em;
  max-native: max(10vw, 100px);
}

In the future, function conflicts will be alleviated through some kind of namespacing / aliasing.

[nfq]

1. Great, I think this is a smart move.
2. For consistencies sake (I always do it anyway), I think using () after a call a good idea.
3. I'm on the fence about this. But thinking about it, for consistencies sake, I think it makes sense as well... Actually, I'm in favour, after thinking it through.

[matthew-dean]

Thanks for your feedback!

I'm on the fence about this. But thinking about it, for consistencies sake, I think it makes sense as well... Actually, I'm in favour, after thinking it through.

Yeah, I wouldn't say it's the most ideal situation, but it's a short-term way to alleviate conflict in function names. I wonder if there's maybe a better way though....

[matthew-dean]

I think there's a better way to do this, so to be on the safe side, I'm going to just white-list min / max the way that rgba and hsla return the function call if there's an error evaluating.

[nfq]

Thanks for your feedback!

I'm on the fence about this. But thinking about it, for consistencies sake, I think it makes sense as well... Actually, I'm in favour, after thinking it through.

Yeah, I wouldn't say it's the most ideal situation, but it's a short-term way to alleviate conflict in function names. I wonder if there's maybe a better way though....

Are you wondering more syntactically?

[matthew-dean]

@nfq Yes, I have what I think is a good syntactic solution in mind.

Namely:

// Makes it explicitly clear we want to import Less's max function
@import { max } from 'less/functions';

.foo {
  // will always try to evaluate, because max is in scope
  value: max(3em, 1em, 2em, 5em);
}

But there's no way to make that happen for this proposed release, so a try/catch works for max/min in the short term (like we have for rgba/hsla).

[nfq]

It makes sense. Except, when I see value: max(3em, 1em, 2em, 5em); I think mixin. I know it's know not. But it feels like it is. I wondering if it will create confusion in the short term? Maybe it's a worthwhile tradeoff.