242629 2022-07-11 19:54:00 -0700 atan2 calc() function behaves incorrectly with different units 2024-11-10 20:40:22 -0800 1 1 1 Unclassified WebKit CSS Safari 15 Unspecified Unspecified RESOLVED DUPLICATE 278244 GoodFirstBug, InRadar P2 Normal --- 1 govett webkit-unassigned 50167214 ahmad.saleem792 ap bfulgham karlcow koivisto nmouchtaris ntim simon.fraser webkit-bug-importer zalan oldest_to_newest 1882323 0 govett 2022-07-11 19:54:00 -0700 The atan2 function in CSS accepts dimensions, percentages, or numbers as inputs as long as the two arguments have the same type. However, the matching type doesn't mean the values are of the same units. As discussed in https://github.com/w3c/csswg-drafts/issues/7482, WebKit's current implementation behaves incorrectly when the units differ. For example, currently the following behave identically: ``` rotate: atan2(90px, 90px); rotate: atan2(90px, 90vw); ``` However, `90vw` should be resolved at computed value time and used rather than ignoring the unit completely. The same is true for examples like the following, where a computation includes incompatible units: ``` rotate: atan2(90px, 10px + 10vw); ``` Currently, WebKit ignores the 10vw completely here, and behaves the same as atan2(90px, 10px). The computation should be resolved and the result should be based on whatever 10px + 10vw computes to. The current tests in web platform tests don't include any examples of differing units, but probably should. Here's a codepen where you can see how WebKit currently renders some examples. https://codepen.io/devongovett/pen/GRxqNYj 1884999 1 webkit-bug-importer 2022-07-18 19:54:55 -0700 <rdar://problem/97235085> 1894363 2 ahmad.saleem792 2022-08-28 18:51:03 -0700 All three browsers differ in the attached test case (CodePen) from Comment 0. *** Safari Technology Preview 152 on macOS 12.5.1 *** Two Tilted red square first then in the last square *** Chrome Canary 107 *** Three red square *** Firefox Nightly 106 *** Titled red square and then simple square and then again tiled red square. ______ Just wanted to share updated results. Thanks! 1970284 3 ahmad.saleem792 2023-08-09 05:43:11 -0700 Chrome Canary 117 and WebKit ToT (266719@main) seems to match each other while Firefox Nightly 118 is different from other. Do we need to do anything here? CCing @Tim - since he fixed similar bugs recently. 1983583 4 ntim 2023-10-08 10:45:22 -0700 (In reply to Ahmad Saleem from comment #3) > Chrome Canary 117 and WebKit ToT (266719@main) seems to match each other > while Firefox Nightly 118 is different from other. > > Do we need to do anything here? CCing @Tim - since he fixed similar bugs > recently. WebKit & Chrome still have an incorrect result here, since the first 2 squares are identical (first one uses 90px, second uses 90vw). They should defer computation to computed-value time. Arguably Firefox is slightly more correct here by rejecting the computation altogether (instead of computing to something incorrect), but that's not what the spec wants. 2061853 5 ntim 2024-09-20 09:06:36 -0700 *** This bug has been marked as a duplicate of bug 278244 *** 2074197 6 50167214 2024-11-10 20:32:05 -0800 Looks like Chrome 132 is wrong in the second test case? It seems to resolve to `atan2(5px, 5px)`. ```css #b { rotate: atan2(5px, 5vw); } ``` 2074199 7 karlcow 2024-11-10 20:40:22 -0800 Also relevant https://github.com/w3c/csswg-drafts/issues/8169