Re: [csswg-drafts] [css-anchor-position] Nailing down the position-try-options "flip" behavior (#10049)

> Anders suggests leaving the values untransformed

I did initially, but I didn't think about the need to transform things other than anchor functions. That makes it a bit more annoying: while anchor functions are resolved computed-value time (saving the rest of the system from having to care about the flip), the same can not be said for `align-self`, etc. Still _possible_ to do of course, but I'm less enthusiastic about this idea now.

> The timing of precisely what value we're getting

This may vary between browsers, but at least in Blink this should be entirely unproblematic. In my opinion, we can just spec the flip as taking place on "the specified value with var()/env()/etc resolved", or invent a new value stage to represent that.

Note that reverts and substitution/computed-value-time are already required to "cooperate", due to how `foo:var(--unknown, revert)` [works](https://drafts.csswg.org/css-variables/#:~:text=as%20if%20that%20keyword%20were%20its%20specified%20value%20all%20along) when the fallback is taken. (I'm not sure if this helps, or makes it worse, or something in between).

> but still before style/layout interleaving

I don't think we have to handle that? The specified value has the `anchor()` function (at least post-substitution). The computed value does not. If we describe it in terms of value stages, we can ignore interleaving.

-- 
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10049#issuecomment-1986596251 using your GitHub account


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

Received on Saturday, 9 March 2024 00:25:18 UTC