[css-values-4] What is the unit of `round(A, B)` if `A` and `B` have different units?

[mkrause]

In the expression round(2rem, 1px), what would be the unit of the resulting length? Is it even defined?

Here are some test cases: https://codepen.io/maikelkrause/pen/yyBxJPg

The codepen above gives different results (for test case 2 and 3) in all three major browsers. (Note: I assumed that Chrome's implementation is the correct one so those are marked as "passing", but this is what I want to double check in this issue.) It uses tan(atan2()) to extract the scalar part of a dimensional value.

• Chrome 139: (1) 32px, (2) 32px, (3) 32px
• Firefox 142: (1) 31.9999px, (2) 31.9999px, (3) 0px
• Safari 18.6: (1) 32px, (2) 0.250549px, (3) 0.250549px

From the spec:

The round(<rounding-strategy>?, A, B?) function contains an optional rounding strategy, and two calculations A and B, and returns the value of A, rounded according to the rounding strategy, to the nearest integer multiple of B either above or below A. The argument calculations can resolve to any <number>, <dimension>, or <percentage>, but must have a consistent type or else the function is invalid; the result’s type will be the consistent type.

If A is exactly equal to an integer multiple of B, round() resolves to A exactly

The spec mentions that the result may be (1) the nearest integer multiple of B (implies the unit of B?), or (2) A exactly (implies the unit of A?).

(This may be related to #7482.)

[Loirooriol]

You can only resolve round(2rem, 1px) at computed value time. And a length is absolutized at computed value time, so the unit doesn't matter.

Question: what is the expected unit of round() if given two different units? Here: 32px since it rounds to the px? Or 2rem (assuming 2rem matches a whole number of pixels)?
round(2rem, 1px)

You seen to assume 1rem = 16px. In that case,

• round(2rem, 1px) = round(32px, 1px) = 32px
• round(2rem, 1px) = round(2rem, 1rem / 16) = 2rem
• And indeed, 32px = 2rem. Not sure why you think they are different.

BTW, you get zero in Firefox because the value isn't accepted by the parser, so it's not a resolution problem.

[mkrause]

@Loirooriol Thanks. So my confusion here was actually due to me missing that tan(atan2(A, B)) performs a unit conversion if the arguments are different units, meaning it doesn't matter if you do tan(atan2(2rem, 1px)) or tan(atan2(32px, 1px)) (yes assuming that 1rem ~ 16px), both will be 32. I assumed for some reason that this would ignore the units and evaluate to 2 and 32 respectively.

The reason for the inconsistent browser results in my codepen above is actually due to Firefox and Safari not handling tan(atan2()) with different units if you don't use @property, with Firefox just returning 0 in that case and Safari doing something weird that I don't quite the logic for (tan(atan2(2rem, 1px)) somehow ends up as 0.250549?).

Here is another codepen that makes it clearer: https://codepen.io/maikelkrause/pen/gbaBBdY

In this codepen, I added @property declarations and now everything works fine in all browsers (apart from Firefox's rounding error). The need for @property is also mentioned in this article. If you remove the @property declarations then you'll see the behavior from my original codepen.

Will close this issue.

[Loirooriol]

with Firefox just returning 0

It's not really that the expression resolves to zero. In Firefox it's just a parse error, so the entire value is dropped. Or when using variables, you get invalid at computed value time. 0 is just the initial value that you then get as a fallback.

CSS.supports("rotate: atan2(2rem, 1px)") // false in Firefox, true in Chrome.

For the rounding error, note that the precision of numeric values is implementation-defined. And it's not surprising to see it when doing some back and forth with trigonometric functions. Ideally you should just use "unit algebra" like 2rem / 1px without trigonometric hacks, but browsers don't support this yet.

[mkrause]

Thanks @Loirooriol for the clarifications