attr() declaration with type function breaks parsing
To reproduce:
img {
aspect-ratio: attr(width type(<number>)) / attr(height type(<number>));
}
Current behavior:
An exception: "Could not parse call arguments or missing ')'" is thrown.
Expected behavior:
img {
aspect-ratio: attr(width type(<number>)) / attr(height type(<number>));
}
should be rendered
Environment information:
lessversion: 4.2.2nodejsversion: 22.17.0operating system: macos
Hi @janschoenherr! I'm Dosu and I’m helping the less.js team.
Less v4.2.2 doesn't support parsing the CSS attr() function with type arguments like attr(width type(<number>)), which is why you see the "Could not parse call arguments or missing ')'" error. The parser expects function arguments to follow a specific grammar and doesn't recognize the type argument syntax used in modern CSS, so it fails to parse and throws an error see parser code.
Recent updates (e.g., v4.4.2) have fixed some CSS function parsing regressions, but there's no indication that support for attr() with type arguments has been added see PR #4364. There isn't any documentation or discussion about workarounds for this limitation.
For now, Less can't output this syntax as-is. If you need to use it, you may need to avoid preprocessing these lines with Less or use a post-processing step to inject the desired CSS.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
Thank you for the bug report @janschoenherr
I'll try to experiment this weekend and see if I can come up with a solution.
Hi @janschoenherr I have been reviewed the bug and I also earlier encountered the same bug :
`img {
aspect-ratio: attr(width type(<number>)) / attr(height type(<number>));
}`
To fix this try ~" " by wrapping the expression in :
`~"img{
aspect-ratio: attr(width type(<number>)) / attr(height type(<number>));
}"`
this will tell less to treat as raw CSS. and The compiler will no longer throw Could not parse call arguments or missing ')' error The resulting CSS works as expected in all modern browsers.
Hi @rohan45327,
thanks, that's what we currently do with uikit. It would still be nice, if we wouldn't have to use the workaround.
@janschoenherr Can you link to the spec where type(<number>) (specifically <number>) is now a valid value?
@matthew-dean This is still in draft: https://drafts.csswg.org/css-values-5/#attr-notation
Currently only Chrome supports it. I understand, if you want to delay supporting it until the spec is final.
https://wpt.fyi/results/css/css-values/attr-all-types.html?label=experimental&label=master&aligned&q=attr-all-types