How to handle Maths

[lukeapage]

1. We decided on strict maths going forward but there is general unease about forcing () around every calculation
2. I don't think we want to change things massively or go back to the drawing board

See #1872

Possibility to add another case for calc which like font, with strict mode off, essentially turns strict mode on for a rule ? Too many exceptions in the future?

@seven-phases-max :
Well, there're a lot of other possibilities, e.g. ./ or require parens for division (e.g. 1/2->1/2 but (1/2)->0.5) etc...
Also, the "special cases" (e.g. properties where x/y can appear as shorthand) are not so rare (starting at padding/margin and ending with background/border-radius and eventually there can be more) so we just can't hardcode them all like it's done for font (and because of that I think that the current font "workaround" is just a temporary and quite dirty kludge that ideally should be removed too).

[seven-phases-max]

I don't think we want to change things massively or go back to the drawing board

Yes, I suggested to start this only because if we want some "default" strict math in 3.0 we'll have to invent something less heavy than the current one (and a possibility of fixing all the problems without introducing any new --alt-strict-math option seems to be quite unreal because of hidden issues behind the font-like hardcoding solution...).

[lukeapage]

I hadn't realised that its growing

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

:(

I think at the moment I am in favour of initially expanding strictMaths to be

• Off
• Division
• On

and then for 2.0.0 setting the default to be Division

So..

Media Queries - if off, switch to division for sub nodes
Font - if off, switch to division for sub node
calc( - if off or division, switch to on for sub nodes

[seven-phases-max]

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

Yep, I think they are towards to allowing "shorthand values" (i.e. x/y) in any "shorhand property"...

[lukeapage]

related: #1480

[lukeapage]

Another option.. process calc calls but only where the units make it possible e.g
calc( 1% + 2%) => 3%
calc(100% - 10 px) => unchanged

[seven-phases-max]

This will fix calc but won't fix #1627 and related stuff.
I mean yes, calc(100% - 10 px) => unchanged could be a solution for the calc but this does not cancel the need for a less-heavy-than-parens-everywhere solution.

[calvinjuarez]

If strict maths is being revisited, I'd like to suggest that Less functions like percentage() not require extra parentheses inside them. With strict maths on, you have to double-wrap the argument. This would greatly reduce the possibility of confusion and tough-to-find bugs, since both percentage(16 / 17) and percentage((16 / 17)) would be valid.

[seven-phases-max]

@calvinjuarez V2 provides a plugin subsystem where a plugin can add an arbitrary number of functions to the environment and in this sense the core won't be able to decide if such built-in function expects a single value or an expression, i.e. it is allowed to accept 16/17, and then evaluating 16/17 before it is passed to a function would be incorrect (well, roughly speaking - it's a bit more complicated than that internally).

In that context ./ change seems to be my favourite though I understand it would be very dramatic change (if compared to (/), not counting it is also requires a whitespace before ., e.g. 16 ./17 and not 16./17, hmm).

[ponychicken]

Another thing where less currently breaks valid css is background shorthand:

background: url(image.png) 50%/300px no-repeat;

[matthew-dean]

I think at the moment I am in favour of initially expanding strictMaths to be

Off
Division
On
and then for 2.0.0 setting the default to be Division

Sorry I didn't respond to this before 2.0 was released. I think that's a good instinct. Naked division operators simply conflict with too much of CSS, and will conflict more and more as people use more CSS3 features. And I understand people's pushback to not require parens for all math, since it's not needed in many cases.

@seven-phases-max

it is allowed to accept 16/17, and then evaluating 16/17 before it is passed to a function would be incorrect

Strictly speaking, yes that's absolutely correct. This should not be evaluated BEFORE it reaches the function, especially for a custom one. However, I think it would be smart to allow functions to opt to process arguments like this, if it makes sense. So, percentage would receive 16/17 as a text argument, and then the percentage function could make a call to some helper function to see if the text is math. In the case of percentage, the argument is not ambiguous. A CSS3 declaration is not valid here. So, other user-defined functions could operate the same way: opt to evaluate arguments for valid math equations. Therefore, it's not necessarily true that strict math "forces" a double parentheses in this case. I think to suggest that causes some pushback on the idea of strict math, that it must, as a necessity, be verbose in all cases.

[matthew-dean]

Our --math options could be more like:

• Always
• Division (default)
• Strict

So, we could deprecate --strict-math=true and make it an alias for --math=strict