w3c
[css-grid-3][masonry] Clarify what mixing subgridded items with automatic and definite grid position does
The following section of the spec states how to handle automatically placed subgridded items within a masonry container, which are supposed to be consider in every possible track for sizing.
However, there is nothing clarifying the expectation for items with a definite grid position that are subgridded through an automatically placed submasonry. Is the expectation to have that definite position to be consider in "all tracks" within the parent grid axis, considering that it would be offset to the "possible" definite positions it could take?
If this is the expectation, then computing the "possible" tracks an item could be placed becomes very complex when multiple levels of subgridding occur, and it is relevant to have those resolved in order to create the virtual masonry items for the optimized algorithm.
Hm, I think our intent was just that definite-placed items affected the size of the tracks they could theoretically have gone into. So, like, say you have masonry with 5 tracks, and a span-3 submasonry, with an item placed explicitly in track 2 of the submasonry. The submasonry can go in any of the tracks, so 1-3, 2-4, or 3-5; the explicitly placed item, then, can be in the parent masonry's tracks 2, 3, or 4, and thus would be taken into account for those tracks' sizing.
I think that's what you're describing, right?
We probably should consider this in conjunction with some of the auto-placement improvements in https://github.com/w3c/csswg-drafts/issues/10265.
Here's an example that I think we will want to make work:
- 6 tracks in pairs, type A and type B.
- auto-placed masonry parent grid spanning two tracks, but only allowed to be placed in the pattern A-B, i.e. spanning tracks 1-2, 3-4, 5-6 and not 2-3 or 4-5.
I don't think we have very strong use cases for the OP case to work in a particular way, but for this case we want items that can only end up in A tracks to not contribute to B tracks and vice versa.
I think that's what you're describing, right?
@tabatkins Yeah, I believe the question is around what to do for explicit placed items, since the spec only says what to do for auto placed items. Your suggestion makes sense, and I believe that would allow for extension to the case that @fantasai brings up in https://github.com/w3c/csswg-drafts/issues/10926#issuecomment-3348988361
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).
The full IRC log of that discussion
<TabAtkins> q+<TabAtkins> https://github.com/w3c/csswg-drafts/issues/10926#issuecomment-3348981423
<TabAtkins> proposal here ^^^
<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
<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
<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.
<Kurt> alisonmaher: treat them as auto placed
<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
<Kurt> items go in even tracks...
<Kurt> ...not sure if that paints us in a corner or not
<Kurt> alisonmaher: Not sure which proposal you're pushing for...
<Kurt> fantasai: strong opinion on theoretical case, but otherwise don't have an opinion
<Kurt> alisonmaher: weird thing with odd placement if you shift subgrid one track at a time, you'd have it contribute to every track
<Kurt> fantasai: right now, all items will contribute to every track except first or last
<TabAtkins> elika is discussing a theoretical future where we can limit auto-placemnet more
<astearns> ack TabAtkins
<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
<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.
<Kurt> alisonmaher: Seems reasonable, complicates implementation. I see argument of placing everywhere.
<Kurt> fantasai: I don't mind your propsoal, as long as we're ok with more complicated placements might change this in the future
<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.
<Kurt> astearns: any concerns with not handling this for now?
<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).
<Kurt> astearns: objections?
<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).
