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

jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-anchor-position] Clarification: effect of `position-try-fallbacks` and `position-try-order` when the positioned box does not overflow ==
The spec for [`position-try-fallbacks`](https://drafts.csswg.org/css-anchor-position-1/#position-try-fallbacks) says that this property provides

> alternate positioning styles to try _when the [absolutely positioned box](https://drafts.csswg.org/css-position-3/#absolute-position) overflows its [inset-modified containing block](https://drafts.csswg.org/css-position-3/#inset-modified-containing-block)_

(my emphasis) which implies that if the positioned box does **not** overflow its IMCB, the fallbacks listed will not be used.

The [`position-try-order`](https://drafts.csswg.org/css-anchor-position-1/#position-try-order-property) property extends this feature by providing control over the order in which the fallbacks are tried (other than simply "as listed").

I note that the [**position options list**](https://drafts.csswg.org/css-anchor-position-1/#position-options-list) that `position-try-order` potentially re-sorts includes the positioned box's original "base" position as well as the fallback positions from the try-fallbacks list. _However_, if the positioned box did not overflow its IMCB, there is no reason to (construct or) use this position options list at all, because the basic condition for using `position-try-fallbacks` ("when the absolutely positioned box overflows...") is not met.

I'm bringing this up because while this is my understanding of the properties described in the spec, it does not match the behavior I currently see in Chrome. The testcase at https://codepen.io/jfkthame/pen/raLaBbx has an anchored element that fits comfortably (without overflow) in its IMCB at `position-area: top left`. The checkbox allows additional properties `position-try-fallbacks` and `position-try-order` to be applied to it (and changes the color to red). By my reading of the spec, this should **not** cause the anchored element to move, because it didn't overflow and therefore `position-try-fallbacks` is not relevant. But in Chrome, the `flip-block flip-inline` fallback gets used, and the element jumps to the bottom right area. It looks like Chrome is using the sorted position options list _even though no fallback was required_.

Is this the expected result? It doesn't seem to me that it follows from the property descriptions in the spec. But there's a [WPT reftest](https://wpt.live/css/css-anchor-position/position-try-order-logical.html) whose reference currently assumes the Chrome behavior.

I'd argue that the Chrome behavior is a bug (or misunderstanding of the spec), and the position-try-order-logical test is bogus, but I'd like to know whether the WG agrees, or if my interpretation is at fault here.

@fantasai I notice that Safari does _not_ share Chrome's (questionable) behavior on this example; does this mean your understanding here matches mine?

(Also tagging @emilio to add anything I've forgotten.)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13268 using your GitHub account


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

Received on Thursday, 25 December 2025 15:18:40 UTC