- From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
- Date: Sat, 25 Jan 2020 01:54:42 +0000
- To: public-css-archive@w3.org
@mrego > Do we need to set sizes for the columns? Do we need those sizes depend on the content (that might be very tricky as you never know when an item is going to end up? See above. Yes, there are examples that would overflow because some (larger) item weren't in the subset of items that contributed to intrinsic track sizing. I doubt this will be a problem in practice though, from looking at actual examples of masonry designs on the web. It's also worth noting that authors can influence which items are considered for the intrinsic sizing step by using `order` to place items at the start, or use definite placement (`grid-column:1` on the third item in your example), or use the placement property in the other axis to force it into the "first row", e.g. `grid-row:1`. Granted, it's not perfect, but it's impossible to let auto-placed items (other than those in the "first row") influence track sizes since it leads to unsolvable circularity issues. Personally, I'd rather include intrinsic track sizing that will work fine for the majority of practical designs than exclude it and require only definite track sizes just because it doesn't work perfectly in all cases. The crux of your testcase is: how do you know which column item 3 will be placed in? This depends on the height of item 1 and 2. If item 1 has a larger height than item 2, then item 3 goes in the 2nd column and shouldn't contribute to the intrinsic size of the first column. > Do we need to be able to position an item into a particular column? Or to span columns? Spanning tracks is most definitely a required feature if we want to support the designs already in use on the web. Maybe placing items into specific columns isn't needed but we get it for free so I see no reason to intentionally remove it. It's a powerful feature and I'm pretty sure authors will find a use for it. Also, it gives authors better control over intrinsic sizing contributions (as noted above) so that's also an argument for keeping it. I also thinks it makes the design easier to understand if we can say that the grid-axis works exactly the same as in regular Grid. (Granted though, the effects of the item placement properties in the masonry axis is a bit fuzzy. Hopefully this will be easier to understand once we have polished spec text for it.) -- GitHub Notification of comment by MatsPalmgren Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4650#issuecomment-578365021 using your GitHub account
Received on Saturday, 25 January 2020 01:54:43 UTC