- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 17 Dec 2025 17:01:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][masonry] Clarify what mixing subgridded items with automatic and definite grid position does`, and agreed to the following: * `RESOLVED: Explicitly placed items in a subgrid contribute to all tracks (even if they can't actually go into that track); but only if the item is fully auto-placed (can start in any track).` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> q+<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/10926#issuecomment-3348981423<br> <TabAtkins> proposal here ^^^<br> <Kurt> alisonmaher: In the spec, we note how auto-placed items contribute track sin subgrids, but it doesn't know what to do with explicitly placed items - which tracks will explicitly placed items apply<br> <Kurt> fantasai: we have an auto place grid-lanes item, we have a subgrid, with an item, which items contribute to tracks in the parent grid<br> <Kurt> ...lets say there's 3 tracks, 2 placements, 1 and 2 and 2 and 3. Track 1 gets the narrow, 3 gets the wide, track 2 gets the max of both. Alternative is to just accumulate all the items and make all of the tracks the max of all of the items.<br> <Kurt> alisonmaher: treat them as auto placed<br> <Kurt> fantasai: I find it hard to think of a case where this would come up with this kind of overlapping behavior. Main concern is in the future it's likely we'll have stronger controls for auto placement, e.g. 10 column parent grid and an item that spans 2 tracks, can only start in an odd tracks, so all narrow items will only be on odd tracks and wide<br> <Kurt> items go in even tracks...<br> <Kurt> ...not sure if that paints us in a corner or not<br> <Kurt> alisonmaher: Not sure which proposal you're pushing for...<br> <Kurt> fantasai: strong opinion on theoretical case, but otherwise don't have an opinion<br> <Kurt> alisonmaher: weird thing with odd placement if you shift subgrid one track at a time, you'd have it contribute to every track<br> <Kurt> fantasai: right now, all items will contribute to every track except first or last<br> <TabAtkins> elika is discussing a theoretical future where we can limit auto-placemnet more<br> <astearns> ack TabAtkins<br> <Kurt> ...you'd get accumulation in middle tracks and dedicate at edges. A theoretical future where we can restrict placement to named tracks in a repeating pattern, you'd be able to say the subgrid starts on an odd number, placing would be exclusive<br> <Kurt> TabAtkins: I think Elika and I agree - the proposal in the issue. If a subgrid has explicitly placed items, they should only contribute the tracks they go into in the parent masonry. Will shave off a few from the edge. In the future, it'll be able to limit more drastically. Gives the correct behavior in most scenarios.<br> <Kurt> alisonmaher: Seems reasonable, complicates implementation. I see argument of placing everywhere.<br> <Kurt> fantasai: I don't mind your propsoal, as long as we're ok with more complicated placements might change this in the future<br> <Kurt> TabAtkins: +1, currently we have no restrictions, it impacts tracks in the middle. Ok with leaving it as is for now and having auto placement now. Do nothing, items are placed in all positions.<br> <Kurt> astearns: any concerns with not handling this for now?<br> <fantasai> PROPOSED: Explicitly placed items in a subgrid contribute to all tracks (even if they can't actually go into that track); but only if the item is fully auto-placed (can start in any track).<br> <Kurt> astearns: objections?<br> <fantasai> RESOLVED: Explicitly placed items in a subgrid contribute to all tracks (even if they can't actually go into that track); but only if the item is fully auto-placed (can start in any track).<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10926#issuecomment-3666295527 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 December 2025 17:02:00 UTC