[css-flexbox-1][css-position-3] static position of abspos flex children

[fantasai]

@dholbert pointed out in #1432 (comment) #1432 (comment) and https://bugzilla.mozilla.org/show_bug.cgi?id=1682641#c9 that the newer CSS Positioned Layout model for handling the alignment properties and the flexbox spec conflict on a few points.

First, overall:

• css-position defines abspos layout as creating an inset-modified containing block (where some of the insets are auto insets derived from the static position), and then applying alignment within that rectangle. It defines the auto offsets for a flex child to coincide with the content edges of its container.
• css-flexbox sets the position of an abspos child more directly in https://drafts.csswg.org/css-flexbox/#abspos-items in normative prose by defining it as the position the item would have had as the sole flex item (but says something different, matching css-position, in the note in the same section).

A few places where this matters that @dholbert pointed out:

• Per css-position, in a column flex container, the align-self property will apply in the block axis, not the main axis. But per css-flexbox, it will affect the static position in the main axis.
• Per css-position, the justify-self property will affect the static position in the inline axis. Per css-flexbox, it can have no effect.
• Per css-position, justify-content and align-content on the container have no effect on the child's static position. But per css-flexbox, they do.

We need to resolve these conflicts somehow.

[tabatkins]

Our preferred resolution is just to say that Position is correct, and Flexbox was written while we were still figuring things out. We suspect the compat impact of making the changes is minimal, especially since cross-browser behavior seems all over place.

[fantasai]

Mm, actually we have a fair amount of interop here. Test results for a statically-positioned abspos child of a flex container:

• Neither Firefox nor Chrome applies justify-self to an abspos flex child.
• Both Firefox and Chrome apply align-self to an abspos flex child, in the cross axis.
• Both Firefox and Chrome apply justify-content on the container to the abspos, in the main axis.
• Firefox applies align-content on the container to the abspos, but Chrome doesn't. (Note that align-content only has an effect if the flexbox is multiline.)

Note that these behaviors only apply to abspos that are statically-positioned.

[dholbert]

Yeah, so the compat situation here (per fantasai's "test results" comment) seems to be that Firefox, Chromium, WebKit, and pre-Chromium Edge all directly implement the Flexbox normative prose (determining the static position as if the abspos thing were the flex container's sole flex item). The only deviation from that is that Chromium, WebKit & pre-Chromium Edge neglect to honor align-content when determining that position (which per the prose, they should honor iff the flex container is multi-line).

So browsers are mostly consistent on this right now, and have been for at least 3-4 years, which makes changes feel pretty risky from a webcompat perspective.

[fantasai]

OK, so proposal: define the static position rectangle of a flex child as:

• In the main axis, the start and end margin edges of the child if it were the sole flex item in the container. [this will lock us to the position defined by justify-content on the flex container]
• In the cross axis, we have a couple options:
  1. Use the start/end margin edges of the hypothetical flex item honoring both align-self and align-content per Firefox.
  2. Use the start/end margin edges of the hypothetical flex item pretending flex container is single-line OR use the content-box edges of the container and define that statically-positioned abspos flex children specially map their align/justify-self axes per the container's flex flow instead of the abspos containing block writing mode. (Same effect, different definition methods.)
  3. Use the content-box edges of the container, allow alignment properties to work within resulting range as for other abspos.

The first option is consistent with Firefox and the Flexbox spec.
The second option is consistent with Chrome and WebKit.
The third option is consistent with Chrome and WebKit in the case of row flex containers, but differs in column flex containers in whether align-self or justify-self controls the alignment. However, it means align/justify-self axis mapping would be consistent across all abspos, instead of making a special exception for statically-positioned flex child abspos.

I think if we can do the third option, in the long run (once alignment is implemented for all abspos), it will be better for authors. But we need to consider the compat impact, and would need data for that.

CC @bfgeek @cbiesinger

[fantasai]

Related issue: #5061

[fantasai]

So the question we need an answer to is, would swapping the axes of align-self vs justify-self on an abspos child of a column flex container (i.e. making align/justify match the block/inline split of other abspos, rather than the cross/main of other flex items) break content.

[cbiesinger]

Maybe @davidsgrogan can help with adding a use counter for align-self/justify-self on abspos items in a column flexbox? I guess ideally limiting to items which don't have the corresponding left/top/right/bottom property specified...

[foolip]

I'm interested in this issue because it's a large chunk of failures in https://wpt.fyi/compat2021?feature=css-flexbox and am trying to understand, with the help of @svillar. I'm wondering about these two comments:

@tabatkins said:

cross-browser behavior seems all over place

@dholbert said:

browsers are mostly consistent on this right now, and have been for at least 3-4 years

Getting clarity on this would be great, and seems like it's what should determine the outcome here. If there is already a high degree of interop here, then unless the behavior creates problems for web developers, just sticking with it seems best. But there have been cases in the past when moving away from interop has been the only way to get to a sensible state, so it's not a hard rule. What should happen here?

[fantasai]

@foolip See #5843 (comment)