- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 18:44:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][masonry] Handling baseline shim for multi-span items in intrinsic track sizing`, and agreed to the following: * `RESOLVED: No change` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> yanling: [shares screen]<br> <kbabbitt> yanling: from the spec, track sizing can be optimized by aggregating items that have same span size and placement into single virtual item<br> <kbabbitt> ... with multi span items this can lead to incorrect track sizes<br> <kbabbitt> ... in this example we have one item spanning 2 tracks, blue item explicitly placed in track 1<br> <kbabbitt> ... green item in track 2<br> <kbabbitt> ... we observe that track sizes differ between grid and grid-lanes<br> <kbabbitt> ... root cause, in grid when calculating intrinsic size contributions, placement data is already available<br> <kbabbitt> ... plum item contributes to track 1's baseline<br> <kbabbitt> ... need to correct baseline trim for blue item<br> <kbabbitt> ... in grid-lanes, we follow the spec's item grouping model without placement knwoeldge<br> <kbabbitt> ... items are grouped by span size, since plum and blue are differen they're in different groups<br> <kbabbitt> ... baseline trim will be 0 which caseus block contribution to be smaller than grid<br> <kbabbitt> ... we have a few possible solutions<br> <kbabbitt> ... option 1, rerun track sizing<br> <kbabbitt> ... ignore the baseline trims on first track sizing pass<br> <kbabbitt> ... placement, rerun track sizing<br> <kbabbitt> ... given placement could change based on update to track sizes, not ideal<br> <kbabbitt> ... option 2 would be group by baseline sharing with overlap analysis<br> <kbabbitt> ... baseline sharing align then define overlapping groups based on possible placement, calculate max shared baseline across overlapping rules on each item, then group into virtual items and calc contributions<br> <kbabbitt> ... this option would be easy for explicitly placed items, but challenges for implicit items. baseline isharing itself may vary with placement<br> <kbabbitt> ... need to come up with every possible position of every item for every combination<br> <kbabbitt> ... which undermines virtual item optimization<br> <kbabbitt> ... option 3 is group by baseline alignment type onluy<br> <kbabbitt> ... first group, then calculate shared baseline in each category, then group into actual virtual items and calc contribhution size<br> <kbabbitt> ... for thise xample since all items are baseline aligned, end up in same group[ in step 1<br> <kbabbitt> ... row 1 is correctly sized, row 2 is over expanded because green's baseline shim is calcuilated against shared beaselin<br> <kbabbitt> ... per spec, plum should only participate in baseline alignment in startmost context<br> <kbabbitt> ... onlyu row 1 not row 2, grouping doesn't account for this<br> <kbabbitt> ... would prefer to proceed with option3, drawback of 2 is that it requires every possible combination which undermines optiization<br> <kbabbitt> ... both options may over expand track sizes<br> <kbabbitt> ... but account for every possible placement<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/13530#issuecomment-4121175679<br> <Rossen> ack fantasai<br> <kbabbitt> fantasai: confused as to why you're getting wrong results with this example<br> <kbabbitt> ... spec says you separate grid items into item groups<br> <kbabbitt> ... each item is in its own group<br> <kbabbitt> ... then for each of these groups you synthesize a virtual grid item<br> <kbabbitt> ... then place hypotehtical copyu of each group into each set of tracks it could occupy<br> <kbabbitt> ... since they're explicitly placed, they go in tspecifid tracks<br> <kbabbitt> ... then run track sizing algo with those items<br> <kbabbitt> ... track sizing includes baseline alingment shimming within itself<br> <kbabbitt> ... you're not doing it in a previous step and not doing it here<br> <kbabbitt> yanling: they're in 3 different item groups<br> <kbabbitt> fantasai: but those groups were just for virtual placement<br> <kbabbitt> ... now that's done we run track sizing on all virtual items<br> <kbabbitt> ... when you do track sizing, a track that has 2 items in it, one a spanner one not both in same track<br> <alisonmaher> q+<br> <kbabbitt> ... have to do baseline alignment on them but it looks like you're not doing that<br> <kbabbitt> alisonmaher: the way we impl is that baseline shim is part of item contribution<br> <kbabbitt> ... have to know max of those<br> <kbabbitt> .... could have multiple and need to calculate up front know which has largest contribution size<br> <kbabbitt> ... problem is we calculate before placing items in every track need to know which one is largest<br> <kbabbitt> fantasai: say 3 items creating virtual item<br> <kbabbitt> ... virtual item has a size and baselin position<br> <kbabbitt> ... then that virtual item gets put into a track<br> <kbabbitt> ... same track shared with plum one because plum spans 1+2, blue is start alignment<br> <kbabbitt> ... virtual item has a baseline which we aggregated<br> <kbabbitt> ... that aligns with plum wone to do real track sizing<br> <kbabbitt> alisonmaher: so instead we store the baseline as separate contribution inside virtual item? the one which creates largest shim?<br> <kbabbitt> fantasai: yes have to do another calc once assembled multiple items in same track<br> <kbabbitt> ... might make a larger shim<br> <kbabbitt> ... virtual item is a way to group stuff with same placement<br> <kbabbitt> ... but step 3 says do track sizing with these virtual items<br> <kbabbitt> ... which involves calculating virtual item's baseline shim with respect to rest of items<br> <kbabbitt> alisonmaher: I think we probably could explore doing something where we calc that later on rather than before items are placed<br> <kbabbitt> Rossen: so, take it back and do more exploration?<br> <kbabbitt> fantasai; I think spec is requiring correct behavior, just a question of..<br> <kbabbitt> alisonmaher: just the ordering of things<br> <kbabbitt> Rossen: we can resolve this no change, if anything else comes up we can come back<br> <kbabbitt> RESOLVED: No change<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13530#issuecomment-4172214752 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 April 2026 18:44:15 UTC