[css-align-3] the `safe flex-start` fallback alignment for `justify-content:space-between` is actually unsafe

[dholbert]

Per https://drafts.csswg.org/css-align-3/#valdef-align-content-space-between , the fallback alignment for justify-content: space-between is safe flex-start.

Here, safe is defined as forcing start alignment when the aligned content causes overflow, per: https://drafts.csswg.org/css-align-3/#valdef-overflow-position-safe

In cases where the flex container's main axis is reversed (flex-direction: row-reverse or flex-direction: column-reverse) and the flex container itself establishes the scrollport by having overflow:scroll, the safe keyword here actually makes things unsafe -- it forces the overflow off of the end side, where content is unscrollable.

Testcases:
https://bugzilla.mozilla.org/attachment.cgi?id=9472153 (column-reverse)
https://bugzilla.mozilla.org/attachment.cgi?id=9472158 (row-reverse)

Current Firefox release 136.0.1 renders those^ testcases as orange squares without scrollbars due to following the spec on this point.

I'm planning to revert this behavior and remove safe as part of our fallback alignment here, to match other browsers; and I think we should update the spec as well.

[dholbert]

(+CC @tabatkins @fantasai as css-align-3 editors)

I'm adding a WPT to test this, marked as .tentative for now since it's expecting the behavior that browsers currently have rather than the behavior that the spec requires. (Test can be updated/renamed when we've got a resolution to this issue).
That WPT will soon live at css/css-flexbox/justify-content_space-between-003.tentative.html once my patch lands and has its WPT portion merged upstream. (Here's the wpt.fyi page for this test.)

For convenience, that WPT is also available for live testing here:
https://bugzilla.mozilla.org/attachment.cgi?id=9472184

It shows a green square in all browsers, except in Firefox 136 (current release) through Firefox Nightly 138 where it's red. (Though probably/hopefully we'll have a patched version out on all release channels in a few days, including a 136 dot-release, which will make it green again.)

I believe the spec requires browsers to show a red square (i.e. aligning the start edge of the flex item with the start edge of the flex container), but it seems that requirement doesn't match reality and isn't web-compatible, since it causes breakage in various web-chat platforms as reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1953102 .

[Loirooriol]

I think it should be fine because of this: https://drafts.csswg.org/css-align/#overflow-scroll-position

When the content-distribution properties are set on a scroll container with an overflowing alignment subject, they reduce the clipping of the negative scrollable overflow region just enough to ensure that alignment subject can be scrolled into its start-aligned position.

[dholbert]

Hmm, I think you're right @Loirooriol - that spec text should help us prevent the overflow from being clipped in this case.

However, in practice that's not what happens in Chromium/WebKit at least (i.e. that's not the actual reason they avoid overflow in my WPT and my above-linked testcases here).

Here's another testcase comparing the actual space-between fallback alignment (left half of testcase) to the spec-required fallback alignment (right half of testcase), for a {row,column}-reverse flex container:
https://bugzilla.mozilla.org/attachment.cgi?id=9472487

Chromium, WebKit, and Gecko-with-my-patch-that-just-landed render the left half and the right half differently, indicating that we're all just falling back to flex-start rather than safe flex-start.

I think you're right that we could implement the spec text without suffering from inadvertently-clipped-content if we simultaneously implement the spec text that you quoted, though.