- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 25 Jun 2025 16:50:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-align-3] the `safe flex-start` fallback alignment for `justify-content:space-between` is actually unsafe``, and agreed to the following: * ``RESOLVED: Change `safe` alignment on scroll containers to align towards the scroll origin side (rather than the `start` side)`` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> dholbert: this is a case where the spec is clear, but browsers dont' match, and we tried to align with the spec and got breakage<br> <TabAtkins> dholbert: oriol observed that if we did an additional change we wouldn't have the breakage, but as it currently stands i'm not sure everyone is willing to implement both changes<br> <TabAtkins> dholbert: so more detail<br> <TabAtkins> dholbert: justify-content:space-between and its fallback value<br> <TabAtkins> dholbert: currently impls have it fall back to `flex-start`, spec says to do `safe flex-start`. those differ when your axises are reserved<br> <TabAtkins> dholbert: like row-reverse, flex-start and start are opposite side<br> <TabAtkins> dholbert: `safe flex-start` means if you overflow it'll overflow towards the end side.<br> <TabAtkins> dholbert: but that's an issue, if you have -reverse keywords, the scrollbars start on the end side, so overflowing toward that actually does cause content to be clipped into the unscrollable region<br> <TabAtkins> dholbert: oriol observed there's some additional spec text that if you have a scroll container that would overflow off its start side, you shoudl adjust the positioning so it's not overflowing. but it's not clear we want to do that.<br> <TabAtkins> dholbert: so for simplicitly i think we might want to align with impls and remove `safe`<br> <TabAtkins> dholbert: but i don't think i feel really strongly, maybe we want to wait for both changes<br> <astearns> ack fantasai<br> <TabAtkins> dholbert: but righ tnow spec and impls disagree<br> <TabAtkins> fantasai: i think for a scroll container, using the "unsafe" behavior is the right thing to do, so it'll scroll in the direction the author is expecting<br> <TabAtkins> fantasai: and the spec section about alignment overflow will ensure the content can be scrolled to<br> <TabAtkins> fantasai: if it's not a scroll container, this can result in it overflowing into the unscrollable area<br> <TabAtkins> fantasai: tricky is, don't htink we can represent that - safe in non-scroll containers, unsafe in scroll becuase it's actually safe in practice<br> <TabAtkins> fantasai: that's probably what we want but it hasn't come up before<br> <TabAtkins> dholbert: all the spec text involved here sorta represents that correctly, to get it you cna start to adjust the scroll position to make it scrollable<br> <oriol> q+<br> <TabAtkins> fantasai: i know webkit does it, i implemented that<br> <TabAtkins> fantasai: but you'd be scrolled to the wrong side of the container. if i have row-reverse, i'd expect scroll origin to be on the right side (opposte of normal)<br> <TabAtkins> fantasai: but if you use safe alignemtn you'll be scrolled to the right, so you see the left edge [think i might have gotten confused here]<br> <TabAtkins> fantasai: it's outside of a scroll container that we want to enforce safe alignment<br> <fantasai> s/scrolled to the right/scrolled to the left/<br> <dholbert> s/webkit does it/webkit does the thing to expand the overflow area to include area from the negative scrollable region from overflowing alignment subjects/<br> <fantasai> But within a scroll container, we should use "unsafe" alignment, because it's not actually unsafe -- the scroll container makes sure we can see the content<br> <TabAtkins> astearns: so based on elika's feedback, think we should remove the `safe` from the fallback, and see if we can conditionally re-introduce it for non-scroll containers?<br> <astearns> ack oriol<br> <TabAtkins> dholbert: makes sense to me<br> <TabAtkins> oriol: for scroll containers vs not, you can specify safe or unsafe but can also omit, giving automatic alignment. that has different behavior based on scroll or not. not sure if it's exactly what we want, but we could use it.<br> <TabAtkins> fantasai: i think that's a bit challenging. right now, if you want to center a box that's too small, it's going to overflow and be absolutely centered. that's default behavior, probably what people are depending on.<br> <TabAtkins> fantasai: one thing we might be able to do is change the definition of safe alignment, so if the container is a scroll container, safe doesn't change how you align - it's a no-op<br> <TabAtkins> fantasai: that would satisfy the idea that we're just trying to find a safe alignment. might not be workable, but maybe worth looking into<br> <TabAtkins> astearns: what to do right now?<br> <TabAtkins> fantasai: i think we can conclude that for scroll containers, alingment is as specified (without `safe` adjustment)<br> <TabAtkins> fantasai: because you *can* scroll to them<br> <TabAtkins> fantasai: so further question is just whether it can be something we can tie into `safe`, or make it something special for fallbacks, or what<br> <TabAtkins> dholbert: if we dont' do safe alignment, we ahve stuff potentially overflowing off the top of the scroll container (with the additional behavior making that stuff scrollable), if *that* child still has stuff overflowing off of it... that would be unscrollable regardless, i guess<br> <TabAtkins> dholbert: i think i maybe agree with fantasai<br> <fantasai> Option A) 'safe' alignment follows the specified alignment on scroll containers, rather than restricting overflowing content to start alignment, because the scroll container allows scrolling<br> <TabAtkins> astearns: so trying to understand elika's suggestion<br> <TabAtkins> astearns: is it to keep the spec as-is but refine the behavior of `safe`?<br> <fantasai> Option B) fallback alignment follows the specified alignment on scroll containers (as above), as a magic thing that isn't otherwise specifiable<br> <fantasai> Option C) B, but with a new keyword<br> <oriol> q+<br> <astearns> ack oriol<br> <TabAtkins> fantasai: i think it'd prefer to avoid new syntax, so if we can get away with changing `safe` to be a no-op on scroll containers, might be the best option. not sure about compat<br> <TabAtkins> oriol: i think in this case, saying `safe` is a no-op on scrollers is fine. it's a fallback alignment<br> <TabAtkins> oriol: but in general, people could set `safe center`, big children could overflow both directions, not sure if ignoring `safe` is the right thing to do<br> <TabAtkins> astearns: i'm a little concerned about stuffing more magic into the safe fallback alignment, already complex and not adjustable by authors<br> <TabAtkins> astearns: i'm not opposed to this, but think it's got a little smell to it<br> <TabAtkins> oriol: maybe rather than changing `safe`, rather than it being no-op we change it so instead of `start` side, we use the scrolling origin sid<br> <TabAtkins> oriol: so in a flexbox, it would align to the flex-start side<br> <TabAtkins> dholbert: that works if the flexbox itself is scrollable, but not if the ancestor is<br> <TabAtkins> fantasai: we'd only do this for scroll containers<br> <TabAtkins> dholbert: okay. that would be making `safe` a little more magical<br> <TabAtkins> astearns: so is the proposed resolution that we redefine `safe` fallback alingment for scroll containers?<br> <TabAtkins> TabAtkins: and just fallback, or `safe` in general?<br> <TabAtkins> dholbert: i'd say the keyword itself<br> <TabAtkins> PROPOSED: Change `safe` alignment on scroll containers to align towards the scroll origin side (rather than the `start` side)<br> <dholbert> looks good to me!<br> <fantasai> i.e. the item-flow start side :)<br> <TabAtkins> RESOLVED: Change `safe` alignment on scroll containers to align towards the scroll origin side (rather than the `start` side)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11937#issuecomment-3005471397 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 June 2025 16:50:59 UTC