[css-anchor-position-1] Do we need area-list fallback position syntax?

[xiaochengh]

(This is a sub-topic from the feature comparison issue)

The grid-based proposal has a list based fallback syntax, for example:

.target {
  position-area: top / all, bottom / all, left / all, right / all;
}

The current spec doesn't have anything similar, but will have auto position fallback that allows automatically generating a list of fallback styles from a base style. See #9196 (comment)

I'm opening this issue to gather opinions on whether the auto position fallback syntax is enough for simple cases, or do we still need a list-based syntax to close the gap.

[tabatkins]

As I mentioned in the breakout, right now the spec has two types of fallback behavior:

1. Fairly simple "just flip things around to the other side" automatic fallback, opted into by the author.
2. Explicit "if the first doesn't fit, try these properties instead" arbitrary fallback via @position-fallback.

The grid-based proposal's fallback mechanism falls between these two, at a 1.5 complexity level - it can do a little more than 1, and requires commensurately a little more specifying by the author, but isn't nearly as complex or powerful as 2.

I think for this an exploration of use-cases would be best. This might be something that's best delayed until level 2, so we can see where the pain points are for authors in real world code, and make sure the complexity is needed. (But I'm happy to not delay if there's some reasonably convincing answers.) Afaict this could be added in the future with a minimum of pain.

[jensimmons]

I would very much like to see examples of what's possible at "complexity 2" but not possible at "complexity 1.5".

[nt1m]

I will say that the position-area proposal, solves the cascade issues pretty nicely.

[xiaochengh]

I will say that the position-area proposal, solves the cascade issues pretty nicely.

Doesn't position-area have the same issue as the current @try rules? Namely, we also need to run layout to know which position area we are going to use, and therefore, all the area-specific styles (including alignment properties implied by the used area, like center implies anchor-center alignment) are determined at used value time and don't participate in the cascade.

In fact I've always been assuming that position-area list related things are applied at used value time, am I correct?

[kizu]

One thing I was thinking about: as an author, I would be completely ok with only having the position & outer dimensions change for the fallback mechanism, and for any cases where I'd want to have any changes to the properties like padding or border, use containment and then query the resolved dimensions and position after the fallback in order to adjust anything I'd want in relation to the final position.

That would make the more simple cases less complicated, and still allow for enough room for anything else.

And, when only caring about the insets for the fallbacks, I imagine things could be easier by making them a part of a cascade?

As a sidenote (not sure how feasible), I wonder if in this case we could retire the @try, and make it possible to mix the grid-based position-area with the fallbacks for the insets somehow.

Like, what if

.popover {
    position-area: top / all, bottom / all, 0 anchor(same) 0 auto;
}

We'd need to have #1282 first in order for the shorthands to be possible for logical directions, but otherwise I can see this covering both the grid-like alignment and inset one?

From what I understood about the necessity to have @try instead of extending the inset properties, the reason for them was that we'd want to try all the insets at the same time, so we cannot (or it is inconvenient/cumbersome if we'd require to maintain the same order) have the separate insets each with their own list of fallbacks, but if we would only work in a position-area/inset-area context, then we'd be good?

One issue could be that it might be a bit complicated to work only with shorthands, but, given that the common cases would be covered by the simple grid-like layout, we can sacrifice the inset case, especially given no-one would forbid us from using CSS variables for managing the separate values in any way we'd like.

[xiaochengh]

... make it possible to mix the grid-based position-area with the fallbacks for the insets somehow.

Interesting idea! I'll think more about it.

I wonder if in this case we could retire the @try

I still think we should at least also allow sizing and box alignment properties (besides insets and margins) in position fallback, otherwise it seems too restrictive.

And jamming all these things into a single list doesn't look feasible to me, which means we still need something like @try
(or the area-specific styling in Apple's proposal) for the general case.