- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Nov 2023 10:21:44 +0000
- To: public-css-archive@w3.org
Since my previous post raised some questions yesterday (elsewhere), I'll add a more detailed explanation, and some more thoughts on this. --- Container relative units (`cq*`) resolve at computed-value time, even though they require layout information to resolve. Example: ``` <style> #container { container: --c / size; width: 100px; height: 80px; } #target { width: 50cqw; } </style> <body> <div id=container> <div id=mid> <div id=target> </div> </div> </div> </body> ``` During the regular style recalc process, after computing the style for `#container` and figuring out that it's a size container, we _skip_ computing the style for `#container`'s descendants. So during this process, "computed-value time" has happened for `#container`, but not for `#mid` nor for `#target`. Then, when _layout_ reaches `#container`, we immediately _resume_ style recalc for `#container`'s descendants. Now armed with the knowledge of `#container`'s actual size, we're able to resolve (compute) `cq*` units into what they're supposed to be. So for `#container`'s descendants, "computed-value time" happens _during_ layout. (Hence the term "interleaved style and layout" which you may or may not have encountered). --- The above works, because at the time we finally end up resolving `cq*`, we know the size of the container. (And thanks to containment, we also know that it's not going to move around). The same _appears_ to be true for `anchor()`, since we have the requirement that the layout of the anchor must be understood _first_. However, the mental model doesn't quite work out for `anchor()`, because there's no ancestral "container" which marks the interleaving point. In order to detect that `anchor()` is used on some element, "computed-value time" would need to already have happened, and then we'd need to have a second round of "computed-value time"? It's (even) less "clean" than container queries. The new path we're on for @position-fallback also requires the same uncleanliness: we must know the computed value of `position-fallback` before attempting the associated `@try` styles to eventually figure out the _real_ computed style. Doing multiple rounds isn't a problem for the implemenation, but figuring out a decent mental model (spec) for this might require some thought ... -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8181#issuecomment-1812178370 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 November 2023 10:21:46 UTC