Re: [csswg-drafts] [css-anchor-position] Clarification: effect of `position-try-fallbacks` and `position-try-order` when the positioned box does not overflow (#13268)

The CSS Working Group just discussed ``[css-anchor-position] Clarification: effect of `position-try-fallbacks` and `position-try-order` when the positioned box does not overflow``, and agreed to the following:

* `RESOLVED: Use all positions for position-try-order, including base styles`
* `ACTION: Clarify the spec`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> TabAtkins: so... probably due to some historical effects it was not clear to jonathan whether `position-try-order` which reorder your fallback sets reorders the base styles as part of that set or just the fallback styles<br>
&lt;emilio> ... the intention of the spec was that your base styles is just one of your sets of styles<br>
&lt;emilio> ... so position-try-order: most-size will potentially trigger fallback if a fallback has more space<br>
&lt;emilio> ... seemed to be fine for jfkthame and elika<br>
&lt;kizu> q+<br>
&lt;emilio> ... so unless anyone has an opinion we can close<br>
&lt;emilio> kizu: no complain, I think it's nice to have this<br>
&lt;astearns> s/most-size/try-size/<br>
&lt;emilio> ... several use cases where you want to choose the biggest area<br>
&lt;emilio> ... what they do is making the base positioning overflow<br>
&lt;emilio> ... maybe there's even use case for removing the base styles and only use the fallback options?<br>
&lt;emilio> ... maybe there's a way to include this?<br>
&lt;emilio> q+<br>
&lt;Rossen> ack kizu<br>
&lt;emilio> TabAtkins: not part of this issue, but forcing the base styles to overflow makes this possible<br>
&lt;emilio> kizu: right but then you can't reorder<br>
&lt;emilio> ... you can't give priority to one of the options in the list<br>
&lt;Rossen> ack emilio<br>
&lt;emilio> ... you can't say "this is the first one" and then sort the rest<br>
&lt;fantasai> emilio: oriignal version, if base style doesn't overflow don't use fallbacks?<br>
&lt;fantasai> emilio: Gives you what kizu wants, have a priority style and then reorder the rest<br>
&lt;fantasai> emilio: That said I don't mind<br>
&lt;fantasai> emilio: Nice to not have to try the fallbacks<br>
&lt;iank_> q+<br>
&lt;emilio> TabAtkins: agreed there are reasons to go either way<br>
&lt;fantasai> TabAtkins: There are reasons to do either way, but when you are reordering for largest space, I feel like that use case lends you more towards checking all the styles rather than starting with a preferred style<br>
&lt;fantasai> TabAtkins: but could add that in the future<br>
&lt;Rossen> ack fantasai<br>
&lt;Rossen> ack iank_<br>
&lt;emilio> fantasai: I was going to say that if there are use cases for both we could have keywords to reorder all of them or just some<br>
&lt;emilio> iank_: most-block-size isn't useful if you don't consider all of the styles<br>
&lt;emilio> ... very unintuitive if you need to make the first one overflow<br>
&lt;emilio> ... separate keyword for that seems fine<br>
&lt;emilio> emilio: fair<br>
&lt;emilio> PROPOSED: Use all positions for position-try-order, including base styles<br>
&lt;iank_> (would only want to add the additional switch if we have a strong use-case)<br>
&lt;emilio> RESOLVED: Use all positions for position-try-order, including base styles<br>
&lt;fantasai> ACTION: Clarify the spec<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13268#issuecomment-4180719910 using your GitHub account


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

Received on Thursday, 2 April 2026 22:01:40 UTC