Description
In the minutes of the CSSWG discussion, @emilio brought up that handling fallback completely and correctly can require a decent amount of code, but in most cases the desired fallback behavior is very simple and straightforward. He suggests having a more declarative version of the fallback specification, which will let authors get this "basic" position fallback without having to think thru a lot of cases (or copy-paste from a good example).
This sounds reasonable to me. The current API is intentionally somewhat low-level because, as Ian said in the discussion, there are a lot of cases that want the complexity. But it's also true that a large fraction, possibly a majority, of cases want a very simple behavior that can be described in a common fashion.
Here's my suggestion: we add a auto side keyword to anchor(): anchor(--foo auto). This only works if the opposite property in the axis is auto (so the positioning is guaranteed to not have an effect on the element's size); if this isn't true it resolves to 0.
By default, it positions the specified edge of the element against the opposite edge of the anchor; top: anchor(--foo auto) puts your top edge against the bottom edge of the --foo anchor. It automatically falls back to the opposite set of edges (for both elements) if it needs to. (This doesn't change what property it's affecting - in the preceding example it would resolve top to a value that happens to place the element's bottom edge against the anchor's top edge, so 'transition: top 1s` still works to make it non-abrupt.) This applies to each axis independently; the other axis can also be auto-anchored, against the same or a different element, or be a fixed value or a non-auto anchor, whatever.
This would resolve the "lots of small popups, all need a separate @position-fallback rule" problem.
Emilio also mentioned a "sticky"-like behavior, where the element defaults to sticking to an edge like above, but if it would slightly overflow it just slides enough to avoid that, rather than flipping. We could do this as well with a sticky keyword that's subject to the same constraints as auto. I'm curious exactly what the constraints of this are, tho - does it stop sliding when the opposite edges are aligned? This would occur when the anchor is just about to slip off-screen entirely - is that what's desired?
Interaction between these and position-fallback need to be defined. Maybe we consider these as effectively a first fallback entry, and then use the actual position-fallback only if they still overflow in either position?