2.0.0 - Changes in default options

[lukeapage]

strict math - turn on by default?
no javascript - turn on by default ?

As @matthew-dean suggested, I agree we should either make this change for 2.0 or wait till 3 or never make the change.

I'm pretty agnostic about both of @matthew-dean suggestions above, this is just a dedicated issue for it.

[Soviut]

I think that 2.0 (or major version) is the right time to implement these sorts of "breaking" changes. After all, these aren't even deprecations, they're just changing defaults. Either way, having a nice round number people can easily remember will make it easier for people to pick the right version or check the site to see the change log and refactor accordingly.

[matthew-dean]

My feeling is that 2.0 is "okay" for strictMath, but if we do so, we really, really need to update the docs immediately to show the preferred math method.

On no JavaScript, my feeling is not yet. It would cause some headaches if done now. Not everyone is using a Less compiling tool that has these switches available (I would consider it "advanced" usage of Less to mess with switches), and refactoring of mixin libraries that rely on JS would not necessarily be as easy. We certainly don't have to wait as long between 2.0 and 3.0 as we did from 1.0 to 2.0. I think the safest point to migrate from JS inline is when we have our plugin system, environment adapters, and API finished, so that we can point to some clearer migration path possibilities.

[seven-phases-max]

I have switched to --strict-math:on at the very beginning of my Less experience, and the more Less code I write the more I start to think of switching back to --strict-math:off. The problem is that the conflicting CSS statements (calc(...), whatever: 1px/4px etc.) do not appear in my code that often while arithmetic stuff happens a lot meaning literally hundreds of redundant parens everywhere. So I actually suspect that many users will still prefer to occasionally put a few ~"" here and there rather than bloat all the code with (quite annoying to be honest) parens. It heavily depends of course on how much math you have in your code but it feels like current strict-math solution to the problem is not as neat as it was thought to be when invented...

(The other day I had a though that some kind of less strict math option would possibly be more handy, e.g. require parens only for division or a sort of).

[jonschlinkert]

more Less code I write the more I'm starting to think of switching back to --strict-math:off.

Completely agree with this. IMHO it's just un-intuitive to users, so no matter how much we update the docs they will still come here first to report it as an issue, rather than assume that they are doing something wrong. This was evidenced by the number of issues we received during the brief time that on was the default.

suspect that many users will still prefer to occasionally put a few ~"" here and there rather than bloat all the code with (quite annoying to be honest) parens

Indeed.

I'm also not a fan of removing support for javascript. This has always offered a way of hacking around features that we don't support. I can see how someone who only uses less.js in the browser would want a flag to turn it off though. But in node.js, server-side, why turn it off?

[jonschlinkert]

it's also worth mentioning that if we get some kind of support for runtime config files, like .lessrc, or however we decide to implement it, these kinds of defaults can more easily controlled by users. thus, there would likely be less controversy as well

[matthew-dean]

I'm also not a fan of removing support for javascript. This has always offered a way of hacking around features that we don't support. I can see how someone who only uses less.js in the browser would want a flag to turn it off though. But in node.js, server-side, why turn it off?

First, because not all JavaScript environments can eval imported JavaScript (as it's unsecure), but also, why would you want a hacked language? How is it okay that the supported method for an issue that Less doesn't solve is injecting an unrelated scripting language into your CSS-like syntax? Doesn't that defeat the purpose of a CSS-like language? Wouldn't that be less desirable than just making a more scripting-like adaptation like SASS? Wouldn't the point be to keep the syntax of LESS and the scripting language that parses it separate?

[matthew-dean]

I have switched to --strict-math:on from the very beginning of my Less experience, and the more Less code I write the more I start to think of switching back to --strict-math:off. The problem is that the conflicting CSS statements (calc(...), whatever: 1px/4px etc.) do not appear in my code that often while arithmetic stuff happens a lot literally meaning hundreds of parens everywhere.

I've often wondered about this myself, if the few use cases where there's conflict leaves more syntax where it's not needed. I feel like it's philosophically problematic to choose math operations and syntax that directly conflict with and are ambiguous with CSS statements. We probably could have avoided it if / had not been chosen as a division operator. So I get why people would prefer to not put parentheses around things, since it seems like extra work for some potential conflicts. Maybe there's a cleverer solution?

[Soviut]

One solution is to make special cases for bracketed functions like calc.

On Saturday, February 15, 2014, Matthew Dean notifications@github.com
wrote:

I have switched to --strict-math:on from the very beginning of my Less
experience, and the more Less code I write the more I start to think of
switching back to --strict-math:off. The problem is that the conflicting
CSS statements (calc(...), whatever: 1px/4px etc.) do not appear in my code
that often while arithmetic stuff happens a lot literally meaning hundreds
of parens everywhere.

I've often wondered about this myself, if the few use cases where there's
conflict leaves more syntax where it's not needed. I feel like it's
philosophically problematic to choose math operations and syntax that
directly conflict with and are ambiguous with CSS statements. We probably
could have avoided it if / had not been chosen as a division operator. So
I get why people would prefer to not put parentheses around things, since
it seems like extra work for some potential conflicts. Maybe there's a
cleverer solution?

Reply to this email directly or view it on GitHubhttps://github.com//issues/1872#issuecomment-35147897
.

[matthew-dean]

What about font and background shorthand?

I wonder why we never thought of bringing in \ as the division operator, and having a switch to force a backslash for division. I think division has always been the only conflict (plus calc).

[matthew-dean]

But getting back to the question of this issue: should we turn these options on by default. Some of us were on the fence about math, and some of the team are "no"s, so I think we can safely say no for 2.0. I think we should revisit later after we've done API / plugin work and have a roadmap for 3.0. Agreed?

[lukeapage]

Maybe its the right solution but we shouldn't use strict.. e.g. at the moment inside certain constructs we "turn on" strict math - so that you can still do math inside media query statements for instance and font statements but you need the brackets. If we just extend that to calc (the only missing one I believe) then people do not need strict maths - but we can still keep the option around in case people prefer to be explicit.

Anyway, closing this as we will not change any default options for 2.0.0

[zamtools]

Perhaps we should warn the user if there are any / detected in the source file? That might be a better solution than changing defaults.

[seven-phases-max]

font statements but you need the brackets. If we just extend that to calc (the only missing one I believe) then people do not need strict maths

The way it works for font has its issues (#1627). And I guess same would apply to the calc (and similar CSS functions) if we try to hardcode it... and I'm not sure this can be easily fixed some way (though before today I thought that simple hardcoding can be a solution for the calc at least). Probably we need to open another thread to discuss possible --strict-math alternatives since this goes beyond this ticket scope?

[SomMeri]

I would find it reasonable to require strict math only in fonts, calc and media ratio. I'm usually for consistency, but there is no need to annoy users with additional () when they are needed only on same relatively rare places.

The problem with \ everywhere is that \ as division is non-standard. My guess is that most people are used to / as division and are going to make mistake often and be annoyed.

[lukeapage]

yes If I see \ then I see escape and although escape is only valid in URLs in css (at the moment, afaik), its still part of CSS that I think would be more confusing.

[Soviut]

I'm with @SomMeri on this one. The special cases are few enough to warrant their own rule for requiring strictMath while the rest should be non-strict.

[seven-phases-max]

Actually \ is the CSS escape character and it's even supported by Less :)
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... That's why I suggested another thread :)

[seven-phases-max]

Also, the "special cases" (e.g. properties where x/y can appear as shorthand) a not so rare (starting at padding/margin and ending at 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 (at least when we have some strict-math as default)).

[lukeapage]

see #1880

[matthew-dean]

Like @seven-phases-max said, CSS will probably keep adding "/" for things. Special-casing properties doesn't seem ideal either. While parentheses is annoying to some, at least the behavior is completely predictable. The goal should not be to write a different type of math syntax based on which property you happened to write.