[css-anchor-position-1] Allow more properties in position fallbacks

[xiaochengh]

The current spec only allows inset, sizing and box alignment properties in a @position-fallback rule. This doesn't seem enough.

Consider if the first fallback position is horizontally aligned with the anchor, and the next fallback is vertically aligned. We would likely want different margins, borders and paddings.

So I propose adding border, padding and margin properties into the list of allowed properties.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position-1] Allow more properties in position fallbacks, and agreed to the following:

• RESOLVED: add border, padding, and margin properties to position fallback rules

The full IRC log of that discussion

<dbaron> astearns: see if we can resolve this in 5 minutes?
<dbaron> TabAtkins: currently position fallback has a limited set of things you can put in it. There are use cases for more properties.
<dbaron> ... originally limited for simplicity of implementation. Original goal of things that could be done late in layout cycle, without changing overflow.
<dbaron> ... border/padding/margin don't cause new problems that changing positioning properties do already. Also seem necessary for many things.
<dbaron> ... different margins or different borders depending on alignment.
<dbaron> ... So we're suggesting to add the box properties (border, padding, and margin) into list of allowed properties.
<dbaron> dbaron: all border properties, including stuff like border-image?
<dbaron> TabAtkins: yeah
<emilio> q+
<dbaron> astearns: any objections to adding border padding and margin properties to position fallback rules?
<dbaron> emilio: not an objection, but doesn't that mean that you can trigger image loads as a result of this?
<dbaron> emilio: either need to load the border-image eagerly or it flickers
<dbaron> TabAtkins: known issue with background image that only triggers on :hover
<dbaron> TabAtkins: we should probably do something about it, but doesn't need to be addressed now
<emilio> ack emilio
<dbaron> emilio: fair enough
<dbaron> astearns: any objections to add these properties?
<dbaron> RESOLVED: add border, padding, and margin properties to position fallback rules

[xiaochengh]

After some implementation attempts, it appears that the previous resolution wasn't made with enough care.

Margin properties are fine, but padding and border properties are problematic because they affect the internal layout of the element too much (e.g., intrinsic size, table border collapsing).

Besides, the box alignment properties (other than justify-self and align-self), which have been allowed since the @try rule was first added, also have the same issue.

@bfgeek and I discussed it, and think the only properties that we can safely support now are those affecting only the external geometric constraints of the element, but not anything internal.

(Not until we can properly cascade @try rules, which would probably take another year's effort...)

Proposal: Remove padding properties, border properties, and all box-alignment properties except self-alignment properties from position fallback rules. As a result, the remaining allowed rules will be margin, inset, sizing and self-alignment properties.

[fantasai]

Current proposal is to accept only:

• inset properties
• margin properties
• sizing properties
• self-alignment properties

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position-1] Allow more properties in position fallbacks, and agreed to the following:

• RESOLVED: Remove border/padding.

The full IRC log of that discussion

<emilio> TabAtkins: we have some spec for properties allowed to be set in @position-try / auto-flipped by the automatic keywords
<emilio> ... previous resolution we added margin/border/padding
<emilio> ... the internal properties are more problematic than expected
<florian> q?
<florian> q+
<emilio> ... current proposal reflected in the ED is to only accept insets (including inset-area) / margin / sizing and self-alignment properties
<astearns> ack florian
<emilio> florian: the removal of border-padding makes sense if we can solve it through some other system
<emilio> ... such as something like container queries
<emilio> ... seems plausible that this should work
<emilio> TabAtkins: we're only removing it through implementation difficulty issues
<astearns> ack fantasai
<emilio> ... so we can revise
<emilio> fantasai: any property in the position fallbacks are risky because they don't play with the cascade properly
<emilio> ... the anchor positioning styling will override everything
<emilio> ... including in the more important layer
<emilio> ... it's important to limit the properties that fit in the position try blocks
<emilio> ... any other kind of styling needs to happen in some conditional styling system needs to play well with origin / specificity / etc
<miriam> q+
<emilio> ... I'm fine with these but we should not do the conditional styling
<astearns> ack miriam
<emilio> ... the more you can shift into that the better because it cascade properly
<emilio> s/cascade/cascades/
<emilio> miriam: these properties don't change the result you get
<emilio> ... when you choose what try block to use is not based on what layout to use right?
<emilio> TabAtkins: it is, it is based on whether you overflow with those
<emilio> miriam: ah, so you can't just put them in queries
<emilio> darn
<emilio> florian: anchor-default is not in this list, why?
<emilio> TabAtkins: I think it should be into the list
<emilio> astearns: separate issue?
<emilio> TabAtkins: that's fine
<emilio> dholbert: following up, @position-try order evaluation is independent
<emilio> ... to the sizing properties etc
<emilio> TabAtkins: you don't need to layout the elements but you need to know the inset properties
<dholbert> s/@position-try order/position-try-order: [...]/
<emilio> RESOLVED: Remove border/padding.
<dholbert> s/inset properties/inset properties in order to determine the inset-modified containing block/ (in what Tab said)