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
<rdar://problem/97235085>
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!
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.
(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.