[csswg-drafts] [css-values] Consider requiring same <length> units in atan2() (#8169)

emilio has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-values] Consider requiring same <length> units in atan2() ==
Consider `atan2(10em, 13vh)`. Should that work? Per spec, it should because the two units are `<length>`s, and [the spec](https://drafts.csswg.org/css-values-4/#trig-funcs) says:

> The atan2(A, B) function contains two comma-separated [calculations](https://drafts.csswg.org/css-values-4/#calc-calculation), A and B. A and B can resolve to any [<number>](https://drafts.csswg.org/css-values-4/#number-value), [<dimension>](https://drafts.csswg.org/css-values-4/#typedef-dimension), or [<percentage>](https://drafts.csswg.org/css-values-4/#percentage-value), but must have the same [type](https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation), or else the function is invalid.

If we allow different units, we can't resolve `atan()` at parse-time (because it starts depending on resolving those `<length>`s to pixels. That introduces a new set of property dependencies which didn't exist before. For example, we'd need to define how ex/etc units resolve on `font-weight`, since `font-weight` can affect the primary font, and with this you could do `font-weight: atan2(2ex, 10px)`.

My implementation in Firefox doesn't allow mixed relative units in `atan2()` (because I misread the spec). This is also problematic for Chromium implementation-wise (even without all these new dependency shenanigans).

Unless this is extremely useful, it might be worth restricting relative lengths to enforce same-unit-ness.

cc: @tabatkins @devsdk @dbaron

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8169 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 1 December 2022 22:43:32 UTC