Re: [csswg-drafts] [css-anchor-position][other] Handling popover default styles (#10258)

> Option 0 (North star): New `<condition>` value for checking whether any property has a value

This isn't a north star; it's an anti-pattern that we can't do, and don't *generally* want to aim towards for any other features, either. When we do, it's only in carefully chosen one-offs, like `light-dark()`.

As I said in the chat (and you summarized here), having a function or condition or whatever that resolves differently based on the style of an element means that wherever you use it, you're now introducing a *dependency* on the properties that determine that style. 

We have several examples of this in CSS already: the `em` unit (depends on `font-size`), the `lh` unit (depends on `line-height`), the `light-dark()` function (depends on `color-scheme`). All of these can be used nearly anywhere, and impose this sort of dependency; as a result, we have to carefully design things sometimes to avoid issues with cyclicity. The complexity also compounds; adding `lh` introduced more complexity than `em` originally involved, because they can interact with each other. We've documented the problems with this more generically in <http://wiki.csswg.org/faq#selectors-that-depend-on-layout>.

Adding more of these can only be done with care. Even the `if(color-scheme(): ...)` condition is going to involve more complexity than `light-dark()`, for the reasons outlined in the wiki. It's probably *fine*, because `color-scheme` is very much a "terminal" property that will never depend on anything, but this still represents a restriction on future CSS development. (We can, luckily, do the "detect if dependencies actually exist at runtime" thing the wiki talks about when resolving substitution functions; otherwise this would be impossible to add!)

Is an "is anchored" test similarly "terminal"? I don't think so. For one, `position-area` depends on, and is depended on, by several layout properties already. For two, I think "is anchored" needs to be more complex than just referring to `position-area`; I just opened #12552 to talk about this. (Completely unrelated to today's discussion, in fact! Ian and I discussed this yesterday.) This means there's a wide range of core layout properties that this test would depend on, and these participate in a complex web of property dependencies that stretches across quite a lot of CSS. I don't think we can reasonably define a test for this, both finding all the dependencies *now* and keeping the list up to date in the *future*; this also restricts out ability to introduce *new* dependencies between *existing* properties in ways that I don't want to bind us. And that's just the spec side of things; making the set of restrictions understandable for *authors* would be, I fear, impossible, especially as many of the places you would *want* to change based on anchoring are precisely the things that would be ruled out due to dependency cycles.

So, this rules out all of your options. It's just not something we can do in any meaningfully generic fashion. We can only depend on "being anchored" in very specific, tightly-controlled, predetermined ways in the spec, where we can layer the dependencies and resolve conflicts explicitly.

----------

Defining a *container query* that determines if an *ancestor* is using anchoring is, of course, a totally different story. We should feel free to discuss that in a different issue.

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


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

Received on Thursday, 31 July 2025 03:34:36 UTC