math will be ignored

[formspiel]

I use opacity: @opacity / 100; in my mixins and compile with CodeKit (and 1.4.0-b2). But -khtml-opacity:70 / 100; appears in the CSS.

It would be nice to have an error output for calculation without parenthesis.

regards Andreas

[lukeapage]

less.js would have to know the context of what is valid css and not valid css. At the moment it doesn't and thats why we made it consistent by requiring brackets.

Maybe we could warn but will be some work

[maranomynet]

I sort of like the way Stylus does this. There parenthesis around maths is optional - except when doing divisions.

It seems that in LESS doing maths is default - and the syntax should optimize for that - providing an escape mechanism for literal uses of math symbols (like "/" in the font: shorthand). Like so:

font: 16/12em \/ 1.5em;

[maranomynet]

Just in terms of pure ergonomics, requiring brackets around all maths adds four redundant keystrokes - Shift+(+Shift+) - every time we cant to calculate something.

[lukeapage]

4 extra keystrokes, but is the resultant less more obvious as to what is a calculation and what is css?

[maranomynet]

Been leading a team using LESS for over a year, and we've never had trouble spotting calculations. We often wrap things in parenthesis where math operations are mixed with other values (or other calculations) - where we feel it helps, but most of the time things look neater without them. i.e.

font-size: 18/14em;
padding:  10px  @gutter/2  (2*@bottomPad - 5px)  @gutter;

I've been diligently wrapping everything in parenthesis ever since 1.4 beta came out, and it just feels unnecessary and way too verbose most of the time.

(Also, I dread the prospect of having to go through tons of working LESS code and wrap everything in parenthesis to be able to upgrade and take advantage of the new features.)

[lukeapage]

yes it is a pain to upgrade - I did it for bootstrap.. only took me an hour though.

The thing is, we need parenthesis around slash.. and less is meant to be a superset of css, yet at the moment the calc function can't be used without having an ugly looking calc(~"12% - 1px").. so we thought that given that css might introduce more calculations that it was better to be consistent with parenthesis than require it for divides but not everything else.

There is a strictMaths option you can turn off and it will run with the old behaviour, however at the moment the plan is that this will be removed.

I want to release 1.4.0 proper very soon, so this is a last chance saloon. I think I'm still comfortable and don't have 2nd thoughts. Any doubts @jonschlinkert or @Synchro or @MatthewDL

[matthew-dean]

Forcing the parenthetical change is one of those things that I feel uncomfortable about, but am not sure how to make a graceful solution. The problem is that there's things in CSS that look like math that aren't. Specifically around the slash character. I have wondered if division is the only case that would be required to have parentheses, but, of course, that wouldn't really solve the original problem of this issue. Or, we come up with a smarter algorithm that we haven't thought of. But, as it stands, CSS has perfectly valid values that look like "11px / 14px" that are not meant to be divided.

Escaping characters also doesn't really work, because in general, CSS should be valid LESS by default.

The trouble is that these ambiguous values probably mean that making a designation of calculation should have been present to begin with, but wasn't, and 2 characters to designate a calculation is not massive. However, I think it's a reasonable argument that it IS a large task with an existing LESS library, and it seems reasonable to make that transition as graceful as possible.

I propose that we include the @options directive for 1.4.0, starting with just the compiler options we have now. (Issue #1134) It would be trivial to include background-compatibility if someone just needed to add this to their old library:

@options {
  strictMaths: false;
}

[jonschlinkert]

Rather than focus on the reasons why this these features are important for technical reasons, I'd rather focus on the impact to our users. I can definitely see @lukeapage's point about being consistent, and I agree with the need to have the options for all the reasons stated - I'm very conservative as a principle, so I like features like this generally.

However, I think strictMaths and strictUnits should be there for people who want to use them with the option to set them to "true", because in IMHO we're going to have a lot of frustrated users when 1.4.0 is officially released and the non-early-adopters (the other 99% of users) have their styles break. @lukeapage, consider that most people don't know Less.js nearly as well as you do, so it would take longer for the avg. person. Also consider that you could refactor Bootstrap to SASS in an hour, so this is one of those things that makes the switching cost much lower. No one wants to be forced to refactor their code to fix a problem the haven't experienced - legitimate or not.

The bigger problem we'll have though, is that many people who use Less for a living don't work on just "one project" that uses Less. I personally have at least 30 projects that use Bootstrap alone, and dozens more that use Less. I think that unless you are introducing a new feature that leverages (requires) strictMaths and strictUnits, then they should default to "false" indefinitely. Barring that, I think to users this will feel like a solution looking for a problem to solve, and it could be a very big turnoff to the community.

Just my 2c.

[jonschlinkert]

Again, I want to stress that I see (and agree with) the advantages of these features. But I think the carrying cost is too high to force them on the average user...

Oh, and to @MatthewDL's point about the options, I think that's a good idea if it's doable. After thinking about it a while, I also would be cool with JSHint style config options in code comments:

/* less strictMaths: false, strictUnits: false */

or something similar...

[lukeapage]

yeh I think keeping the default to be on and making it even easier to turn off is the thing to do.

I can implement options over the next 2 days, that's not a problem, its the specification of whether options appear in comments or not and whether they are the style above or the less style is the big problem.

btw. not sure if you saw but I have reverted strictUnits to be false by default.

I like the simplicity of @jonschlinkert approach

/* less strictMaths: false, strictUnits: false */

would that apply to a) the current file only b) the current file and all imports

option a allows you to upgrade bootstrap to 3, which may be coded for strictMaths but keep your files not using strict maths.

On the other hand b means more consistency and bootstrap 3 is compatible with strictMaths on or off.

[maranomynet]

Making it easier to turn strictMaths off seems pointless if the feature is going to be removed down the line anyway.

I agree with @jonschlinkert that usability matters (a lot!) and that strictMaths will make LESS seem less appealing to casual users.

Also, the value of 100.00% painless CSS imports diminishes as more and more projects start out in LESS and most legacy projects have already been converted already. Meanwhile, painless conversion from SASS/Stylus to LESS will be a growing concern.

It seems like it would be simpler to just write a minimal CSS importer to escape the odd slash character in the CSS - than to impose more verbose syntax on every single LESS calculation.

BTW, requiring parenthesis inside calc() functions makes perfect sense.

[lukeapage]

If the community want to keep the option I think we would be hard pushed to remove it. Maybe the next step could be to turn off strict maths on division everywhere and inside the calc function... and of course if other cases start occuring then requiring parenthesis other places.

The nice thing is that it is backwards compatible.. so we could say

1. strictMaths: false as in less 1.3.3
2. strictMaths: true (default) - require parenthesis around division and inside calc(). recommend parenthesis around all maths, but not require it (for now)

and then see what the community reaction is.. it is certainly a less harsh progression.

[matthew-dean]

It seems painful to backpedal, but I also want to listen to users. But, also want to be pragmatic that SOMETHING needs to change. CSS's syntax is in direct conflict with LESS's math syntax. When that happens, the prevailing wisdom is that CSS should be preserved.

Here's the questions to ask, IMO:

• Is division the only case of conflict? For instance, the + character is valid, but for selectors. Can it end up in a value? Are * and - ever valid in CSS?
• Does requiring parens for division only make sense? Is that less confusing for new LESS devs? We have them to consider also, not just existing LESS devs.
• Is there any other way to resolve the CSS / LESS conflict, algorithmically?

Also, as an aside, I'm not sure why the calc() function is an issue. No math should ever be performed in it, by definition, unless you explicitly forced (a second set of) parentheses, as stated.

[SomMeri]

Just a quick idea, since it is easy to turn required parentheses on and off, would it be too difficult to create migration tool?

It would compile less 1.3.3 into less 1.4.0 e.g., automatically wrap all assumed expressions into parentheses. The community reaction could be more friendly if they could just run less -migrate something.less and have it done.

Related idea: less.js 1.4.0 could show (optional) warnings wherever old and new style expressions end up with different results e.g. for 1cm-1mm and for expressions in/out of parentheses. This could be easier to create then the migration tool.

I think I could turn less4j into something like that within reasonable time, but it is in java and all those JavaScript/css developers may prefer js compiler.

[lukeapage]

We don't keep whitespace so transforming less would also prettify..

Warning is ok, but we don't have an established warning system.

I'm more interested in what we do very short term to stop 1.4.0 being
delayed another month or more.

Reading Matthews questions I still think moving to requiring brackets is
the nicest option, but Yeh how we roll out, whether its default, how we can
help is negotiable.

[SomMeri]

I wrote blog post about less expressions and their upcoming changes. I finished writing it before I read this discussion, so it describes less-1.4.0-beta-3.js as is.

If you decide not to require parentheses, I will update the post. For now, I just putted there warning. I will update or rewrite it again after feature set of less-1.4.0.js is known and final .

[jonschlinkert]

Reading Matthews questions I still think moving to requiring brackets is the nicest option

That is disappointing @lukeapage. I think the post you made directly prior to @MatthewDL's comment was great. It should never be painful to backpedal a bad decision. On the contrary it shows that you're taking user feedback into consideration.

[matthew-dean]

Actually, based on @SomMeri's blog post, I'm more swayed in line with parentheses on all math, because I had forgotten about the ambiguity of negative values. So now we have 50% of math operations outside of parentheses potentially conflicting with everyday CSS syntax.

If it's a bad decision, @jonschlinkert, we'd need a viable alternative, but I don't see one. The bad decision was probably to co-opt CSS syntax for math operations. Or, you could argue the problem is the syntax chosen by W3C for CSS. But it's where we are now.

That said, I still agree that it should not be painful for existing users. I think we have to resolve the conflict, and I think we should gracefully handle backward compatibility.

When Microsoft went through this after IE6, and needed to change syntax to line up with the W3C, they implemented doctype switching. Which was probably also dumb, but allowed them to solve the same problem: resolve conflicts, and preserve past behavior. Eventually, this backwards compatibility was phased out.

So, hearing @jonschlinkert's and other's feedback, and putting on my diplomatic pragmatist hat, we COULD follow the same path:

1. We leave strictMaths off by default in 1.4.0, BUT...
2. We easily allow enabling them using the @options block. It's our doctype switch. So, we allow people to eliminate ambiguities without command-line directives, which they may not have access to (depending on how their LESS compiler is wrapped). I want to stress that if we don't do Support require('less').render(str, options) #2, I am NOT AT ALL in favor of Remove Array.prototype.find #1. We need a way for people to stop generating errors for themselves for valid CSS without command-line switching.
3. We make sure all examples continue to demonstrate math in parentheses, and we make it clear that by version 2.0, strictMaths will be on by default. I think a larger lead-up and allowing a longer phase-out of older libs is reasonable. But, as Luke says, on a long enough timeline, at SOME point, required parens should be the standard to maintain CSS compatibility. So we may just be kicking the problem down the road.

Thoughts?

[jonschlinkert]

I'm in a agreement with leaving strictMaths off by default in general. And I also agree that we should use strict maths in demonstrations. I don't think we're kicking the problem down the road, I think we're offering a responsible transition plan for users who are going to be blindsided otherwise. The only thing I disagree with is the requirement to have the options block for leaving strictMaths off by default. I agree that the options block would make it more convenient to switch strictMaths back on, but the absence of the options block doesn't make strictMaths: true a good decision for this release.

[matthew-dean]

The only thing is, if we don't allow inline declarations of command-line options, then for some users, as I said, they really don't have that option.

Even if we use strict maths in demonstrations, it does not solve scenarios where CSS syntax is interpreted as math, which should not ever happen. All CSS should be valid LESS.

[zenimpulse]

@MatthewDL is correct, there's no trivial way to discern whether a user meant to use math when inputting something like "margin: 10px -10px" or "font: 12px / 14px". Forcing declarative syntax for math equations is the only easy way to solve this problem.

[amatecha]

Sure - either you use some ultra-complex logic to determine whether to treat something as a mathematical equation, or you add new syntax (like explicit parentheses) to handle that. I feel like programatically determining whether the writer intended that a property's value (or a portion thereof) be treated as an equation without some explicit indication could be pretty much insanely difficult or potentially even impossible.

[jonschlinkert]

I mentioned earlier I that I think I'm missing something, that must be the case (I'm not being flippant, I really think I might be missing something important, and I'm willing to expose my ignorance if it helps clarify this for others as well).

It just seems that unless people are actually having problems with the existing syntax in practice, this is all conjecture. I searched for Issues about this to see if anyone has created an Issue here to describe a problem they're having with the maths, but I didn't find anything related to the points being made here. Is there a feature that won't work without strictMaths? Can someone create a test on less2css.org that demonstrates a non-obvious failure to calculate properly under the old maths? In other words, can you demonstrate a failure to calculate that wouldn't not be obvious and correctable to the user?

Less, as a language, is about simplicity and being approachable to CSS users. To reiterate what I said earlier, I agree that strictMaths and strictUnits are necessary moving forward, but I don't think we should force them on the user without a transitional period unless there is a real, immediate, pressing problem that must be resolved to prevent other bigger problems - so actual issues being logged about it.

So my recommendation is that before we implement strictMaths: true, at minimum there must be sufficient documentation and adoption of strict maths in our own educational materials before we can expect the average user to embrace this chance.

[matthew-dean]

@jonschlinkert There are pepperings of issues over time, although I wouldn't all of them without some searching. People get hit with it, but yes, as you say, there are workarounds, such as escaping strings, or adopting the long form of the font declaration instead of short form.

I misheard you saying that strictMaths are necessary moving forward. I thought this...

in a agreement with leaving strictMaths off by default in general

...meant that you thought they should never be turned on ever in the future.

So, at the moment, I think you and I are in agreement that the transitional period feels too short to force parens for 1.4. On the upside, if we don't turn it on, it also feels better that it's not a 2.0 release (indicating changes such as this).

On, Less2css.org, interestingly, this currently throws a parse error on everything but 1.4 (not sure why...?):

.test {
    font: 12px / 14px;
}

However, this demonstrates the math error:

.test {
    background: url("myimage.png") no-repeat 10px 20px / 200px 70px scroll content-box content-box;
}
//output in 1.3
.test {
  background: url("myimage.png") no-repeat 10px 0.1px 70px scroll content-box content-box;
}
//current output in 1.4 (CORRECT)
.test {
  background: url("myimage.png") no-repeat 10px 20px / 200px 70px scroll content-box content-box;
}

I've run into that last one myself. But, with these situations, you basically resign yourself to the fact that LESS has bugs and you find known workarounds. Like fewer shorthands.

So, agreed, such annoyances are not unresolvable, and can be solved by other declarations or escaped string hacks, whereas an immediate switch to forced parentheses might indeed be more annoying to more people.

[lukeapage]

Tbh I'm in 2 minds I think brackets required is more consistent but more
hassle. I'd like to hear from more than 1 user.

[jonschlinkert]

Yeah, I think we're in agreement, but IMO every version should throw an error with this:

.test {
    font: 12px / 14px;
}

Even to a person (not just the parser) that looks like you're trying to do math. Meaning, I know it's not, but it appears to be human error that you were trying to calculate a font-size, in which case the following would not throw an error (intuitively):

.test {
    font-size: 12px / 14px;
}

This also works just fine - IMO, also intuitively:

.test {
    font: 12px/14px;
}

Because if you are intending to do "font shorthand", and not a calculation, then there shouldn't be a space on either side of the slash. So this works fine as well:

body {
    font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;
}

Add spaces around the slash and it throws an error:

body {
    font: italic small-caps normal 13px / 150% Arial, Helvetica, sans-serif;
}

However, this is always a problem as far as I know:

box {
    border-radius: 50%/50%; // with or without spaces
}

Another example, this works great:

@size: 3px;
.test {
  border-radius: 30px / @size;
}
// yields 10px

And I think it's intuitive to most users that, by default, maths are calculated in a predictable way in that scenario. I also think it's intuitive that if you don't want the slash to cause a calculation then it should be escaped:

@size: 3px;
.test {
  border-radius: 30px ~"/" @size;
}
// yields 30px / 10px

I'm curious why this isn't a good solution. It might feel hacky to some, but I never seen it that way, IMO it's no different than escaping in any other language. If you don't want maths calculated, then escape. Why would we enforce the other way around?

My gut is that when strictMaths are indeed enforced, we'll continue to have the exact same problem you're describing, but in reverse. I personally think it's a better course of action to say: "If you don't want something calculated, escape it". Escaping is part of programming, and I'd much rather be explicit about what I don't want.

In other words, are we using edge cases to explain why strictMaths should be the default? And are we trying to create new rules and new solutions around problems that already have solutions. Do we want to require more effort on the part of the user for "exceptions to the rule"? I want to emphasize again that I completely understand the programmatic aspect of this and why it makes sense to enforce strictMaths. But the spirit of Less is to remain simple to use, and we have to be careful not to become to complicated or we begin diminishing the specific advantage we have over other languages.

[jonschlinkert]

@lukeapage agreed, I think all of us are just trying to advocate for Less users, it would be great to have more opinions from others on this. @lukeapage take my 2c however you want, I'm confident in your decision on this whichever way you decide to go.

[Synchro]

Just to make up the numbers... I'd be happy always having to use parens for math ops. I think it's a lot clearer than using escaping as it doesn't look weird, and it's immune to any changes that CSS is likely to have in store. I'm mainly using less for variations on bootstrap, so I'm not dealing with a huge code base. From Jon's example, I think this:

border-radius: (30px / @size);

is much clearer than:

border-radius: 30px ~"/" @size;

I'm against the idea of making white space significant - this isn't brainf**k!

[Synchro]

I just realised that I got Jon's example backwards and that was intended to show it not performing a calculation. I think that counts as a QED!

[zenimpulse]

CSS is subject to change, and whitespace is a shaky property to follow at the best of times. Even if it were, not every case will allow for those kinds of distinctions. We need to create a solution that will work independently of standard CSS syntax, and right now adding parentheses is the only option available to us.

[jonschlinkert]

I'm against the idea of making white space significant

yeah I agree with that, although whitespace was not even pertinent to the overall point. But even while I was writing the example I was thinking about that. Nonetheless, it has been that way, and outside of technical diatribe it's worked fine in the real world.

@Synchro, "QED", are you saying proof for or against my point? lol.

IMO this is pretty simple. If you're using slashes, you're doing maths. And if you're doing maths, you know that this:

1 + (2 * 3)

is not the same as this:

(1 + 2) * 3

What I think is silly is to require:

(1 + (2 * 3))

Whatever way @lukeapage decides to go, everyone wins. It's not too hard to flip a switch to perform strictMaths, or not. IMO it's great that the feature is being implements, I'm just advocating a much softer landing, and that we not be so heavy-handed in our decisions.

[Synchro]

On 1 May 2013, at 22:30, Jon Schlinkert notifications@github.com wrote:

@Synchro, "QED", are you saying proof for or against my point? lol.

It was just that I managed to use an example that involved me completely misinterpreting your syntax, suggesting that it isn't that obvious!

I don't think extra parens are that big a hardship - it's not exactly unusual, given that we're happy to use things like /* */ to delimit comments, and the reason that it is different to 'normal' maths markup is that there's a syntax clash involved that we need to get out of. In general I'd prefer CSS markup to always win and for anything over and above that, it's less' job to accommodate and disambiguate, not CSS.

[dmcass]

It's been a long time since I've touched on issues here, but I've been quietly watching for a while. Since this whole math thing is something that I started (read: my fault), I wanted to chime in here.

The main reason for this change is defined by the fundamental goal of this project: LESS is meant to be 100% compatible with CSS. This is the only rule that matters. Take a CSS file, change the extension, run lessc, and it works. The argument over what is easy for users doesn't make sense, because you're either making it easy for existing users or making it easy for new users. Neither one is more important than the other, and no solution here is making everything exceptionally easy for both. If you want to prioritize one, fine, but ultimately it makes sense for everyone to switch to using parentheses around math in order to maintain the integrity of the foundation of the project and future compatibility with CSS.

History

The problem with division (and by extension math) originated on 2010-11-18 with #146. That's two and a half years ago. It was further exacerbated by the same problem with the background shorthand for background-size, and ratios in media queries. Not long after, we started causing all kinds of problems with calc().

I proposed a solution 8 months ago which was accepted by cloudhead and the working community at the time. We talked through the points of breaking changes and how they affect the project in #146. There was a decision made that major version changes are acceptable places to make these breaking changes, and agreed on a path forward for this particular change. I created a PR to implement the proposed changes (#915).

The documentation was updated 6 months ago stating that parentheses will be required to do math (less/old-lesscss.org#29). Knowing the history, I'm wondering how long is long enough for people to make adjustments to their code before we implement a breaking change? Six months of notification seems more than ample to me, but perhaps I'm in the minority.

Edit: In case my position isn't obvious enough, I'm of the persuasion that this should move forward with StrictMaths enabled by default in 1.4.0 and if people aren't ready to upgrade, they don't have to.

[jonschlinkert]

The argument over what is easy for users doesn't make sense

Not to put to fine a point on it, but that's why we're all programming and not in customer service. Unfortunately though, it matters a great deal to people who will be stepping up to resolve the issues after the transition.

In any case, are you basically saying, "Since you can't do math in CSS, this: 12px / 14px would never be calculated in CSS? So Less shouldn't calculate it either? If so I agree, and that's why I think this feature is a good decision. However:

I'm of the persuasion that this should move forward with StrictMaths enabled by default in 1.4.0 and if people aren't ready to upgrade, they don't have to.

Fair enough, but that's a heavy handed approach and I don't think you're the avg. Joe. I think 95% of Less users never even visit the GitHub repo, and most of them will upgrade automatically to take advantage of the other awesome features in 1.4.0, like extend, and variables and directives in @import statements, and they will have no idea why their stuff broke.

That's two and a half years ago. It was further exacerbated by the same problem with the background shorthand for background-size, and ratios in media queries. Not long after, we started causing all kinds of problems with calc().

So, just to be clear, you are saying that without strictMaths it is currently impossible to achieve what you want in Less, or just not as convenient? I want to be clear on whether or not we are "robbing Peter to pay Paul", because if there is something that can't be achieved without strictMaths, then I am completely sold and I'm behind implementing it with true as the default. I haven't heard anything yet that tells my why the average Less user will be at a continuing disadvantage due to the lack of strict maths. Anecdotally, I've personally worked on dozens of projects, and probably > 200 Less components, and never had to worry about calc(). I'm not saying it's not common, but I would be surprised if it was. The point is that strictMaths: true is going to be less convenient to every Less user (than the lazy way we've gotten accustomed to). So IMHO if it needs to happen, then it needs to happen, but it's just good to be tactful and considerate in our decisions.

There was a decision made that major version changes are acceptable places to make these breaking changes

Also agreed, which is why I recommended that we do strictMaths: false for the minor bump to 1.4.0. There is no question that strict maths introduces breaking changes, so on that alone (following semver) we can't enforce it until 2.0.0.

[matthew-dean]

Hmm.... the information on lesscss.org has only recently reflected this impending change, and there's been no blog post by any major web magazine about LESS that reflects how this will be in the future. To my knowledge, LESS does not have a blog or Twitter account or Facebook page that people can follow. People do not really follow Github issues, even if they are web developers. And actually, Github issues are kind of hard to follow.

So, I think it's reasonable to assume most LESS devs will not know about this until the math change makes it in, despite how long it's been discussed on Github (or updated on web).

Despite the long timeline you pointed out @dmcass, it feels like the information could still use a bit of a boost, or some more time to propagate, or something more self-explanatory like a 2.0 release.

[matthew-dean]

Oh, and I didn't mention, that as far as reasoning / argument in support of parentheses, I think @dmcass and @Synchro are right on point. CSS is the winner. "CSS is valid LESS." That's what I tell devs, and that's what gets them using it. If you can avoid it at all costs, you don't alter / escape CSS to make valid LESS. LESS is designed to be CSS+, and that's a fundamental design principle. That essentially defines LESS.

On our web page, we say, "As an extension to CSS, LESS is not only backwards compatible with CSS, but the extra features it adds use existing CSS syntax. This makes learning LESS a breeze, and if in doubt, lets you fall back to CSS."

"LESS is an extension" means that you do not alter/escape your CSS in order to make LESS. You change your .css to a .less file and begin adding in those LESS extensions.

But I'm also inclined to, at this point, agree with my honorable colleague @jonschlinkert on timeline. This should be for a later 2.0 release.

[jonschlinkert]

you don't alter / escape CSS to make valid LESS

well said, I like that

[Soviut]

I do agree that if we can semantically determine what operation is happening, it would be best. However, since calc() is going to be a CSS3 function, I don't see requiring brackets around math expressions to be that distant.

Also, -1 for pluralizing the word "math". I get it, it's a short form of "mathematics" but when is the last time you've seen a math library with maths.abs().

[matthew-dean]

Also, -1 for pluralizing the word "math".

Lol, @Soviut I wasn't going to touch that one, though I agree. But, of course, I was raised in America. American English plural form is "math", British English is "maths". The reason most libs use "math", I imagine, is because many modern languages derive from C, and C was developed in the U.S., but I pulled that reason out of my butt. I think it's minor and a separate discussion.

[theMikeD]

Hi all,

I've been using LESS for less than 6 months, but if it counts for anything I prefer the universal "math needs braces" rule over "some math needs braces, but some doesn't" rule.

IOW I'm perfectly fine with, and prefer, this

(1 + (2 * 3))

[Soviut]

@MatthewDL I'm Canadian but I still use American spellings for things when I'm programming as a matter of consistency.

Speaking of consistency, I agree with @theMikeD in that either all math should be wrapped, or none should be. As long as there is a consistent rule or convention that can be quickly explained, I don't really see an issue. It'd be nice to have it work without, but if it's a nightmare to make work and hits a lot of edge cases, I'd be willing to accept wrapping all the time.

[matthew-dean]

@theMikeD Thanks Mike. For using LESS especially! :-)

[lukeapage]

Ok, lets change the default to false and set the default to true in 2.0 (milestone 1.4.1 ?)

As for options, I'm all for it, but it can't even be started till we have a syntax and 1.4.0 has been hanging around in beta for months, I don't really want to add big changes to it.

So, just to be clear, you are saying that without strictMaths it is currently impossible to achieve what you want in Less, or just not as convenient? I want to be clear on whether or not we are "robbing Peter to pay Paul", because if there is something that can't be achieved without strictMaths, then I am completely sold and I'm behind implementing it with true as the default. I haven't heard anything yet that tells my why the average Less user will be at a continuing disadvantage due to the lack of strict maths. Anecdotally, I've personally worked on dozens of projects, and probably > 200 Less components, and never had to worry about calc(). I'm not saying it's not common, but I would be surprised if it was

calc is going to become more common I expect

media queries and font: properties cannot contain calculations in 1.3.3. With strictMaths true, I was able to allow this. There are multiple issues for both of these restrictions.. so yes, strict maths does enable things that are causing inconvenience.

[jonschlinkert]

I'm on board, sounds like a good plan.

[formspiel]

And then there (in Less 2) should be an error output for calculation without parenthesis. It’s a pain to work with bootstrap mixins, preboot or others with the beta.

I know it’s a lot of work, but, hey, you made the rules ;-)

[maranomynet]

It just seems that unless people are actually having problems with the existing syntax in practice, this is all conjecture.

+1

How about committing to continued support (default or not) for naked math in LESS, with these rules in place:

1. inside calc() parentheses are always required
2. 10px / 5px --> 10px / 5px
3. 10px/5px --> 2px
4. 10px -5px --> 10px -5px
5. 10px - 5px --> 5px
6. 10px-5px --> 5px

?

[Soviut]

I like it. Whitespace is important, just like in every other language.

[matthew-dean]

@Soviut @maranomynet The font spec specifically writes the slash in font-size/line-height as 10px/5px. The background syntax writes it with whitespaces. So... sorry, no, it's not that easy.

http://www.w3.org/TR/css3-fonts/#font-prop
http://www.w3.org/TR/css3-background/#the-background

As @dmcass has mentioned, the problem has been gone over for 2 years with a solution that's been on the table for nearly a year. It's good to get people's input about disruption, but algorithmically, I don't believe this to be solvable with whitespaces, and parentheses is still a very simple syntax. There's an adjustment, and I think it's that adjustment that's more the question (how to manage that).

@lukeapage @jonschlinkert +1 to strictMaths false in 1.4 and 2.0 as next milestone.

[dmcass]

Ok, you guys are too logical ;) I can jump on board 👍

[jonschlinkert]

This is good, I'm pretty sure @lukeapage's plan (correct me if I'm wrong, Luke) was to wrap up 1.4.0 and then shortly thereafter release 1.4.1.. then 2.0.0 will introduce breaking changes for math, as well as other breaking changes that were discussed. IMO that makes sense since 1.4.0 is about to be released and 1.4.1 has some awesome features that are not breaking changes and it "wraps up" 1.4.0 nicely. Just making sure expectations are set, Luke was that a fair description of the grace period?

[lukeapage]

Yep, good. Have done the changes to the website and code (while flying ;))
will push and release 1.4.0 tomorrow.

[matthew-dean]

Just for clarity, since the behavior was reverted on 1.4, the next release will be the next beta, correct?

[lukeapage]

Not sure on your meaning?

[matthew-dean]

I just meant that I am assuming (or recommending, if not) that because of the reversion, the next release will be 1.4 beta 4, not final.

[lukeapage]

Okay... And then after x days without issues we promote?

[matthew-dean]

Yeah, that's what I would suggest.