Negative calculated value lose its unit

[MatTheCat]

@font-size-base: 1em;
@atomic-distance-base: unit(5/8, em);

@line-height-base: (ceil(@font-size-base/@atomic-distance-base)*(@atomic-distance-base/@font-size-base));

If I write margin: @line-height-base; I get margin: 1.25em; as expected. margin: (@line-height-base*2); get me margin: 2.5em; too.

But get-unit(@line-height-base) echoes an empty value and the unit is removed if the result of an operation with this value is negative. Eg. margin: (1 - @line-height-base); will generate margin: -0.25;

I guess it's logical the unit is lost after a division but why is it still there in some case?

Thanks.

[bassjobsen]

you can see what happens when compiling the following code:

tests {
multiplication: get-unit(1em*2em);
division: get-unit(2em/2em);
addition: get-unit(2em+2em);
substraction: get-unit(2em-2em);
}

the above outputs:

tests {
  multiplication: em*em;
  division: ;
  addition: em;
  subtraction: em;
}

The outcome of units in the above is (mathematically) as expected.

In your case @line-height-base is an division of two em units, and so the unit has been removed.

I guess it's logical the unit is lost after a division but why is it still there in some case?

Which cases?

You can apply unit(value,em); to your divisions and multiplication to "force" it to em (which make mathematically no sense).

unit(2em/2em,em) returns 1em

[MatTheCat]

If @line-height-base has no unit how comes margin: @line-height-base; gives margin: 1.25em;?

[bassjobsen]

well, now i understand your question (sorry)

margin: @line-height-base; gives margin: 1.25em; because of the ----strict-units option has been set off (default).

echo "s{p:2em/2em}" | lessc - outputs:

s {
  p: 1em;
}

whilst echo "s{p:2em/2em}" | lessc --strict-units=on - outputs:

s {
  p: 1;
}

[MatTheCat]

Oh I'm really sorry, I use less through assetic so I had no idea it had this option. Thanks for your time!

[bassjobsen]

Does it really solve your issue? i think with --strict-units=off 1 - 1em is some kind of unpredictable, but the compiler takes the unit of the first number in this case where the (to remembered cause the --strict-units=off) unit of the second number seems to be lost due to the division.

test{
t1: 20 - 2em/1em;
t2: -2em/1em + 20;
t3: 20 - 2em;
}

outputs:

test {
  t1: 18;
  t2: 18em;
  t3: 18em;
}

i think the above should output 18em; for all three cases. The lost unit seems a bug.

Taking the above into account one could expect that in your situation possible using (-@line-height-base + 1); instead of (1 - @line-height-base); would help, but it does not, the unit has been lost already

[MatTheCat]

I'll use strict units now so I guess my issue is fixed.
I don't really know what to say about the behavior I described. It wasn't what I expected but I guess neither less did expect my code.