[css-align][css-flexbox][css-grid] Difference between overflow behaviour when aligning and justifying to start and end in flexbox and grid

[rachelandrew]

Where a flex or grid container is smaller than the items inside, and has overflow auto or scroll set on it, items aligned/justified to end or flex-end behave differently to those aligned start or flex-start. The original post from an author who asked me the question is here. I did a couple of tests here, and found the same behaviour in grid with justify-content at least.

This seems to relate to this open Chrome issue, although the behaviour is the same in Firefox.

The relevant part of the spec is here, so the scrolling to the end of the container seems correct, but I think that most authors would expect the overflow to scroll, just from the other direction.

I'm not clear from the spec whether this is a bug in implementations, or is desired behaviour for a reason I don't fully understand, either way it could be clarified perhaps with an example (which I'd be happy to put together once I understand the issue fully myself!)

[MatsPalmgren]

I believe the reason the Grid example doesn't allow scrolling is this:
https://www.w3.org/TR/2016/WD-css-overflow-3-20160531/#scrolling-direction

... UAs must clip the scrollable overflow region of scroll containers on the block-start and inline-start sides of the box (thereby behaving as if they had no scrollable overflow on that side).

[rachelandrew]

Thanks - that makes sense. So is the flexbox behaviour actually a bug or is this the same issue?

[fantasai]

This is a case for using margin: auto, I think. We're locked into not being able to scroll to the top or left because, historically, browsers didn't do that and Web pages started relying on that to hide content by offsetting it thousands of pixes to the top/left. Nevermind that we didn't have a good UI model for the initial scroll position being in the middle of the scrollable area, allowing users to scroll to that hidden content would make the scrollbars unusable because of the huge scale of that distance.

So in Flexbox, margin: auto alignment is "safe" alignment, where if it overflows it always overflows the end edges of the box. And the alignment properties are "unsafe" alignment: they can result in content overflowing to the top or left, where it can't be accessed. But they allow for
true centering/right alignment, which are needed for some designs.

In Box Alignment, we've got two solutions we're tossing around:
1.) Making the "unsafe" alignment behavior of the alignment properties a little smarter, by having it only disobey the specified alignment if it will actually overflow the scrollable area, rather than basing the end-alignment safety trigger on whether it overflows its containing block.
2.) Giving the author control over this with the "safe" and "unsafe" keywords, which will explicitly trigger the margin: auto-type behavior or the overflow-if-necessary-but-absolutely-preserve-alignment behaviors, respectively.

(It's a bit unclear atm if #1 is implementable; if not it'll behave as "unsafe".)

See https://drafts.csswg.org/css-align/#overflow-values

[fantasai]

Oh, and, as Rachel points out here, the spec requires making the overflowing content visible when overflow: auto is set on the same element that has align-content/justify-content. So between that and the safe/unsafe handling described in the comment above, I think we've handled the issue spec-wise, and maybe implementations need to follow up.

@rachelandrew Can you confirm if everything here looks good to you, or if you have some concerns that aren't addressed? :)

[fantasai]

Note: We did make some clarifications to the alignment+overflow section that Rachel linked to, hopefully that helps.

[rachelandrew]

I think the safe/unsafe handling would deal with the issue as raised so I don't have any other concerns :)