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

CSS3 calc() function doesn't work with LESS #974

Closed
mgol opened this Issue Oct 8, 2012 · 47 comments

Comments

Projects
None yet
@mgol

mgol commented Oct 8, 2012

I know it's been reported already but bugs were closed due to insufficient information.

I have the following CSS code:

#id1 {
    position: fixed;
    left: 0; top: 0;
    width: 130px;
}
#id2 {
    position: fixed;
    right: 0; top: 0;
    width: calc(100% - 130px);
}

I wanted to transform it into LESS using 130px as a parameter but calc gets internpreted by LESS and this:

@id1width: 130px
#id1 {
    position: fixed;
    left: 0; top: 0;
    width: @id1width;
}
#id2 {
    position: fixed;
    right: 0; top: 0;
    width: calc(100% - @id1width);
}

makes the last but one line transformed to width: calc(-30%); which is clearly not what's desired. I tried using width: ~"calc(100% - @id1width)"; but it makes @id1width not interpreted.

I think LESS shouldn't use things reserved by CSS3 for its internal use...

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Oct 8, 2012

Member

they were probably closed as duplicates.. though I can't find one about calc.. see #146 #122 and #915

workaround: width: ~"calc(100% - @{id1width})"; - note curly brackets around variable.

We are moving to a system where only things inside brackets will be evaluated to fix this problem.

Member

lukeapage commented Oct 8, 2012

they were probably closed as duplicates.. though I can't find one about calc.. see #146 #122 and #915

workaround: width: ~"calc(100% - @{id1width})"; - note curly brackets around variable.

We are moving to a system where only things inside brackets will be evaluated to fix this problem.

@shankarcabus

This comment has been minimized.

Show comment
Hide comment
@shankarcabus

shankarcabus commented Dec 17, 2012

👍

@jonjohnjohnson

This comment has been minimized.

Show comment
Hide comment
@jonjohnjohnson

jonjohnjohnson Dec 19, 2012

@rows: 10;

@row1: 1 / @rows * 100%;

.featured1
{
  top: ~'-webkit-calc(@{row1} + 20px)';
  right: 0;
  bottom: @row5;
  left: @col9;
}

This bit of LESS will process out the value of '@row1' to be 10%, which is great. But when it is inside an escaped seciton of LESS and wrapped in curlys to retain the LESS variable it returns '10' without the '%'.

I've found a workaround that hasn't failed me yet. If you place another '%' after the closing curly of the 'row1' variable inside the escaped code it will work correctly...

~'-webkit-calc(@{row1}% + 20px)';

But that seems like quite a hack to add in another unit type that is suppose to already be in the variable.

jonjohnjohnson commented Dec 19, 2012

@rows: 10;

@row1: 1 / @rows * 100%;

.featured1
{
  top: ~'-webkit-calc(@{row1} + 20px)';
  right: 0;
  bottom: @row5;
  left: @col9;
}

This bit of LESS will process out the value of '@row1' to be 10%, which is great. But when it is inside an escaped seciton of LESS and wrapped in curlys to retain the LESS variable it returns '10' without the '%'.

I've found a workaround that hasn't failed me yet. If you place another '%' after the closing curly of the 'row1' variable inside the escaped code it will work correctly...

~'-webkit-calc(@{row1}% + 20px)';

But that seems like quite a hack to add in another unit type that is suppose to already be in the variable.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Dec 19, 2012

Member

@jonjohnjohnson this is fixed in head and will be in 1.3.2

the rest of this bug will be resolved in 1.4.0

Member

lukeapage commented Dec 19, 2012

@jonjohnjohnson this is fixed in head and will be in 1.3.2

the rest of this bug will be resolved in 1.4.0

@faceless2

This comment has been minimized.

Show comment
Hide comment
@faceless2

faceless2 Jan 14, 2013

Not sure if this is the same issue, but I'm having a problem with the following. Note there's no less-specific stuff here, less 1.3.3 is munging otherwise valid CSS.

Here's the CSS

html, body {
    margin:0, padding:0, border:0;
    height: 100%;
}

#content {
    height: -webkit-calc(100% - 40px);
    height: calc(100% - 40px);
    background-color:gray;
}

#footer {
    background-color:black;
}

And here's the HTML to include it

<!doctype html>
<html lang="en">
<head>
<link rel="stylesheet/less" type="text/css" href="test.css" />
<script src="less-1.3.3.min.js"></script>
<body>
<div id="content"></div>
<div id="footer" style="height:40px"></div>
</body>
</html>

"content" is being set to a height of 60%, so less is parsing & incorrectly resolving the calc expression rather than passing it unchanged through to the browser. Tested in Safari 6.0.2 and Firefox.

faceless2 commented Jan 14, 2013

Not sure if this is the same issue, but I'm having a problem with the following. Note there's no less-specific stuff here, less 1.3.3 is munging otherwise valid CSS.

Here's the CSS

html, body {
    margin:0, padding:0, border:0;
    height: 100%;
}

#content {
    height: -webkit-calc(100% - 40px);
    height: calc(100% - 40px);
    background-color:gray;
}

#footer {
    background-color:black;
}

And here's the HTML to include it

<!doctype html>
<html lang="en">
<head>
<link rel="stylesheet/less" type="text/css" href="test.css" />
<script src="less-1.3.3.min.js"></script>
<body>
<div id="content"></div>
<div id="footer" style="height:40px"></div>
</body>
</html>

"content" is being set to a height of 60%, so less is parsing & incorrectly resolving the calc expression rather than passing it unchanged through to the browser. Tested in Safari 6.0.2 and Firefox.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Feb 2, 2013

Member

Fixed on master for 1.4.0

Member

lukeapage commented Feb 2, 2013

Fixed on master for 1.4.0

@OliverJAsh

This comment has been minimized.

Show comment
Hide comment
@OliverJAsh

OliverJAsh Jun 3, 2014

height: ~"calc(100% - 50px)";

still produces:

height: calc(50%);

for me. I want:

height: calc(100% - 50px);

OliverJAsh commented Jun 3, 2014

height: ~"calc(100% - 50px)";

still produces:

height: calc(50%);

for me. I want:

height: calc(100% - 50px);
@OliverJAsh

This comment has been minimized.

Show comment
Hide comment
@OliverJAsh

OliverJAsh Jun 3, 2014

What’s more, it still produces height: calc(50%); even with strict math set to on.

OliverJAsh commented Jun 3, 2014

What’s more, it still produces height: calc(50%); even with strict math set to on.

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Jun 3, 2014

Member

@OliverJAsh I can't reproduce your results with Less 1.7.0 (both escaped value and --strict-math:on work as expected)... Could you please provide more details on the compiler/environment/scripts you use? (Just in case there was Bootstrap build script issue that could lead to such incorrect results: twbs/bootstrap#13604, maybe this is your case too?).

Member

seven-phases-max commented Jun 3, 2014

@OliverJAsh I can't reproduce your results with Less 1.7.0 (both escaped value and --strict-math:on work as expected)... Could you please provide more details on the compiler/environment/scripts you use? (Just in case there was Bootstrap build script issue that could lead to such incorrect results: twbs/bootstrap#13604, maybe this is your case too?).

@twiginteractive

This comment has been minimized.

Show comment
Hide comment
@twiginteractive

twiginteractive Jul 26, 2014

I was having this issue in 1.6.3 (for some reason, WinLESS is barfing on compile when I upgrade to 1.7.x, so I'm sticking to 1.6.x for now)

My quickfix was just to escape one part of the equation like:

height: calc(~"100%" - unit(@var, px));

This even works for variables, like @var: 50. Or you could escape the whole calculation like calc(~"100% - 50px");

twiginteractive commented Jul 26, 2014

I was having this issue in 1.6.3 (for some reason, WinLESS is barfing on compile when I upgrade to 1.7.x, so I'm sticking to 1.6.x for now)

My quickfix was just to escape one part of the equation like:

height: calc(~"100%" - unit(@var, px));

This even works for variables, like @var: 50. Or you could escape the whole calculation like calc(~"100% - 50px");

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Jul 26, 2014

Member

@twiginteractive If you have to use escaping with --strict-math option off (default setting) then it's not an issue but expected behaviour. See --strict-math.

Member

seven-phases-max commented Jul 26, 2014

@twiginteractive If you have to use escaping with --strict-math option off (default setting) then it's not an issue but expected behaviour. See --strict-math.

@twiginteractive

This comment has been minimized.

Show comment
Hide comment
@twiginteractive

twiginteractive Jul 26, 2014

@seven-phases-max Hmmm - according to the docs, with SM off (default) then this should get parsed correctly (i.e. untouched)
height: calc(100% - 10px);

But it doesn't. The output CSS is height: calc(90%);, which isn't the desired result. Maybe this is fixed in 1.7, but as I say I can't use that version right now until I figure out what is breaking the WinLESS compile.

(Unless I am mis-reading the docs when it says "will be processed correctly"... LESS couldn't know the value of 100%, so it shouldn't do a mathematical computation on '100% - 10px')

twiginteractive commented Jul 26, 2014

@seven-phases-max Hmmm - according to the docs, with SM off (default) then this should get parsed correctly (i.e. untouched)
height: calc(100% - 10px);

But it doesn't. The output CSS is height: calc(90%);, which isn't the desired result. Maybe this is fixed in 1.7, but as I say I can't use that version right now until I figure out what is breaking the WinLESS compile.

(Unless I am mis-reading the docs when it says "will be processed correctly"... LESS couldn't know the value of 100%, so it shouldn't do a mathematical computation on '100% - 10px')

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Jul 26, 2014

Member

@twiginteractive

according to the docs, with SM off (default) then this should get parsed correctly (i.e. untouched)

No, the word there is currently not correctly (i.e. "will be processed currently").

Member

seven-phases-max commented Jul 26, 2014

@twiginteractive

according to the docs, with SM off (default) then this should get parsed correctly (i.e. untouched)

No, the word there is currently not correctly (i.e. "will be processed currently").

@seven-phases-max seven-phases-max modified the milestone: 1.4.0 Jul 26, 2014

@twiginteractive

This comment has been minimized.

Show comment
Hide comment
@twiginteractive

twiginteractive Jul 27, 2014

@seven-phases-max Ah - my bad, it makes sense now. Thanks for the clarification.

twiginteractive commented Jul 27, 2014

@seven-phases-max Ah - my bad, it makes sense now. Thanks for the clarification.

@aamirshahzad

This comment has been minimized.

Show comment
Hide comment
@aamirshahzad

aamirshahzad Sep 5, 2014

height: ~"calc(100% - 50px)"; Worked for me.

aamirshahzad commented Sep 5, 2014

height: ~"calc(100% - 50px)"; Worked for me.

@stevenvachon

This comment has been minimized.

Show comment
Hide comment
@stevenvachon

stevenvachon Sep 5, 2014

This is where Less.js begins to mess with your code. Supposedly v2.0 will have the option to prefix its functions like so:

height: _calc(50%);
height: calc(100% - 50%); /* browser-native */

stevenvachon commented Sep 5, 2014

This is where Less.js begins to mess with your code. Supposedly v2.0 will have the option to prefix its functions like so:

height: _calc(50%);
height: calc(100% - 50%); /* browser-native */
@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Sep 5, 2014

Member

@stevenvachon

Supposedly v2.0 will have the option to prefix its functions like so:

This won't affect calc in any way. There's no built-in calc function, Less is just evaluating a math expression accordingly to its (Less's) rules. That's it. If you don't want this "mess" use --strict-math.

Member

seven-phases-max commented Sep 5, 2014

@stevenvachon

Supposedly v2.0 will have the option to prefix its functions like so:

This won't affect calc in any way. There's no built-in calc function, Less is just evaluating a math expression accordingly to its (Less's) rules. That's it. If you don't want this "mess" use --strict-math.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Sep 5, 2014

Member

P.s. the solution to this problem is strict maths. And maybe we should
force strict maths on when in a call to calc?

Member

lukeapage commented Sep 5, 2014

P.s. the solution to this problem is strict maths. And maybe we should
force strict maths on when in a call to calc?

@stevenvachon

This comment has been minimized.

Show comment
Hide comment
@stevenvachon

stevenvachon Sep 5, 2014

The problem extends when using Myth after Less. Even with strictMath, we need to ~"calc(...)" so that Less ignores it.

stevenvachon commented Sep 5, 2014

The problem extends when using Myth after Less. Even with strictMath, we need to ~"calc(...)" so that Less ignores it.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Sep 5, 2014

Member

Why? Does myth remove parentheses? Strict math makes less a proper superset
of css.

Member

lukeapage commented Sep 5, 2014

Why? Does myth remove parentheses? Strict math makes less a proper superset
of css.

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Sep 5, 2014

Member

And maybe we should force strict maths on when in a call to calc?

We've discussed this in #1872 and there're a few arguments against "local strict-math:on" workarounds. The proposed solution (not quite decided yet) is in #1880.

Member

seven-phases-max commented Sep 5, 2014

And maybe we should force strict maths on when in a call to calc?

We've discussed this in #1872 and there're a few arguments against "local strict-math:on" workarounds. The proposed solution (not quite decided yet) is in #1880.

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Sep 5, 2014

Member

@stevenvachon

Even with strictMath, we need to ~"calc(...)" so that Less ignores it.

Example? I.e. a snippet where Less screws an expression inside calc with --strict-math=on.

Member

seven-phases-max commented Sep 5, 2014

@stevenvachon

Even with strictMath, we need to ~"calc(...)" so that Less ignores it.

Example? I.e. a snippet where Less screws an expression inside calc with --strict-math=on.

@lukeapage

This comment has been minimized.

Show comment
Hide comment
@lukeapage

lukeapage Sep 6, 2014

Member

Since when will v2 prefix functions? Did we decide that and I forgot?

Member

lukeapage commented Sep 6, 2014

Since when will v2 prefix functions? Did we decide that and I forgot?

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Sep 6, 2014

Member

Since when will v2 prefix functions? Did we decide that and I forgot?

No. I guess this was just slightly overestimated #2102 (comment).

Member

seven-phases-max commented Sep 6, 2014

Since when will v2 prefix functions? Did we decide that and I forgot?

No. I guess this was just slightly overestimated #2102 (comment).

@stevenvachon

This comment has been minimized.

Show comment
Hide comment
@stevenvachon

stevenvachon Sep 6, 2014

Yes, sorry, not "the option to" but "the ability write a plugin providing the option to". I'll have to test some code again with and without ~"" on calc(). I must've been mistaken a while back and just kept moving forward with that misunderstanding. I have some older code that I'll have to modify now.

stevenvachon commented Sep 6, 2014

Yes, sorry, not "the option to" but "the ability write a plugin providing the option to". I'll have to test some code again with and without ~"" on calc(). I must've been mistaken a while back and just kept moving forward with that misunderstanding. I have some older code that I'll have to modify now.

@alenb

This comment has been minimized.

Show comment
Hide comment
@alenb

alenb Jun 2, 2015

I've noticed something weird happening with calc when used in-conjunction with width. I've put it all into a codepen just to make it easier: http://codepen.io/anon/pen/OVpJvP

alenb commented Jun 2, 2015

I've noticed something weird happening with calc when used in-conjunction with width. I've put it all into a codepen just to make it easier: http://codepen.io/anon/pen/OVpJvP

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Jun 2, 2015

Member

@alenb

So what is strange there? The code in your codepen is compiled as expected...

Member

seven-phases-max commented Jun 2, 2015

@alenb

So what is strange there? The code in your codepen is compiled as expected...

@alenb

This comment has been minimized.

Show comment
Hide comment
@alenb

alenb Jun 3, 2015

@seven-phases-max

It's compiled, but it's not what's expected. Check the CSS code a little more closely.

It's strange because it still has a gap on the far right even though it should stretch fully with the 3 columns. First two columns should be 33.33% minus 20px with the last column being 33.33%. The first 2 columns would have a padding-right of 20px, but this is not reflected as there is obviously a gap on the far right.

I've played more with it last night and margin-right instead of the padding-right does the trick and resolves the problem.

alenb commented Jun 3, 2015

@seven-phases-max

It's compiled, but it's not what's expected. Check the CSS code a little more closely.

It's strange because it still has a gap on the far right even though it should stretch fully with the 3 columns. First two columns should be 33.33% minus 20px with the last column being 33.33%. The first 2 columns would have a padding-right of 20px, but this is not reflected as there is obviously a gap on the far right.

I've played more with it last night and margin-right instead of the padding-right does the trick and resolves the problem.

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Jun 3, 2015

Member

@alenb

It's compiled, but it's not what's expected. Check the CSS code a little more closely.

Sure, I did. So if you expect something different - please specify.

The first 2 columns would have a padding-right of 20px, but this is not reflected

padding does not affect width in any way (unless you set specific box-sizing), consult CSS specs. So you simply get :
(33% - 20px) + (33% - 20px) + 33% = 99% - 40px -> 40px gap as expected.

Either way this is related solely to CSS and has nothing to do with how Less compiles calc. Click "view compiled" button in the codepen code and there you see your calc statements are compiled by Less exactly to what you specified).

Member

seven-phases-max commented Jun 3, 2015

@alenb

It's compiled, but it's not what's expected. Check the CSS code a little more closely.

Sure, I did. So if you expect something different - please specify.

The first 2 columns would have a padding-right of 20px, but this is not reflected

padding does not affect width in any way (unless you set specific box-sizing), consult CSS specs. So you simply get :
(33% - 20px) + (33% - 20px) + 33% = 99% - 40px -> 40px gap as expected.

Either way this is related solely to CSS and has nothing to do with how Less compiles calc. Click "view compiled" button in the codepen code and there you see your calc statements are compiled by Less exactly to what you specified).

@alenb

This comment has been minimized.

Show comment
Hide comment
@alenb

alenb Jun 3, 2015

@seven-phases-max

I would have thought the codepen would make this apparent, but no problem at all.

Thanks for the info!

alenb commented Jun 3, 2015

@seven-phases-max

I would have thought the codepen would make this apparent, but no problem at all.

Thanks for the info!

@rkyoku

This comment has been minimized.

Show comment
Hide comment
@rkyoku

rkyoku Apr 8, 2016

Today it still doesn't work with default installation of less (using npm).

I had to use:
min-height: ~"calc(100% - 262px)"; //calc(100% - 262px);

I don't know if it is normal, as the bug is marked "closed", but just wanted to let you know.

rkyoku commented Apr 8, 2016

Today it still doesn't work with default installation of less (using npm).

I had to use:
min-height: ~"calc(100% - 262px)"; //calc(100% - 262px);

I don't know if it is normal, as the bug is marked "closed", but just wanted to let you know.

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max
Member

seven-phases-max commented Apr 8, 2016

@RenaudParis --strict-math

@rkyoku

This comment has been minimized.

Show comment
Hide comment
@rkyoku

rkyoku Apr 8, 2016

Okay I will try that, thank you! But wouldn't it be better that it is by
default? Because it is quite surprising, when you don't know about this
parameter.

Thanks anyway!

Le ven. 8 avr. 2016 à 20:48, Max Mikhailov notifications@github.com a
écrit :

@RenaudParis https://github.com/RenaudParis --strict-math
http://lesscss.org/usage/#command-line-usage-strict-math


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#974 (comment)

rkyoku commented Apr 8, 2016

Okay I will try that, thank you! But wouldn't it be better that it is by
default? Because it is quite surprising, when you don't know about this
parameter.

Thanks anyway!

Le ven. 8 avr. 2016 à 20:48, Max Mikhailov notifications@github.com a
écrit :

@RenaudParis https://github.com/RenaudParis --strict-math
http://lesscss.org/usage/#command-line-usage-strict-math


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#974 (comment)

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Apr 9, 2016

Member

But wouldn't it be better that it is by default?

Making it to be default will break a lot of existing Less code-bases. Once (at ~v1.4.0) there was an attempt to make it to be default actually, but then it's reversed because of legacy backward-compatibility... A newer, less-intrusive method was developed at #1880 (but it's not implemented yet).

Member

seven-phases-max commented Apr 9, 2016

But wouldn't it be better that it is by default?

Making it to be default will break a lot of existing Less code-bases. Once (at ~v1.4.0) there was an attempt to make it to be default actually, but then it's reversed because of legacy backward-compatibility... A newer, less-intrusive method was developed at #1880 (but it's not implemented yet).

@rkyoku

This comment has been minimized.

Show comment
Hide comment
@rkyoku

rkyoku Apr 9, 2016

Okay, thank you for taking the time to explain it to me Max!

Le sam. 9 avr. 2016 13:46, Max Mikhailov notifications@github.com a
écrit :

But wouldn't it be better that it is by
default?

Making it to be default will break a lot of existing Less code-bases. Once
(at ~v1.4.0) there was an attempt to make it to be default actually, but
then it's reversed because of legacy backward-compatibility... A newer,
less-intrusive method was developed at #1880
#1880 (but it's not implemented
yet)).


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#974 (comment)

rkyoku commented Apr 9, 2016

Okay, thank you for taking the time to explain it to me Max!

Le sam. 9 avr. 2016 13:46, Max Mikhailov notifications@github.com a
écrit :

But wouldn't it be better that it is by
default?

Making it to be default will break a lot of existing Less code-bases. Once
(at ~v1.4.0) there was an attempt to make it to be default actually, but
then it's reversed because of legacy backward-compatibility... A newer,
less-intrusive method was developed at #1880
#1880 (but it's not implemented
yet)).


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#974 (comment)

neic added a commit to TK-IT/web that referenced this issue May 3, 2016

@mqliutie

This comment has been minimized.

Show comment
Hide comment
@mqliutie

mqliutie Sep 1, 2016

I have solved this :

.calc(@prop, @val) {
    @{prop}: ~"calc(~'@{val}')";
    @{prop}: ~"-moz-calc(~'@{val}')";
    @{prop}: ~"-webkit-calc(~'@{val}')";
    @{prop}: ~"-o-calc(~'@{val}');"
}
.calc(width, "80% - 36px");

When I use command line it is correct . Only less-loader is not correct. So I found this solution on stackoverflow

I copy it to my code, Sadly it also not correct. So I modified something. It works!

Unfortunately, command line is not correct!!😂 😂 😂

mqliutie commented Sep 1, 2016

I have solved this :

.calc(@prop, @val) {
    @{prop}: ~"calc(~'@{val}')";
    @{prop}: ~"-moz-calc(~'@{val}')";
    @{prop}: ~"-webkit-calc(~'@{val}')";
    @{prop}: ~"-o-calc(~'@{val}');"
}
.calc(width, "80% - 36px");

When I use command line it is correct . Only less-loader is not correct. So I found this solution on stackoverflow

I copy it to my code, Sadly it also not correct. So I modified something. It works!

Unfortunately, command line is not correct!!😂 😂 😂

@vincentmorneau

This comment has been minimized.

Show comment
Hide comment
@vincentmorneau

vincentmorneau Nov 3, 2016

Not sure why this issue is closed. It doesn't make sense that Less would change a native CSS behavior.

vincentmorneau commented Nov 3, 2016

Not sure why this issue is closed. It doesn't make sense that Less would change a native CSS behavior.

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Nov 4, 2016

Member

... Less would change a native CSS behavior.

It would not. Just set --strict-math=on (not enabled by default because of compatibility with a gigantic amount of Less projects depending on --strict-math=off, plus a few considerations mentioned at #1880).

Member

seven-phases-max commented Nov 4, 2016

... Less would change a native CSS behavior.

It would not. Just set --strict-math=on (not enabled by default because of compatibility with a gigantic amount of Less projects depending on --strict-math=off, plus a few considerations mentioned at #1880).

@oshihirii

This comment has been minimized.

Show comment
Hide comment
@oshihirii

oshihirii Aug 6, 2017

In a UIkit 3 theme I am using this in my_theme.less:

height: ~"calc(100vh - 20px)";

And it works.

oshihirii commented Aug 6, 2017

In a UIkit 3 theme I am using this in my_theme.less:

height: ~"calc(100vh - 20px)";

And it works.

@quytm2239

This comment has been minimized.

Show comment
Hide comment
@quytm2239

quytm2239 Oct 16, 2017

It worked for me when writing in *.less file #974 (comment)

Thank @lukeapage ! 🥇

quytm2239 commented Oct 16, 2017

It worked for me when writing in *.less file #974 (comment)

Thank @lukeapage ! 🥇

@ciaranlp

This comment has been minimized.

Show comment
Hide comment
@ciaranlp

ciaranlp Oct 19, 2017

Hi @mqliutie thanks for adding the mixin suggestion for calc, but, there is an extra ~ in your Mixin that was breaking the compilation:

the mixin should be

.calc(@prop, @val) {
    @{prop}: ~"-webkit-calc('@{val}')";
    @{prop}: ~"-moz-calc('@{val}')";
    @{prop}: ~"calc('@{val}')";
}

Input as follows:
.calc(width, "100% - 60px");

Output as follows:
width: calc(100% - 60px);

ciaranlp commented Oct 19, 2017

Hi @mqliutie thanks for adding the mixin suggestion for calc, but, there is an extra ~ in your Mixin that was breaking the compilation:

the mixin should be

.calc(@prop, @val) {
    @{prop}: ~"-webkit-calc('@{val}')";
    @{prop}: ~"-moz-calc('@{val}')";
    @{prop}: ~"calc('@{val}')";
}

Input as follows:
.calc(width, "100% - 60px");

Output as follows:
width: calc(100% - 60px);

@thany

This comment has been minimized.

Show comment
Hide comment
@thany

thany Jan 25, 2018

Why is this issue closed?! It's not fixed.

I'm still getting calc(30%) when I write calc(50% - 20px). This is never what anyone wants. Apart from the fact that it's wrong to blindly calculate with different units, it should leave it as-is in a calc(), unless it can be calculated with 100% reliability (e.g. same units). I'm using LESS 2.7.3.

Please reopen this issue.

thany commented Jan 25, 2018

Why is this issue closed?! It's not fixed.

I'm still getting calc(30%) when I write calc(50% - 20px). This is never what anyone wants. Apart from the fact that it's wrong to blindly calculate with different units, it should leave it as-is in a calc(), unless it can be calculated with 100% reliability (e.g. same units). I'm using LESS 2.7.3.

Please reopen this issue.

@jonjohnjohnson

This comment has been minimized.

Show comment
Hide comment
@jonjohnjohnson

jonjohnjohnson Jan 25, 2018

@thany
Refer to these comments, they describe how this isn't exactly an issue, as much as the default setting of processing math is a byproduct of history, and you can always change the default setting.
#974 (comment)
#974 (comment)

jonjohnjohnson commented Jan 25, 2018

@thany
Refer to these comments, they describe how this isn't exactly an issue, as much as the default setting of processing math is a byproduct of history, and you can always change the default setting.
#974 (comment)
#974 (comment)

@thany

This comment has been minimized.

Show comment
Hide comment
@thany

thany Jan 26, 2018

@jonjohnjohnson That's just stating the problem again. If strict mode fixes it (haven't tried yet, shouldn't be neccesary to enable all kinds of nondefault flags in order to work around bugs) then it should be on by default.

No matter how you put it, this issue is not fixed by any definition.

thany commented Jan 26, 2018

@jonjohnjohnson That's just stating the problem again. If strict mode fixes it (haven't tried yet, shouldn't be neccesary to enable all kinds of nondefault flags in order to work around bugs) then it should be on by default.

No matter how you put it, this issue is not fixed by any definition.

@jonjohnjohnson

This comment has been minimized.

Show comment
Hide comment
@jonjohnjohnson

jonjohnjohnson Jan 26, 2018

@thany I was just trying to help you understand that the developers decided it's not an issue according to them. Those comments don't just restate the problem, they describe the developers stance on the issue. Good luck.

jonjohnjohnson commented Jan 26, 2018

@thany I was just trying to help you understand that the developers decided it's not an issue according to them. Those comments don't just restate the problem, they describe the developers stance on the issue. Good luck.

@seven-phases-max

This comment has been minimized.

Show comment
Hide comment
@seven-phases-max

seven-phases-max Jan 26, 2018

Member

@thany

then it should be on by default.

It can't be because this would immediately break zillion projects out there. So if you treat the default behaviour as an issue just set the documented option and be done. By any definition.

Why is this issue closed?!

Because the uptodate disscussion of how to improve the default behaviour is here.

Member

seven-phases-max commented Jan 26, 2018

@thany

then it should be on by default.

It can't be because this would immediately break zillion projects out there. So if you treat the default behaviour as an issue just set the documented option and be done. By any definition.

Why is this issue closed?!

Because the uptodate disscussion of how to improve the default behaviour is here.

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Jan 27, 2018

Member

@thany As @seven-phases-max, if you want to see this solved, contribute to #1880. I think the solution is there, but there hasn't been enough community weigh-in to come to a decision that is ready to implement. It's a long thread, but that's what solution-finding takes: reviewing proposals and weighing in one way or another. And then: someone to take on the work to implement.

Member

matthew-dean commented Jan 27, 2018

@thany As @seven-phases-max, if you want to see this solved, contribute to #1880. I think the solution is there, but there hasn't been enough community weigh-in to come to a decision that is ready to implement. It's a long thread, but that's what solution-finding takes: reviewing proposals and weighing in one way or another. And then: someone to take on the work to implement.

matthew-dean added a commit to matthew-dean/less.js that referenced this issue Feb 10, 2018

matthew-dean added a commit that referenced this issue Feb 11, 2018

@stefaniacardenas stefaniacardenas referenced this issue Mar 14, 2018

Merged

Feature/privacy statement cx 1711 #316

4 of 4 tasks complete

matthew-dean added a commit that referenced this issue Jun 30, 2018

[Feature] Namespaced values (#3242)
* calc() fix - fixes #974
* Parses and retrieves a namespaced value
* Adds a bunch of new tests for aliasing and namespacing
* Added more CSS Grid tests
* Added tests for passing mixins into mixins, since it's just another value
* Release v3.5.0-beta.4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment