Bug 278852 – CSS rounding functions behaves differently in Safari than other browsers

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[Kira]

Created attachment 472343 [details]
Screenshot comparing different behavior in Chrome and Safari

Expected behavior:
CSS functions round(), rem(), mod() take css variables and calculate values dynamically.

Actual behavior:
Calculation fails, value is not applied to the CSS property.

Example:
https://codepen.io/chipa014/pen/vYqarRP
Expected behavior:
Pink div is translated to the right (Screenshot upper half, Chrome).
Actual behavior:
Pink div is not translated, staying in the corner (Screenshot lower half, Safari).

[Karl Dubost]

Created attachment 472437 [details]
rendering in safari, firefox, chrome

Is that fixed?

Tested on 

Safari Technology Preview  202           20620.1.4.8
Firefox Nightly            131.0a1       13124.8.29
Google Chrome Canary       130.0.6696.0  6696.0

[Karl Dubost]

@Kira on which versions of Safari did you test?

[Kira]

(In reply to Karl Dubost from comment #2)
> @Kira on which versions of Safari did you test?

I managed to track it down to this:

round() function takes optional third argument. In Safari it is not optional, therefore resulting in such behavior.

Adding the third argument resolves the issue, but whether no default value is intended behavior or not beats me.

[Kira]

For preservation reasons I've reverted my codepen to non-working state, leaving the solution commented.

[Karl Dubost]

Created attachment 472452 [details]
testcase

The codepen is with the working case. 
https://codepen.io/chipa014/pen/vYqarRP

Let's create a local testcase where the behavior is different. :) 

aka   translate: calc(100px * round(var(--offset) / 2));

[Karl Dubost]

Created attachment 472453 [details]
rendering in safari, firefox, chrome for testcase

We can see the difference now.

[Karl Dubost]

Tested in 
Safari Technology Preview  202           20620.1.4.8
Firefox Nightly            132.0a1       13224.9.4
Google Chrome Canary       130.0.6698.0  6698.0

[Karl Dubost]

For reference The current specification 
https://drafts.csswg.org/css-values/#funcdef-round

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.


one thing I want to rap around my head is what value do you expect from 

round(var(--offset) / 2))

Maybe we should reason with something different than 1 or 0.

[Karl Dubost]

Created attachment 472454 [details]
testcase with more cases

OK this is not related to variables. :) 
This is related to the way rounding is done.

[Karl Dubost]

Created attachment 472455 [details]
rendering in safari, firefox, chrome for testcase with more cases

Here you can see it's independent of the variable. I will retitle the bug,
maybe there is even already a bug for this.

[Radar WebKit Bug Importer]

<rdar://problem/135307851>

[Karl Dubost]

This is 
https://wpt.fyi/results/css/css-values/round-function.html?label=master&label=experimental&aligned&q=round%20safari%3Afail

[Ahmad Saleem]

Created attachment 472456 [details]
WebKit ToT Screeenshot

[Ahmad Saleem]

(In reply to Karl Dubost from comment #12)
> This is 
> https://wpt.fyi/results/css/css-values/round-function.
> html?label=master&label=experimental&aligned&q=round%20safari%3Afail

WebKit ToT passes all of these tests as well.

[Karl Dubost]

OK Good news. Thanks Ahmad.
This was fixed by
https://github.com/WebKit/WebKit/commit/e6902e0483c51982df75abe81235860eae084e35