[css-anchor-position-1] Alternative syntax for auto position fallback

[xiaochengh]

The current spec uses auto and auto-same keywords in the anchor() function to create automatic position fallbacks, e.g., left: anchor(auto); right: auto.

I think this need to be reworked. Reasons:

• I've heard a lot of complaints that anchor(auto) and anchor(auto-same) are hard to understand
• anchor(auto) uses a special inset value to trigger auto fallbacks, and the generated fallbacks affect inset values only. This will no longer make sense if we allow more properties (like margins) in @position-fallback, which I think is likely to happen (see also [css-anchor-position-1] Allow more properties in position fallbacks #9195)

Proposal

Remove everything about the auto and auto-same anchor side keywords, and:

Add a new position-fallback-auto property

position-fallback-auto: none | flip-block | flip-inline | flip-x | flip-y | flip-both | compass

A none value means no auto fallbacks are generated.

A flip-block value creates a fallback style where, intuitively, all the block-axis values are flipped. Specifically:

• All the *-block-start and *-block-end property values swapped
• The align-* properties are flipped to the other side (e.g., align-self: start --> align-self: end)
• In addition, for any anchor() function used in the block axis:
  • The anchor side keyword is flipped to the other side (e.g., inset-block-start: anchor(start) --> inset-block-end:anchor(end))
  • The anchor percentage is changed to 100% minus that percentage (e.g., inset-block-start: anchor(30%) --> inset-block-end:anchor(70%))

The other flip-* values for a single axis are similar.

The flip-both value creates 3 fallback styles: block axis flipped, inline axis flipped, then both axes flipped.

The compass value allows creating fallback positions around the anchor (e.g., top, left, bottom, right). Specifically:

• 1st fallback style swaps the block and inline property values of the base style
• 2nd fallback style is the same "both axes flipped" style as in flip-both
• 3rd fallback style swaps the block and inline property values of the previous fallback style

Usage in @try block

The property can also be used in a @try block to create additional fallbacks based on a @try block style. This part is similar to the current spec and hence omitted.

Add new same and opposite anchor side keywords

The current auto and auto-same keywords are also useful for non-fallback purposes. For example, inset: anchor(auto-same) creates an inset-modified containing block that's the same as the anchor box.

To support this use case, we add same and opposite anchor side keywords. They are evaluated the same as the current auto-same and auto, but don't create any fallbacks.

Also, same and opposite are not swapped in flip-* fallbacks.

Minor discussion topics

• As flip-both and rotate create multiple fallbacks, maybe we want a syntax to specify the ordering?
• More ways (keywords) to generate fallbacks?

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position-1] Alternative syntax for auto position fallback, and agreed to the following:

• RESOLVED: accept proposal in the draft with details to be worked out over time

The full IRC log of that discussion

<dbaron> TabAtkins: xiaochengh was exploring space for position stuff. While thinking about use cases brought up for alternate proposal, realized the current stuff we have in the spec for auto fallback isn't sufficient. auto and auto-same keywords. Current behavior is that they resolve to appropriate side of anchor and auto-generate try blocks that flip to other side. Only thing changed in try blocks are side -- margins don't change as well.
<dbaron> TabAtkins: That seems less than useful.
<dbaron> TabAtkins: xiaochengh's alternate proposal is to separate the automatic try block generate to an explicit fallback property that has keywords that say how to generate the fallbacks, a bunch of keywords listed in proposal. (flip-both and compass try all 4 possibilities)
<dbaron> TabAtkins: This affects more than just the inset properties. Also affects other box model properties. So margin-bottom after a flip-y ends up as a margin-top.
<dbaron> TabAtkins: This seems substantiallly better to me.
<dbaron> TabAtkins: In the simplest cases it's identical, but in nontrivial cases it does much better behavior. I'm happy to acccept these.
<dbaron> TabAtkins: Other use for auto and auto-same keywords -- automatically resolving to the appropriate side -- can use in the inset shorthand and get all the sides specified. Can keep that behavior and rename the keywords to not imply auto-fallback.
<jensimmons> q+
<dbaron> TabAtkins: I think this opens up possibilities for more fallback. Could build some position-area stuff in here. Could specify position-area spots and it could do appropriate flipping as well. I think it has growth area to fill in remaining fallback cases.
<astearns> ack fantasai
<dbaron> fantasai: I think this is interesting. I find the auto keywords inside ?? to be confusing. I can never remember what the auto thing does. Can we use more descriptiive keywords?
<dbaron> TabAtkins: suggested keywords are same and opposite. So top: anchor(same) means top.
<TabAtkins> top: anchor(same)
<TabAtkins> means top: anchor(top)
<iank_> we can bikeshed with authors
<dbaron> fantasai: another idea would be 'inside' and 'outside'
<astearns> ack jensimmons
<fantasai> top: anchor(inside) is top: anchor(top) -- it anchors it inside the anchor box
<fantasai> top: anchor(outside) is top: anchor(bottom) -- it anchors it outside the anchor box
<dbaron> jensimmons: Comparing this idea to current spec, not much to say. But comparing to proposal we presented at f2f, the higher-level idea of fallbacks. In the position-area/inset-area model, where you say you want above, in both right and center columns... at the bottom do you want it right and center. What if you want above all the way across, falling back to just center if below. But maybe just flipping is what people usually want. No
<dbaron> opinion on whether a good iteration on current spec.
<nicole> Here is a doc of examples we worked through (you'll need to ask for access) https://docs.google.com/document/d/1Dsu91zGfhG-qBbZvwOz13SS_m5dTb_ZHbDbonUf1qnM/edit?usp=sharing&resourcekey=0-8b2dD7pNg1Ruovm0QlhNkA
<dbaron> TabAtkins: Three levels of fallback precision: (1) is simply mirror. (3) is arbitrary things in next fallback, can use try blocks in @position-fallback. (2) between those is to adjust as necessary, mostly just moving to different area. I think this syntax is extendable to take position-area keywords as well.
<xiaochengh> q+
<dbaron> TabAtkins: So you could start out as top center and move to bottom all and have it work out appropriately, with the necessary flips.
<dbaron> TabAtkins: I think that ends up addressing your concern.
<dbaron> jensimmons: I'm not a fan of the try blocks, but maybe a discussion for a different day.
<fantasai> +!
<fantasai> s/!/1
<nicole> +1
<dbaron> TabAtkins: We have use cases that you need the try blocks for, but ideally we should make it so 80% of cases don't need to touch that.
<nicole> q+
<dbaron> jensimmons: I wonder if we can iterate to something where people can do the complicated stuff without try blocks.
<astearns> ack xiaochengh
<astearns> ack fantasai
<Zakim> fantasai, you wanted to ask about relationship to position-fallback
<dbaron> xiaochengh: Wanted to add something to Tab's second case: a little more complicated but not arbitrary: This property can also be used in try blocks so that we can auto-generate fallback from try blocks. It doesn't eliminate all the try blocks but it can significantly reduce the length of the try list.
<dbaron> fantasai: Relationship of this to position-fallback property? Should this be a longhand of this or separate properties?
<dbaron> TabAtkins: What posiotion fallback property?
<dbaron> TabAtkins: If you don't specify position fallback, these entries get auto generated, if you do specify then you ignore it.
<dbaron> fantasai: should they then be the same property?
<dbaron> TabAtkins: maybe
<dbaron> xiaochengh: I don't think so -- position-fallback property cannot be used in a try block but this property can
<lea> in general we should avoid designing syntax that just ignores specified values, as that tends to lead to author confusion. Maybe if we combine both somehow?
<lea> q?
<dbaron> TabAtkins: setting up one try block with the things you need and then saying auto to generate a couple more, that's fair.
<fantasai> yeah, maybe make position-fallback for both
<dbaron> astearns: can we resolve to add to the draft, and add issues such as one property or two, how it works in try blocks?
<lea> I can easily see the auto values being useful both by themselves, as well as fallbacks to more specific fallbacks specified via @Try blocks
<dbaron> fantasai: I think that's fine if we make it clear there's open questions.
<dbaron> RESOLVED: accept proposal in the draft with details to be worked out over time

[tabatkins]

After putting our heads together, @fantasai and I have this proposal for the "details to be worked out over time":

0. We removed all the automatic magic of creating try options from the spec in [css-anchor-positioning-1] implied auto try blocks are confusing #9362, so no fallback options are created unless explicitly.

1. We switched the position-fallback property to three associated properties:

   • position-try-options which is a comma-separated list of fallback options, either named or generated from the base styles by a transform procedure.

     position-try-options: 
        none | [ <dashed-ident> | <try-tactic> ]#
     <try-tactic> = flip-block || flip-inline || flip-start
     (initial value: none)
     

     The try tactics defined here mirror across the block axis, inline axis, or the start-start to end-end diagonal, respectively.

     We could add "shorthand" keywords here that expand to common sets of options, such as drop-down expanding to flip-inline, flip-block, flip-block flip-inline, but we're leaving that for later right now.

   • position-try-order which specifies how to sort/prioritize the list of options: in specified order, or by largest inset-modified containing block size

     position-try-order: normal | <try-size>
     <try-size> = most-width | most-height | 
                  most-block-size | most-inline-size
     (initial value: normal)
     

   • position-try-final which specifies what to do if all of the options overflow the inset-modified containing block.

     position-try-final: always || [ first | <try-size> ] | hide
     (initial value: first)
     

     By default it'll use the last try-option that worked, and only pay attention to this property if the element is being rendered for the first time. If you specify 'always', it'll instead always use the specified option when they all fail, even if it's different from the last successful option.

     hide acts similar to a strong visibility: hidden - the element still has a laid-out box and doesn't paint or capture mouse events, but it also doesn't affect scrollable overflow of its container, and can't be overridden on children.

2. We changed @position-fallback rules containing @try blocks to @position-try, which gives a single named style block to reference from position-try-options:

   /* old syntax */
   @position-fallback --foo {
   	@try { top: anchor(outside); }
   	@try { bottom: anchor(outside); }
   }
   
   /* new syntax */
   @position-try --foo-1 { top: anchor(outside); }
   @position-try --foo-2 { bottom: anchor(outside); }
   

3. We added a position-try shorthand for convenience

   position-try: <'position-try-order'>? <'position-try-options'> [, <'position-try-fallback'>? ]
   

   For example:

   position-try: most-width flip-block, flip-block flip-inline, --foo, first;
   

   This:

   • specifies three style options (2 auto-generated, one provided by a @position-try --foo {...} block) in addition to the base style.
   • sorts all four of these according to which produces the widest inset-modified containing block.
   • if all the options fail on first render, choosing the first one (the widest of the four); on subsequent renders, it uses the most recent successful option (i.e. it tries to be stable).

This system consolidates the fallback system into a single, explicit list, which makes it a lot easier to understand what's happening. Authors who want to package up a particular list can stuff it into a CSS variable.

It also leaves open the possibility of e.g. inlining inset-area syntax as one of the position-try-options items, similar to the Apple proposal from last July.

[yisibl]

Can the new syntax do this easily?

Currently, we can used:

.horizontal .tooltip {
  left: anchor(50%);
  top: auto;
  bottom: calc(anchor(top) + 3px);
  justify-self: anchor-center;
}

.vertical .tooltip {
    inset: auto;
    left: calc(anchor(right) + 3px);
    top: calc(anchor(50%));
    align-self: anchor-center;
    justify-self: auto;
}

With the current syntax, align-self and justify-self need to be interchanged.

[tabatkins]

Well, note that neither of those tooltip positions are compatible with "avoiding overflow", which is the strategy used to decide whether a position is good or not. In fact, they both overflow the input's bounds, and the choice of vertical vs horizontal position seems to have nothing to do with the containing block, either.

So as far as I can tell, the question is moot - that example isn't using fallback at all.