- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Jul 2023 20:49:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid] Distribute extra space into non-intrinsic tracks instead of going beyond growth limits`, and agreed to the following: * `RESOLVED: Accept edits` <details><summary>The full IRC log of that discussion</summary> <fantasai> We're discussing this case:<br> <fantasai> grid-template-columns: minmax(0, 100px) minmax(auto, 100px);<br> <fantasai> item spanning both columns<br> <dbaron> ScribeNick: emilio<br> <emilio> oriol: In the case we have an item with 2 tracks, one with an intrinsic min but fixed max, which spans also a track with both minmax<br> <emilio> ... instead of forcing the intrinsic track to grow beyond, it could be absorbed by the other track<br> <emilio> ... we have a resolution on this but edits missing<br> <emilio> ... yesterday we met and changed the spec<br> <fantasai> Edits to the specification: https://github.com/w3c/csswg-drafts/commit/0cadf5297d3fd3584ca8a74ac0a86d6f28ab4ca2<br> <emilio> ... it'd be great if you could review and agree with it<br> <TabAtkins> in the above case, the old spec would give as much space as it could do the second track (the intrinsic one), then if there's space leftover it would keep growing the intrinsic one past its max.<br> <emilio> ... the idea would be that we size the intrinsic tracks, then if all of them reach their limit then we check if there are other tracks that the item spans that could grow, and if so they'd absorb some contribution. If they also hit the limit then the intrinsic tracks grow beyond their limit<br> <emilio> ... so it's just inserting that middle step<br> <emilio> q+<br> <TabAtkins> now we'll first give space to the intrinsic track, then give space to the fixed track, *then* blow past the intrinsic track's limit only if we're *still* out of space<br> <astearns> ack hober<br> <emilio> fantasai: [explains the problem in a whiteboard]<br> <emilio> astearns: for this example how are we chosing to fit the right col first?<br> <emilio> fantasai: track sizing has different phases<br> <emilio> ... the first one is the minimum<br> <emilio> ... then the max<br> <emilio> ... we're figuring out the minimum<br> <emilio> ... and we know the min of the previous track is 0<br> <astearns> ack emilio<br> <iank_> q+<br> <TabAtkins> emilio: does this require any etra layout passes? expl sounds lik eno<br> <TabAtkins> fantasai: right, no extra pass<br> <emilio> fantasai: when we distribute space for intrinsic sizes the algorithm distributing across multiple tracks goes through two phases<br> <emilio> ... [explains the case with an extra auto column]<br> <florian> q+<br> <astearns> ack dbaron<br> <emilio> dbaron: some of what you were talking about reminds me about column-spanning cells in tables<br> <emilio> ... in particular about what happens w/ multiple spanning things that are partially overlapping but that could distribute across multiple columns<br> <emilio> ... curious what you do here to avoid ...<br> <emilio> ... I haven't heard talking about the order of the passes here or if you require multiple passes ...<br> <emilio> ... or how you avoid to favor one track over other ...<br> <emilio> fantasai: there are three phases, but we don't want to favor one item over another<br> <emilio> ... the algorithm tracks the current size and the planned increase separately<br> <emilio> ... if I have multiple items spanning tracks<br> <emilio> ... in order to prevent the ordering dependency we check the current size and then the increase<br> <emilio> ... so if I have item 1 spanning cols 1 and 2 and item 2 spanning columns 2 and 3<br> <TabAtkins> (note that elika is currently describing how the grid algo has worked for many years; we didn't change this)<br> <emilio> ... item 1 is 100px and it divides evenly 50px into each track, so we track the planned increase is 50px each. item 2 is 150px and it wants to distribute 75px per track<br> <emilio> ... so we adjust the tracked increase on the columns<br> <emilio> dbaron: I think the interesting case is if item 2 is smaller<br> <emilio> TabAtkins: it's not order-dependent for items within the same span<br> <emilio> dbaron: that's roughly the table solution<br> <astearns> ack iank_<br> <emilio> iank_: conceptually you're tracking two sets of tracks, one if you don't need to blow out the limits and one if you don't<br> <emilio> fantasai: no, blowing out the limits happens per span<br> <emilio> ... we only grow the content once and up to the limit. As we hit the limit we freeze those and keep growing<br> <emilio> ... if we run out of space is when we unfreeze all the tracks<br> <emilio> ... we propose to add a new phase to see if any of the fixed (ignored) tracks are able to grow<br> <emilio> iank_: I think the way we impl this is tracking the items in (1) and (3) separately<br> <emilio> iank_: need to think a bit more<br> <emilio> fantasai: one of the side-effects of this is that you're a lot less likely to blow out the limits, which seems good<br> <emilio> ... the other side effect is that all of the tracks that have fixed sizes could end up having a different size that the tracks that have an identical track-sizing function because of the spanning item<br> <emilio> ... the width of the grid doesn't change because the extra space would be going into the other track<br> <emilio> ... so we're not changing the total size of the grid<br> <emilio> dholbert: I wonder if an item spanning both auto-sized tracks and an item spanning the previous non-auto-sized track would end up growing the grid<br> <emilio> ... I think right now the first item would inflate track (3) to 220px and not contribute to the first track<br> <florian> q?<br> <emilio> ... that is if a later auto track ends up getting inflated due to other items<br> <emilio> ... but this change would also inflate the (1)<br> <emilio> fantasai: for that case if we got that right for (1) and (3) then (2) shouldn't be a problem<br> <florian> pre-existing issue on sizing with multiple spanners: https://github.com/w3c/csswg-drafts/issues/2356<br> <emilio> florian: I think this change doesn't introduce new problems but there are existing ones<br> <emilio> florian: I believe we have a problem for that case but this proposal doesn't make it worse<br> <emilio> dbaron: based on my experience with tables you can't fix both the non-order-dependent and the minimal answer<br> <emilio> iank_: it'd be still true that if there's an fr track we'd still stuff everything there?<br> <emilio> TabAtkins: yes, if there's an fr track we don't do this intrinsic sizing step at all<br> <emilio> ack florian<br> <astearns> ack florian<br> <emilio> florian: I agree there's a conflict with minimizing the space and not taking the ordering dependence. not sure I agree on which one to prioritize<br> <TabAtkins> (rather, if an item spans an fr track it is completely skipped by these intrinsic steps)<br> <emilio> fantasai: but that's a great q dholbert because looking at the algo I'm not sure we got that correct<br> <emilio> astearns: sounds like 1 way forward would be to accept this change and continue looking at the other cases<br> <emilio> fantasai: I think we're not introducing a problem but there might be a pre-existing problem<br> <emilio> florian: this is the one I pasted. If we find a break this week to revisit we should consider revisiting<br> <emilio> ... I think it's addressable, but not sure how without breaking the non-ordered-dependency<br> <emilio> fantasai: I'm sure it's addressable with that because I figured it out a long time ago<br> <emilio> ... so proposal is to accept edits and continue looking at the overlapping spans issue<br> <emilio> dbaron: [tries to convince florian of the ordering vs. optimal width conflict in the whiteboard]<br> <emilio> RESOLVED: Accept edits<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3648#issuecomment-1640973359 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 July 2023 20:49:47 UTC