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

As I said in the call today, I think this is *extremely* overfit to this particular problem and while I'm 100% in favor of solving the problem, I feel (quite strongly) that this is not the right solution.

`dialog` (or whatever we call it) is basically a conditional value that hardcodes three things:
1. the condition we're branching off of
2. the properties that can vary based on 1
3. the values applied for each branch of the condition, 

These three things are coupled together in a way that can neither be customized, nor repurposed.

I can _easily_ see us later wanting to branch off different styles based on this, or even authors (e.g. a generic CSS stylesheet may also want to set different container styling defaults for "anchorless" vs anchored popovers).

Additionally, concerns were expressed around whether this would be even web compatible to change in the UA stylesheet. The popover API is already used in [55% of Chrome pageloads](https://webstatus.dev/features/popover). Of course, this change would not affect all of them, but even a conservative estimate that it would affect 1%, that's still 0.55%, which is way too high.

If we can't change it in the UA stylesheet, it becomes even more important to have a customizable, architecturally sound solution that authors can use in their own reset stylesheets etc.

## Alternative proposals

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

**I’m not seriously proposing this**, but [I think](https://lea.verou.me/blog/2025/hovercar/) it can be a useful consensus-building tool to make sure we're aligned on what the north star syntax would be, if we didn't have the technical constraints we have, before considering what compromises to make.

I wonder if we have consensus that if cycles were not an issue, the ideal solution would be something like:

```css
margin: has-value(position-area, 0, auto);
```

This decouples everything, nothing is a hardcoded black box any longer, and solves a ton of other existing use cases.

Of course, we can't do this for a variety of reasons, but if anyone objects that this would be the north star, it would be useful to know.

### Option 1: New `<condition>` value that hardcodes the proposed condition

Strawman: Introduce a new `<condition>` value that only hardcodes the condition, and can be used (via `if()` and possibly `@container`) in any property, to branch off between any two values.

```css
margin: if(is-anchored(): 0; else: auto);
```

If we can find a way to pull this off, I think that _almost_ north star. Even if the condition _itself_ is overfit, at least it solves the main issues I see of needing to vary other properties or values based on this, so I think it's a far better solution architecturally.

And with the right naming, it can be extended down the line to become _infinitely_ more useful, by taking arguments that query the current position-area (e.g. `is-anchored(block-start)`).

@tabatkins said that even with `if()`'s IACVT behavior, we don't want to introduce a dependency between potentially any property and `position-area`. I’m hoping we can look into this a little before deciding it's a no-go. Remember the proposed condition is just "is `position-area` `initial` or _any_ other value?". I think the potential of nontrivial-to-detect cycles even down the line is exceedingly small and there is precedent for introducing such dependencies.

Worst case, I wonder if we can simply not add it to `@container` and define that any `if()` with this condition is automatically IACVT when used in certain properties. While not great, at least it allows us to drop that restriction down the line, rather than be stuck with a black box keyword forever. If the initial whitelist is `margin` the complexity of cycle detection is identical to this proposal, except there is some light at the end of the API tunnel. 😅

### Option 2: New conditional function, à la `light-dark()`

If we absolutely cannot do this via `if()`, another solution could be to have a dedicated conditional function that can only be used in `margin` at first, but can later be expanded to more properties without adding new API surface or even extended to query the current positioning, as described above.

Needs bikeshedding but perhaps a typed function like `is-anchored( <calc-sum>){2} )` or even a substitution function like `is-anchored(<declaration-value>{1,2})`.

The typed version at least provides a user-facing benefit over `if()`, but since `auto` is not a valid `<calc-sum>` it would need to be `calc-size(auto)` which is …yikes. Unless we can do some spec magic and define that `auto` is automatically wrapped in `calc-size()` inside this function.

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


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

Received on Wednesday, 30 July 2025 17:57:23 UTC