Yeah, I think this is pretty important - for example, atan2(10vw, 10vh) makes complete sense to me.

But more importantly, this isn't an atan2()-specific issue; it applies to everything taking a calculation. font-weight: calc(2ex / 10px), for example, introduces the exact same problem. So I'm strongly against any atan2()-targeted change here; if we want to disallow this we need to instead apply some more powerful restriction to all calculations.

Not sure if I follow, is the "primary font" the same as the "first available font"? Then, what about font-weight: 2ex without calculations, the 2ex resolves depending on the "first available font", which depends on font-weight?

We can't plug relative length units into font-weight without calculations, because font-weight takes number values only.

I think we can just use the same idea how we resolve font-size: 1ex: when a font-relative length unit is used in a font-related property, it refers to the the parent element's font.

Ah, sure, time to go to sleep I guess XD. But I think this would also need to address custom properties registered as <integer> or <number> (https://drafts.css-houdini.org/css-properties-values-api/#dependency-cycles):

--foo: calc(2ex / 10px);
font-weight: var(--foo);

Also:

line-height: 1ex;
font-weight: calc(1lh / 1px);

So, generalizing #2115, I guess the idea would be:

1. Compute font-size, resolving unknown font units with the parent. This sets the em unit.
2. Compute font-weight, resolving unknown font units with the parent. This sets the ex, cap, ch and ic units.
3. Compute line-height, resolving unknown font units with the parent. This sets the lh unit.

Or:

1. Compute font-weight, resolving unknown font units with the parent.
2. Compute font-size, resolving unknown font units with the parent. This sets the em, ex, cap, ch and ic units.
3. Compute line-height, resolving unknown font units with the parent. This sets the lh unit.

Retagging to values-4 since values-3 doesn't have atan2 nor unit algebra.

font-style needs to also be special cased along with font-weight at least, since you would be allowed to set a slant anglebased on any unit. Probably others as well.

font-stretch too I guess. https://drafts.csswg.org/css-fonts-4/#font-prop-desc

All of this seems problematic:

font-weight: calc(1ex / 1px);
font-style: calc(1ex / 1px * 1deg);
font-stretch: calc(1ex / 1px * 1%);
font-variation-settings: "wght" calc(1ex / 1px);
font-feature-settings: "subs" calc(1ex / 1px);
font-size-adjust: ex-height calc(1ex / 1px);

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

In this case the units would be useless because atan2(X, Y) = atan2(Xunit, Yunit):

rotate: atan2(12, 7)     /* = 1.04272rad */
rotate: atan2(12%, 7%)   /* = 1.04272rad */
rotate: atan2(12em, 7em) /* = 1.04272rad */
rotate: atan2(12vw, 7vw) /* = 1.04272rad */
rotate: atan2(12ms, 7ms) /* = 1.04272rad */
...

possible duplicate of 7482

Nah, #7482 was a question about what the behavior was. This is an issue asking if we should change the behavior.

Related: what if we use them in animation properties? For example

.test {
  animation-duration: calc(sin(atan2(1em, 20px)) * 1s);
  animation-name: anim;
}

@keyframes anim {
  from { font-size: 10px; }
  to { font-size: 30px; }
}

Do they need the same "animation-tainted" treatment as in custom properties?

sign() has the same issue.

Yes, as I said in my earlier comment, it applies to every function taking a calculation, including calc() itself. This is a generic consequence of unit algebra letting you use units in the input that don't appear in the output - calc(1ex / 1em) trips the exact same issue.

So this issue is moot; there is no meaningful restriction we can place on these functions that would actually solve the problem. This should be brought up as a question of what precisely the consequences are of using a unit in a math function in these funky cases.

@Loirooriol

I'm trying to understand given example why has circular dependency:

line-height: 1ex;
font-weight: calc(1lh / 1px);

Can I ask the spec references that the font-weight affects x-height?

@DevSDK any font which affects the primary font selection can change the first available font, which at least in theory can affects font metrics, including x-height...

The CSS Working Group just discussed [css-values] Consider requiring same relative <length> units in atan2(), and agreed to the following:

• RESOLVED: font-relative units resolve against the parent element when used in any font-* property (and anything else that affects font selection)
• RESOLVED: Do something similar for line-height (details TBD)

ACTION TabAtkins: Figure out what to do on custom properties typed as lengths

The problem is not just for custom properties registered as lengths, see w3c/css-houdini-drafts#1080

Mild concern with the resolution: this creates an inconsistency with #2115, i.e.

font-size: 2lh; /* resolves using the parent */
line-height: 3em; /* resolves using the current element */

font-size: 2ex; /* resolves using the parent */
font-weight: calc(3em / 1px); /* resolves using the parent */

Since font-size always resolves font-relative units with the parent, it should be possible to resolve em with the current element both for line-height and font-sizefont-weight, so why do different things?

@Loirooriol (I assume you mean font-weigh in your last sentence.) It would be really bad if, in font-weight, 3em resolved against the element itself but 3ex resolved against the parent. Since font-weight can affect the calculation of ex, ex has to resolve against the parent.

@fantasai Why would resolving em and ex against different elements be really bad, but resolving em and lh against different elements is fine? Should all units resolve against the parent when there is a cycle?

We can't change the behavior of line-height: 1em; in general (it uses current-element ems), and special-casing it to change behavior if and only if font-size was in lh is a difficult-to-predict, action-at-a-distance sort of thing that we generally want to avoid. But we have to break the cycle somehow, so having font-size: 1lh; always resolve against the parent was the most reasonable thing to do.

Digging in a little deeper, tho, while line-height and font-size usually establish a dependency, they're not semantically connected - the font size and the height of a line don't readily appear to be different aspect of the same concept, at least imo. It's thus more acceptable to have them differ on which element they refer to, in these cases.

On the other hand, em and ex (and all the other explicitly font-based units) are conceptually related; they're all sizing according to some text, and it's not uncommon for them to be used in parallel fashions. Having them differ on what element they refer to would make the grouping conceptually incoherent.

The ability to convert between different units in atan2() is very useful, E.g. we can now do a pure CSS real-time display of the container width(px).

Demo: https://codepen.io/xboxyan/pen/MWZLYZz