calc(100% - 88px) results in calc(12%)

[varunshoor]

As the title says, the data is being changed to some incomprehensible value. Any idea on how to fix it?

[varunshoor]

Fix is to add unit comparison check in op_number_number() and bail out if the units are not the same. Can someone merge this into the repo?

    // operator on two numbers
    protected function op_number_number($op, $left, $right) {
        // Not same unit? return as is
        if (!empty($left[2]) && !empty($right[2]) && $left[2] != $right[2])
        {
            return array('number', $left[1] . $left[2] . ' ' . $op . ' ' . $right[1] . $right[2], '');
        }

[leafo]

In this case shouldn't the arguments to calc be left alone and not evaluated? There's no way to evaluate 100% - 80px ahead of time.

[varunshoor]

Correct. Isn't the fix I provided right?

Sent from my iPad

On 20-Oct-2012, at 12:34 AM, leaf notifications@github.com wrote:

In this case shouldn't the arguments to calc be left alone and not evaluated? There's no way to evaluate 100% - 80px ahead of time.

— Reply to this email directly or view it on GitHubhttps://github.com/leafo/lessphp/issues/326#issuecomment-9613802.

[leafo]

No, the correct fix is to look for calc function calls, and disable all expressions from being evaluated inside of them.

[Cerdic]

Be carrefull, @vars should be evaluated inside calc() :

width:calc(25% - (3*@gridGutterWidth/4));

[kaystrobach]

i would expect an exception, if the units do not match, or the silent ignore which was suggested :)

[varunshoor]

So whats the final direction?

[kirschkern]

I just ran into this. Would be great to see this fixed. Any workaround so far?

[kaystrobach]

what i can see as a solution would be to transfer such a query to:

https://developer.mozilla.org/en-US/docs/CSS/calc

So what are 80% - 90px ... :d

width: calc(100% - 80px);

[cutesquirrel]

Hi, any news about this issue ? I think @varunshoor solution is good, i'm using it with any problem :)

Another ugly solution would be to write something like

width: calc(~"100% - "@width-right);

It works but I think it doesn't belong to the LESS file to handle parsing problem.

Thanks

[caiosm1005]

I think operations between dimensions of different types should be just silently ignored. This way the parser leaves calc() intact. Ignoring just the contents inside calc() would be kinda messy.

[kaystrobach]

+1

[NielsJanssen]

+1

[moroz1999]

Any hotfix for this? calc(50% - 1em) gives calc(49%)

[kaystrobach]

@moroz1999 what do you expect? ... how many pixels is your 100% :smile: nobody knows ...

[seven-phases-max]

Just write calc(50% ~'-' 1em) instead.

[moroz1999]

@kaystrobach I expect the CSS3 feature named "calc" work as designed without being recalculated. https://developer.mozilla.org/en-US/docs/Web/CSS/calc

lessphp should ignore such case at all without making any modifications. It's up to browser to make the equation in this case.

Try to compile the following code in lessphp: .myclass { width: calc(100%-10px); } This is absolutely valid CSS3 without any less code, so this should be rendered into exactly the same string (in other words, ignored without any changes). Instead, you will get: .myclass { width: calc(90%); } Which is absolutely invalid.

[moroz1999]

@seven-phases-max, thanks, I'll give it a try!

update:@seven-phases-max, thanks a lot, your solution works just perfectly.

[kaystrobach]

@moroz1999 ok, perfect, the solution from @seven-phases-max should work

[iainhallam]

I've just run into this with a CSS framework I can't change, in the DokuWiki project, which automatically parses CSS files through LESSPHP. Fixing this to ignore calc() expressions apart from variable expansion would be most welcome!

[Michaelsy]

A trick to insert (nearly) every unparsed code in LESSPHP: https://github.com/splitbrain/dokuwiki/issues/2254#issuecomment-386814503

[Rainbow-Spike]

~"screen CSS code from LESS parser"