Re: [csswg-drafts] [css-grid-3] Allow <auto-repeat> (i.e. repeat(auto-fill|auto-fit, ...)) to accept intrinsic sizes (#9321)

The CSS Working Group just discussed `[css-grid-3] Allow <auto-repeat> (i.e. repeat(auto-fill|auto-fit, ...)) to accept intrinsic sizes`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> fantasai: Ian suggested it might useful to bea ble to use auto-fill with the intrinsic sizing keywords, particularly in Masonry<br>
&lt;TabAtkins> fantasai: Because, before you can stat placing items you need to know the size of the tracks<br>
&lt;TabAtkins> fantasai: Currently the spec says that you resolve the sizes as if all items were in that track<br>
&lt;TabAtkins> fantasai: So you can do an auto-repeat based on that size<br>
&lt;TabAtkins> fantasai: Can give you odd results if you have wildly differing sizes, and all the thins happens to in one column<br>
&lt;TabAtkins> fantasai: But mostly you'll want this where sizes are similar to even identical<br>
&lt;TabAtkins> fantasai: Grid could maybe also benefit from this<br>
&lt;TabAtkins> fantasai: There's cases where you want to ahve some number of items in your autoplaced grid, but not hardcode the size of the items into the track listing, you want the size to come from the items themselves<br>
&lt;TabAtkins> fantasai: So doing something similar - take the size of the largest grid item - could work<br>
&lt;TabAtkins> fantasai: So question is: is this somethign we're interested in adding?<br>
&lt;iank_> q+<br>
&lt;oriol> q+<br>
&lt;TabAtkins> fantasai: We can add various restrictions as necessary. Like, maybe only the intrinsic-auto-fill can be auto sized<br>
&lt;TabAtkins> fantasai: So you can have one repeat, it can have one track in it, and it's the only intrinsic size in the axis<br>
&lt;TabAtkins> fantasai: More possibilities gets increasingly confusing<br>
&lt;Rossen_> ack iank_<br>
&lt;TabAtkins> iank_: I think this is one of the cases where it's potentiallyc onfsuing for authors in Grid<br>
&lt;TabAtkins> iank_: But makes more sense in Masonry<br>
&lt;TabAtkins> iank_: I typed out an example in the issue<br>
&lt;TabAtkins> iank_: When you're determining the intrinsic size for your items, you need to give them some constraints in the opposite axis<br>
&lt;TabAtkins> iank_: Most noticably, working out the intrinsic block size, you need some inline size<br>
&lt;TabAtkins> iank_: In Grid, since this is before placement, you dont' know what tracks they'll end up in, what size those tracks are, so you ahve to give it *some* inline size<br>
&lt;TabAtkins> iank_: And this'll differ wildly from the item's actual inline size<br>
&lt;TabAtkins> iank_: So the intrinsic block size you're using for repetitions and what it'll actually look like can be very very different<br>
&lt;TabAtkins> iank_: This isn't a problem for Masonry, since the inline size between these steps is stable, it doesn't change. Only a problem for the Grid case<br>
&lt;TabAtkins> iank_: So you'll end up with items where repetitions have a bunch of free space where they shouldn't and we'll get bug reports about Grid looking bad<br>
&lt;Rossen_> ack oriol<br>
&lt;TabAtkins> oriol: Similar to what Ian is saying, I don't see a way to make this work in Grid<br>
&lt;TabAtkins> oriol: Might make sense for Masonry but not seeing it for Grid<br>
&lt;TabAtkins> Rossen_: Suggestions?<br>
&lt;TabAtkins> iank_: The reason a separate display type might be useful is we make things work great for Masonry even if they don't work for Grid<br>
&lt;TabAtkins> fantasai: If the track sizing in the other axis is all the same...<br>
&lt;TabAtkins> fantasai: So like in Grid if the other axis is all auto because you haven't specified row heights<br>
&lt;TabAtkins> fantasai: YOu're auto filling the columns - however many will fit - and the rows are auto height intrinsic grid tracks<br>
&lt;TabAtkins> fantasai: So one thing we could do is handle this by saying if the track sizes in opposite axis are all the same size, then autofill with an intrinsic size will take that size and use it to calculate an intrinsic size for all items in the grid, and repeat that for all tracks<br>
&lt;TabAtkins> fantasai: If there's more than one track size, like author is alternating 500px and auto row heights, then the repetition is just 1<br>
&lt;TabAtkins> fantasai: Functionally disabling the auto repeat, but it's predictable<br>
&lt;TabAtkins> iank_: I don't think that works<br>
&lt;TabAtkins> iank_: If the columns are auto, you still might place something in a particular area that'll increase a particular column by a large amount<br>
&lt;TabAtkins> iank_: And the inline size you use for calculating the intrinsic block size is again very different<br>
&lt;TabAtkins> fantasai: Elaborate?<br>
&lt;TabAtkins> fantasai: Rows are auto-fill, columns are all auto<br>
&lt;TabAtkins> iank_: And you may place one item with a large minimum size in the first column, so all the column will end up different sizes<br>
&lt;TabAtkins> iank_: The inline size you use... you can't tak that into account when determining intrinsic block.<br>
&lt;TabAtkins> iank_: So you'll end up with a bunch of free space<br>
&lt;TabAtkins> Rossen_: Think we should go back to issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9321#issuecomment-1823233101 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 22 November 2023 17:57:02 UTC