fix: don't break CSS keywords when formatting math expressions

[rozsazoltan]

Fixes #18219

Summary

In an arbitrary value, if there's a non-numeric character both before and after a hyphen, there's no need for a space.

Test plan

decodeArbitraryValue will correctly format special CSS values like fit-content. I believe spaces are only necessary if there's a digit either before or after the hyphen.

decodeArbitraryValue('min(fit-content,calc(100dvh-4rem))')

This way, the result of the following arbitrary value will also be correct:

<div class="min-h-[min(fit-content,calc(100dvh-4rem))]"></div>

.min-h-\[min\(fit-content\,calc\(100dvh-4rem\)\)\] {
  min-height: min(fit-content, calc(100dvh - 4rem));
}

[rozsazoltan]

Inside CSS functions, whitespace is added before and after every math operator; I believe this should only be necessary if there is a number before or after the operator.

A number or another operator or function?

Or maybe it's easier to just list the exceptions. I'll leave it as a draft for now.

[rozsazoltan]

decodeArbitraryValue('min(fit-content,calc(100dvh-4rem))')
decodeArbitraryValue('min(fit-content,calc(100dvh-4rem)-calc(50dvh-2px))')

Now:

min(fit-content, calc(100dvh - 4rem))
min(fit-content, calc(100dvh - 4rem)-calc(50dvh - 2px))

And if, in addition to checking for numbers, we also check whether a math function follows it:

let rest = (input.slice(i + 1) || '').trimEnd()
let next = input[i + 1] || ''

// ...

// If there's no number before or after it and it's not followed by a math function, don't add spaces.
else if (
  next.length > 0 &&
  !/\d/.test(prev + next) &&
  !MATH_FUNCTIONS.some(fn => rest.startsWith(fn + '('))
) {
  result += char
  continue
}

Will be:

min(fit-content, calc(100dvh - 4rem))
min(fit-content, calc(100dvh - 4rem) - calc(50dvh - 2px))

[rozsazoltan]

Another possible case is when there is text before it, and an operator follows it - for example: -1, or (2*3), etc.

1 - )    // illegal - not relevant
1 - (    // is possible
1 - -1   // is possible
1 - +1   // is possible

next !== '(' && next !== '+' && next !== '-'

Also, when dealing with functions, we need to consider that formatting is not only required for standard functions, but actually for anything that looks like a function.

1 - calc (  // illegal - not relevant
1 - calc(   // is possible
1 - theme(  // is possible (not standard)

// Original for only CSS functions
!MATH_FUNCTIONS.some(fn => rest.startsWith(fn + '('))

// New for standard function declaration
!/^[a-zA-Z_$][a-zA-Z0-9_$]*\(/.test(input.slice(i + 1))

I believe it's unnecessary to declare every single case, since introducing a new function should come with updating this accordingly. Also, this way the process can work better with custom syntax as well.

[wongjn]

A few other edge cases that don't work which we should perhaps consider. Mainly scientific notation and calc-size() since they may include - in their notations:

['min(-3.4e-2-var(--foo),calc-size(auto))', 'min(-3.4e-2 - var(--foo), calc-size(auto))'],

Expected: "min(-3.4e-2 - var(--foo), calc-size(auto))"
Received: "min(-3.4e - 2 - var(--foo), calc - size(auto))"

[
  'clamp(-10e3-var(--foo),calc-size(max-content),var(--foo)+-10e3)',
  'clamp(-10e3 - var(--foo), calc-size(max-content), var(--foo) + -10e3)'
],

Expected: "clamp(-10e3 - var(--foo), calc-size(max-content), var(--foo) + -10e3)"
Received: "clamp(-10e3 - var(--foo), calc - size(max-content), var(--foo) + -10e3)"

[RobinMalfait]

Thanks! I iterated a bit more on this because I didn't like the regex parts.

I started with a similar approach we used before, where we safelisted a few known idents. But then cleaned it up a bit more by making sure we don't have any hardcoded identifiers to make it more future proof.

In order to do this, we have to track a bit more information, but there are already some rules you identified. We want spaces if:

• There is a digit before the operator
• There is a digit after the operator
• There is a ( after the operator (start of a parenthesized expression)
• There is a ) before the operator (end of a parenthesized expression / function)
• The operator is followed by another operator. E.g.: 1px + -2px
• The operator was not preceded by a value (+unit). This is important to handle scenarios like this: calc(1rem-theme(…)). In this case rem-theme could look like a valid function, but since 1rem was used it definitely is not part of the function.

Some of them are technically not required, but they will look better if it's consistent.

I also added better support for the scientific notation.