Is css-calc suitable for use in a minifier?

[ludofischer]

Hello, I am maintaining postcss-calc to use it inside of the cssnano minifier. I was wondering if css-calc could replace most of the current code, which relies on a currently unmaintained parser generator. css-calc even uses some tests derived from postcss-calc issues, but it is not advertised as a minifier: would using it as such would conflict with the intended development direction?

[romainmenke]

Hi @ludofischer,

css-calc is not really build to be a minifier.
It was build primarily to support relative color syntax.
For relative colors it is important to find the final outcome of a calc expression.
Any expression that doesn't have an outcome known at build-time is ignored.

While a minifier will often try to optimize any expression, even when no outcome can be calculated.
For example:

• calc(100% - 10px + 20px) -> calc(100% + 10px)
• calc(var(--foo) - 10px + 20px) -> calc(var(--foo) + 10px)

---

I wrote css-calc as a recursive descent parser that instead of return the full AST of all children returns the solved calc expression of the children.

When it encounters something it can't solve it aborts the entire mutation.

I think it is definitely possible to instead keep trying to solve as many parts as possible.
This could make it work as a minifier.

There will definitely be edge cases where postcss-calc is doing smarter transforms that won't be trivial to implement here.

---

I've followed some of the issues in postcss-calc and I also wondered if css-calc could help here. Worst case we could duplicate the code base and create a specialized variant.

[ludofischer]

Thank you for your answer! Actually, last time I checked css-calc passed the whole postcss-calc test suite except the nested calc expressions that I think are handled in a separate plugin the csstools repo. I also find the color tools in csstools interesting for cssnano.

[romainmenke]

It might be interesting to add some tests here to cover the intent to minimize calc expressions.

I would like to have sufficient safe guards in place to make sure that we don't accidentally break things for cssnano while doing updates here.

[ludofischer]

From a rapid look at the suite and the tests, it does not look like postcss-calc is doing anything besides replacing calculations with the result. The main difference is that it replaces nested calcs in the same pass as it calculates the results. It might be that it also started as a compatibility tool when not all browsers supported calc(). I am a bit hesitant to recommend that you impose additional burden to handle minification.
There's two issues that make be believe that spending effort on minifying properties has a limited return. The first is that often when a transform preserves correctness, it does not reduce size. For example, when you transform a fraction you need to preserve so many decimals that the result take more characters than the initial definition. The second is that, as people use custom properties more and more, it becomes impossible to make a correct transformation in any case.
Color minfication might be similar, where for more recent color spaces it is not possible to produce a smaller output without visibly changing the colour.

[romainmenke]

it does not look like postcss-calc is doing anything besides replacing calculations with the result

correct :)

The main difference is that it replaces nested calcs in the same pass as it calculates the results

It is doing a walk of the AST of the provided value and when it finds a math expression it will recursively solve that calculation.

This is why it can transform these:

• calc(10% + calc(10px * 2)) -> calc(10% + 20px)
• calc(10px + calc(10px * 2)) -> 30px

but not calc(10% + (10px * 2))

(10px * 2) is not a math expression when visited out of context.
It is only solved when part of a larger, solvable expression.

It might be that it also started as a compatibility tool when not all browsers supported calc()

The goal (maybe surprisingly) never was to support math expressions themselves.
But rather to support other features, like relative color syntax that can contain math expressions.

So finding a solution to an expression was always more important than transforming the expression itself.

The first is that often when a transform preserves correctness, it does not reduce size. For example, when you transform a fraction you need to preserve so many decimals that the result take more characters than the initial definition.

I think this is solvable.

We can solve math expressions and make a judgement on the outcome.

• Is it a terminating decimal or not? A non-terminating or repeating decimal would be better written as the original or a smaller fraction. (there are tricks to find 2 / 3 from 0.666666666...)
• Is the result as a string longer than the original?

This involves a bit of brute forcing, you need to do the work to then measure the output. Potentially discarding the work, to use the original anyway.

The second is that, as people use custom properties more and more, it becomes impossible to make a correct transformation in any case.

correct

---

One thing that I regret is not sticking to the spec for the internal representation.

see : https://drafts.csswg.org/css-values-4/#calc-internal

I think that refactoring the current code base so that it does adhere to the spec would be better.

Currently we only follow the parsing rules and evaluation rules, but not the internal representation or serialization.

CSS has well defined rules for what can be safely simplified in a math expression: https://drafts.csswg.org/css-values-4/#calc-simplification and this is part of the internal representation

This essentially describes a minifier for calc()

---

Color minfication might be similar, where for more recent color spaces it is not possible to produce a smaller output without visibly changing the colour.

This has an extra issue because gamut mapping is currently not going to be part of every color function. color(display-p3 ....) won't have gamut mapping, while oklab(...) will. So even changing from one function to another with sufficient numerical precision to describe the same color might not actually behave in the same way in a browser. I personally think that this behavior is extremely cursed and I really hope that Chrome/Google gets off their high horse and agrees to a more reasonable spec, but that is unlikely.

As far as I know you can only do these transforms:

• all color functions to smaller variants of themselves (less precision, less whitespace, ...)
• rgb() to hex
• color(display-p3 ...) to color(srgb ...) only if the defined color fits within the gamut of both the origin and target. (same for rec2020, ...)
• lab to oklab and back
• lch to oklch and back

These can not be changed to another form:

• hsl
• hwb
• any color containing none
• any relative color

[ludofischer]

Thank you for all your explanations, it's going to take some time to digest! I did not remember correctly when I said that @csstools/css-calc passed all tests of postcss/postcss-calc. It's very close.

It is doing a walk of the AST of the provided value and when it finds a math expression it will recursively solve that calculation.

I suppose that's the reason @csstools/css-calc does not transform this code:

calc(100px + (100px - 100%))

b

calc(200px - 100%)

CSS has well defined rules for what can be safely simplified in a math expression: https://drafts.csswg.org/css-values-4/#calc-simplification and this is part of the internal representation

I notice it says that white space is discarded, which covers another difference with postcss/pocss-calc, namely that postcss/postcss-calc removes the white space too. But would it be acceptable for @csstools/css-calc to remove the whitespace?

One thing that I regret is not sticking to the spec for the internal representation

I did not know about the internal representation at all. This is very interesting! When you say refactoring, do you mean you would like to also change the csstools/tokenizer package?

[romainmenke]

But would it be acceptable for @csstools/css-calc to remove the whitespace?

The CSS serialization algorithms emit a few spaces that aren't strictly needed.

For example: min(10px, 20px)
The space after , isn't needed, but it aids in readability.

I think that follow the spec is more important than producing a good minifier, so I would start by following the spec.

However I don't see a reason why this can't be config and I don't mind providing a second serialization algorithm that omits whitespace and comments.

When you say refactoring, do you mean you would like to also change the csstools/tokenizer package?

A first step could be for us to actually follow the spec for the internal representation of a calc tree when parsing.

This wouldn't change how @csstools/css-calc works from the outside.
But it would give us a clearer picture of which extra capabilities become available when actually implementing this correctly from start to end :)

---

I don't foresee any changes to @csstools/css-tokenizer.

It is possible that some utilities are needed and that those could find their way into @csstools/css-tokenizer but that is an implementation detail.

---

I will have more time in the fall to work on something like this.