The CSS value spec allows for parentheses to be used to group sub-expressions in calc() in order to force operation order when the natural precedence isn't sufficient for the expression.
But when getComputedStyle() is used to retrieve the calc() expression, if it contains any pairs of parens, the reported value is "" instead of the expected expression.
Basic info:
- Node.js version: v19.7.0
- jsdom version: v21.1.1
Minimal reproduction case
const { JSDOM } = require("jsdom");
[
'calc(1px)',
'calc((1px))',
'calc(1px + 4px)',
'calc(1px + (4px))',
'calc(1px + 4px / 2)',
'calc(1px + (7px - 3px) / 2)',
].forEach((testCase, idx) => {
const dom = new JSDOM(`
<!DOCTYPE html>
<p style="width: ${testCase};">hello</p>
`);
const style = dom.window.getComputedStyle(
dom.window.document.querySelector('p')
);
const widthStyle = style.getPropertyValue('width');
console.log(
'test case %s: width="%s" | expected="%s" // %s',
idx,
widthStyle,
testCase,
widthStyle === testCase ? '✅ PASS' : '⛔️ FAIL'
);
});Output:
test case 0: width="calc(1px)" | expected="calc(1px)" // ✅ PASS
test case 1: width="" | expected="calc((1px))" // ⛔️ FAIL
test case 2: width="calc(1px + 4px)" | expected="calc(1px + 4px)" // ✅ PASS
test case 3: width="" | expected="calc(1px + (4px))" // ⛔️ FAIL
test case 4: width="calc(1px + 4px / 2)" | expected="calc(1px + 4px / 2)" // ✅ PASS
test case 5: width="" | expected="calc(1px + (7px - 3px) / 2)" // ⛔️ FAIL
How does similar code behave in browsers?
https://jsbin.com/zeximin/edit?html,js,console,output
The output in the browser is actually different on all counts because the calc expressions are actually evaluated, but if you use DevTools to inspect the widths, the original calc expressions, as JSDom should report them, are all shown as valid CSS values.
test case 0: width="1px" | expected="calc(1px)" // ⛔️ FAIL
test case 1: width="1px" | expected="calc((1px))" // ⛔️ FAIL
test case 2: width="5px" | expected="calc(1px + 4px)" // ⛔️ FAIL
test case 3: width="5px" | expected="calc(1px + (4px))" // ⛔️ FAIL
test case 4: width="3px" | expected="calc(1px + 4px / 2)" // ⛔️ FAIL
test case 5: width="3px" | expected="calc(1px + (7px - 3px) / 2)" // ⛔️ FAIL
Here's test case 6 in Chrome (Version 112.0.5615.137 (Official Build) (arm64)) DevTools:
❗ But I'm not implying jsdom needs to eval the expressions. I'm just saying it should allow for parentheses within calc() expressions and return the expression, not an empty string as though the specified value was invalid. The CSS spec does allow for parentheses: https://www.w3.org/TR/css-values-3/#calc-syntax
I did a bit of digging and I think the problem may lie deeper here: https://github.com/rrweb-io/CSSOM/blob/402a2c7a813890c6c116244827f200cd6c04f0bb/lib/CSSValueExpression.js#L36 But that repo doesn't allow filing issues so I figured I would report this here.
The CSS value spec allows for parentheses to be used to group sub-expressions in
calc()in order to force operation order when the natural precedence isn't sufficient for the expression.But when
getComputedStyle()is used to retrieve thecalc()expression, if it contains any pairs of parens, the reported value is""instead of the expected expression.Basic info:
Minimal reproduction case
Output:
How does similar code behave in browsers?
https://jsbin.com/zeximin/edit?html,js,console,output
The output in the browser is actually different on all counts because the
calcexpressions are actually evaluated, but if you use DevTools to inspect the widths, the originalcalcexpressions, as JSDom should report them, are all shown as valid CSS values.Here's test case 6 in Chrome (Version 112.0.5615.137 (Official Build) (arm64)) DevTools:
❗ But I'm not implying jsdom needs to eval the expressions. I'm just saying it should allow for parentheses within
calc()expressions and return the expression, not an empty string as though the specified value was invalid. The CSS spec does allow for parentheses: https://www.w3.org/TR/css-values-3/#calc-syntaxI did a bit of digging and I think the problem may lie deeper here: https://github.com/rrweb-io/CSSOM/blob/402a2c7a813890c6c116244827f200cd6c04f0bb/lib/CSSValueExpression.js#L36 But that repo doesn't allow filing issues so I figured I would report this here.