Re: [csswg-drafts] [css-grid-3][masonry] variable track sizes + dense packing has poor performance (#9326)

The CSS Working Group just discussed `[css-grid-3][masonry] variable track sizes + dense packing has poor performance`, and agreed to the following:

* `RESOLVED: Have the proposed algorithm for dense packing, with clarification that it looks at spans with same used size`

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> fantasai: one of the challenges brought up with masonry was that we have this dense keyword<br>
&lt;kbabbitt> ... for grid placement<br>
&lt;kbabbitt> ... what does that mean in masonry?<br>
&lt;kbabbitt> ... when you have variable width columns knowing which slots you can place an item into for a perfect result<br>
&lt;kbabbitt> ... would mean having to size the item into each column width, calculate its height in order to figure out if it fits in that slot<br>
&lt;kbabbitt> .. that's a lot of work browser probably doesn't want to do<br>
&lt;kbabbitt> ... we talked abou tit, suggestion is to lay out the item where it would be without dense packing<br>
&lt;kbabbitt> .. likely to stay there<br>
&lt;kbabbitt> ... if it's short enough to fit in a gap left by spanning elements, with the same used width, put it in that gap<br>
&lt;florian> q+<br>
&lt;TabAtkins> q+<br>
&lt;kbabbitt> ... if you have a masonry layout where all tracks are same width, this is perfect algorithm<br>
&lt;kbabbitt> ... if a masonry layout with 2 track widths, an item that would be placed in a wider track would only move into a gap left in a wider track<br>
&lt;kbabbitt> .. likewise for narrow tracks<br>
&lt;kbabbitt> ... in most cases you end up with dense packing you expecty<br>
&lt;kbabbitt> .,.. but if you have a lot of different widths and not many items, maybe you leave gaps that could have been filled<br>
&lt;kbabbitt> ... we think this is close enough and addresses most common use cases for dense packing<br>
&lt;astearns> ack florian<br>
&lt;kbabbitt> florian: I think that makes sence<br>
&lt;kbabbitt> ... supect my line of questioning will be shut down but want to check<br>
&lt;kbabbitt> ... as I was listening and mostly agreeing, was wondering whether, when you check for other columns to move to, check for columns same size or bigger?<br>
&lt;kbabbitt> ... then you would have to relayout but would know it fits<br>
&lt;kbabbitt> fantasai: don't know if it fits due to aspect ratio<br>
&lt;kbabbitt> florian: thanks for confirming<br>
&lt;kbabbitt> ... with that explored think that makes sense<br>
&lt;astearns> ack TabAtkins<br>
&lt;kbabbitt> TabAtkins: also agree with this proposal<br>
&lt;astearns> q+<br>
&lt;kbabbitt> ... ethanjv from microsoft has questions<br>
&lt;kbabbitt> astearns: the way you formulated the issue was talking about tracks with same size<br>
&lt;astearns> ack astearns<br>
&lt;kbabbitt> ... but is it about spanners with same size?<br>
&lt;kbabbitt> fantasai: good clarification, should make sure we get that in spec<br>
&lt;kbabbitt> astearns: other comments or questions?<br>
&lt;astearns> https://github.com/w3c/csswg-drafts/issues/9326#issuecomment-2457881349<br>
&lt;kbabbitt> astearns: Proposed resolution is what is in ^ comment linked above<br>
&lt;kbabbitt> ... with amendment that it's track spans with same used size are possible targets for moving into more dense packing<br>
&lt;kbabbitt> TabAtkins: doesn't only apply to single track items, yes<br>
&lt;kbabbitt> ... 2-track spanner looking at pairs of tracks<br>
&lt;kbabbitt> astearns: objections?<br>
&lt;kbabbitt> RESOLVED: Have the proposed algorithm for dense packing, with clarification that it looks at spans with same used size<br>
</details>


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


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

Received on Wednesday, 2 April 2025 19:15:33 UTC