[css-anchor-position] Clarification: effect of `position-try-fallbacks` and `position-try-order` when the positioned box does not overflow

[jfkthame]

The spec for position-try-fallbacks says that this property provides

alternate positioning styles to try when the absolutely positioned box overflows its 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 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 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 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.)

[dshin-moz]

But if we consider everything and sort it on overflow only, we may end up being more "stateful?" e.g.:

1. The base style fits initially
2. Scroller moves so that the positioned element overflows - we find a fallback that fits, --a
3. Scroller moves to initial position, --a overflows. Now we consider position options list, which includes the base style, as well as fallbacks. The base style will fit, but so will another fallback, --b, with a bigger IMCB, so we end up picking it.

Here's a testcase that I think would exercise this - Chrome seems to always sort everything, Safari seems to always consider base style first before looking at the sorted fallbacks (Maybe)?

[jfkthame]

Some statefulness is inherent in position-try-fallbacks anyhow, because of the last-successful-position stuff, even without considering position-try-order and re-sorting the position options (e.g. https://codepen.io/jfkthame/pen/yyJyYxg).