WIP: Implement calc

[jsakas]

Begin to implement the calc() css function.

This work is not complete, because calc will evaluate what it can inside of the expression and return that as the result. e.g. 100% * 2 becomes 200%. There is a failing test case on the branch for this.

We need to parse the expression, and units, and evaluate them according to the spec and existing browser implementations.

https://drafts.csswg.org/css-values-3/#calc-notation
https://developer.mozilla.org/en-US/docs/Web/CSS/calc

[nitinthewiz]

This is a really timely PR! I'm using jsdom to create elements in node and then save the HTML. I don't know if this is the right tool for the job, but it does it quite well, specially with .serialize(), which is just awesome!

I needed calc, because it is needed in the output, and the browser doesn't need calc to be computed, as you need it to be.

So, I'm going to adopt this code for my needs. I'll try to use the npm patch-package library to do the patching.

Thanks!

[jsakas]

@nitinthewiz that is an interesting use case for this library, thanks for sharing. I have been debating whether or not I think that calc should be computed. It seems like a lot of work and I'm not actually sure if that feature would be beneficial.

I think if we implemented calc in a way that it could be set but not computed, it would solve your use case as well as close #100

I may have been overthinking it when I was exploring computing the values in a way that browsers do.

[domenic]

I don't have a lot of context on this PR but I just want to say that jsdom supports anything that makes it easier for us to get the same behavior as browsers :).

[nitinthewiz]

@domenic heh, technically browsers compute calc, but I don't see a good reason for jsdom to, because it doesn't have a view...

[snoozbuster]

I just spent upwards of a couple hours trying to debug why adding a very simple width: calc(30% - 2px) to one of my vuejs components caused the style attribute to disappear entirely in my tests (which are run under nodejs with jest and jsdom), causing them to fail... only to trace it back to this issue/PR. My use case is also one which would be solved by a simple set-but-not-compute solution; right now I have to test that my code is computing the width correctly but can't test that it actually binds to the element (a crucial part of this code's functionality). Is there a possibility that this PR can be revived and merged?

[jsakas]

Closing in favor of #115

If we need to add computed calc in the future it would be a larger initiative, but for now I think we should at least let calc values pass through.

[cdoublev]

I'm in a situation where all I need is having the calc values passed through, but I would like to set a border length with it, and parserLength currently does not handle it (only the "measurement" parser handles calc, ie. values which are either a length or a percentage). parseInteger, parseNumber, parsePercent, parseColor, and parseAngle should also handle it.

While this is a valid issue that may be relatively easy to fix, I took a look at computing calc before.

My biggest concern for doing it is that some properties will have a percentage value resolved at computed value time, while some others will have them resolved at used value time, which may involve resolving other properties, eventually from a containing element. There's also resolving attr() nested in calc.

So my question is: is it worth trying a partial implementation to compute calc, ie. returning as is a calc that includes a percentage, but that conforms to the other requirements, ie. with types checking? Or should I only create an issue / send a pull request to fix the above mentionned cases where calc should also pass through?