- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 13 Nov 2025 05:40:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][Masonry] Intrinsic auto repeats mixed with fixed tracks`, and agreed to the following: * `RESOLVED: Instead of chopping up spanning items, do enough repeats to cover all posibilities and the create hypothetical items for all spans, and do the same process as span-1 items do, with a reasonable lower bound on the spec for how much needs to be supported` <details><summary>The full IRC log of that discussion</summary> <emilio> TabAtkins: currently masonry has the ability to do repeat auto-fill with intrinsic tracks in the repeat list<br> <emilio> ... you can do it in masonry because we have a heuristic<br> <emilio> ... which works great for span 1<br> <emilio> ... the spec has some more details but that's the tldr<br> <emilio> ... to deal with larger span is not so easy<br> <emilio> ... the current way the spec defines it<br> <emilio> ... you chop it as if it was made of single-span items<br> <emilio> ... so if you have 300px span: 2 you pretend you have two 150px single-span items<br> <emilio> ... for some repeats like 100px auto auto<br> <emilio> ... it doesn't work that well<br> <emilio> ... if this was grid this would work well<br> <emilio> ... but with the heuristics it'd make them 150px wide which means that if you 300px is in the first half you get overflow<br> <emilio> ... without anything to do about it<br> <emilio> ... some suggestions in the issue<br> <emilio> ... I think there's a reasonable opinion, if anyone has different ideas welcome<br> <emilio> ... preferred option is<br> <emilio> ... instead of expanding the repeat once, chop large spans and split<br> <emilio> ... we should repeat the tracks as many times as needed to capture all possible ways a spanner could end up<br> <emilio> ... then rather than chopping up we group them by span<br> <emilio> ... and do the hypothetical calculation<br> <emilio> ... then we pretend all span 1 items live in every position and the 2 span items as well, etc<br> <emilio> ... with some fixes for perf not to be terrible<br> <florian> q+<br> <emilio> ... and then take whatever comes out of that<br> <emilio> ... in the example, it'd result both columns being 200px wide which means regardless of how many times<br> <alisonmaher> q+<br> <emilio> ... there's no perfect solution but guarantees no overflow, and quite often you'd get a perfect fit<br> <emilio> ... extending the span 1 heuristic to work on span 2 and so on<br> <emilio> florian: makes sense but trying to confirm<br> <astearns> ack florian<br> <emilio> ... if I understand right it has an additional benefit, which is we place actual spanners, the sizing phase would take into account that you could span through gaps<br> <emilio> TabAtkins: wasn't super relevant but the chopping already deals with that (subtract the gaps)<br> <emilio> florian: ok, seems like a good idea<br> <astearns> ack alisonmaher<br> <emilio> alisonmaher: I'm supportive, I think it's the best of all the options we could through that. Wanted to mention that that the intrinsic sizes would be different between the columns<br> <emilio> ... so you want to take the max<br> <emilio> TabAtkins: replied on the thread, you'd need to do two reps so both of the autos have 200px<br> <emilio> alisonmaher: If you had 100px auto auto auto you'd still get a 150px in the middle<br> <emilio> ... so we still need the max<br> <emilio> TabAtkins: I don't think why<br> <emilio> alisonmaher: you need this for auto repeat to do the division<br> <emilio> TabAtkins: As long as you have a value I don't think so<br> <masonf> q?<br> <emilio> PROPOSED: Instead of chopping up spanning items, do enough repeats to cover all posibilities and the create hypothetical items for all spans, and do the same process as span-1 items do<br> <emilio> q+<br> <TabAtkins> emilio: This smells like potentially quadratic... maybe fine since it's quadratic on number of items in repeat<br> <TabAtkins> emilio: how easy is it to end up with a bad layout?<br> <emilio> TabAtkins: not quadratic it scales with the number of spans<br> <emilio> ... so you scale up with the max scale of the span<br> <emilio> ... but more of a question of how many distinct spans you have<br> <emilio> ... worst would be 1000 items with 1000 different span values<br> <emilio> ... but that's very bizarre<br> <emilio> ... so I think you could bail out, I don't think it can happen for reasonable markup<br> <emilio> emilio: might be worth to put a lower bound on the spec or something?<br> <emilio> PROPOSED: Instead of chopping up spanning items, do enough repeats to cover all posibilities and the create hypothetical items for all spans, and do the same process as span-1 items do, with a reasonable lower bound on the spec for how much needs to be supported<br> <emilio> florian: would be good for the bound to not be artificially low<br> <emilio> RESOLVED: Instead of chopping up spanning items, do enough repeats to cover all posibilities and the create hypothetical items for all spans, and do the same process as span-1 items do, with a reasonable lower bound on the spec for how much needs to be supported<br> <emilio> TabAtkins: yeah will take impl feedback into account<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12899#issuecomment-3525524685 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 November 2025 05:40:02 UTC