Re: [csswg-drafts] [css-grid-3][Masonry] Repeat(auto-fill, auto) and % sized items (#12432)

The CSS Working Group just discussed `[css-grid-3][Masonry] Repeat(auto-fill, auto) and % sized items`, and agreed to the following:

* `RESOLVED: use intrinsic sizing generally for column count for percentages`

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> alisonmaher: with intrinsic auto repeaters it's unclear how % should apply<br>
&lt;kbabbitt> ... when determining # of ayto repeats<br>
&lt;kbabbitt> ... % normally apply based on track size but we don't have that<br>
&lt;kbabbitt> ... one idea weve discussed is using container size<br>
&lt;kbabbitt> ... but that can lead to surprises because when you size tracks you resolve % differently than when laying out item<br>
&lt;kbabbitt> ... there's one use case brought up which might bepopular with masonry<br>
&lt;kbabbitt> ... yusing % size on image<br>
&lt;kbabbitt> ... element with aspect ratio, set width to 100% so it fills track<br>
&lt;kbabbitt> ... if we resolve on container size we'd get one track<br>
&lt;astearns> ack fantasai<br>
&lt;kbabbitt> fantasai1: I think the right way to think about this is that count is done as an intrinsic sizing pass<br>
&lt;kbabbitt> ... use rules for resolving % when calculating intrinsic size<br>
&lt;kbabbitt> ... treat them as resolving against nothing<br>
&lt;kbabbitt> alisonmaher: that's another option<br>
&lt;kbabbitt> ... question is what if all items have % based size<br>
&lt;kbabbitt> fantasai1: I think % with intrinsic size get treated as ayuto? can't remember<br>
&lt;kbabbitt> TabAtkins: yes they end up behaving as auto<br>
&lt;fantasai1> https://www.w3.org/TR/css-sizing-3/#intrinsic<br>
&lt;kbabbitt> alisonmaher: so you get 1 auto size track?><br>
&lt;kbabbitt> fantasai1: auto size would use these rules for sizing items<br>
&lt;kbabbitt> alisonmaher: summary of that?<br>
&lt;kbabbitt> fantasai1: there's all kinds of weird exceptions to how it is, but end result is you would reuse same rules and same code as intrinsic sizing<br>
&lt;kbabbitt> ... goal is not to do too much layout here<br>
&lt;kbabbitt> ... what's intrinsic size of item? 200px. some rules, just use them<br>
&lt;kbabbitt> ... when you do layout after all tracks are sized, then you resolve %<br>
&lt;kbabbitt> ... but when you do column count I think it would be better not based on latyout but on intrinsic sizing rules<br>
&lt;kbabbitt> TabAtkins: don't have a great opinion on this, don't think there's a good answer<br>
&lt;kbabbitt> ... alisonmaher's suggestion in thread is what we discussed<br>
&lt;kbabbitt> ... treating % as auto is probably better behavior for purpose of determining column counts<br>
&lt;kbabbitt> alisonmaher: seems reasonable<br>
&lt;kbabbitt> ... assuming that will produce less weird results than I was seeing<br>
&lt;kbabbitt> fantasai1: designed to be resolved with less context<br>
&lt;kbabbitt> ... because rules we use before intrinsic size before we have container size<br>
&lt;kbabbitt> ... to prevent cyclic stuff<br>
&lt;kbabbitt> ... iank can probably tell you all about it<br>
&lt;kbabbitt> alisonmaher: sgtm<br>
&lt;kbabbitt> astearns: proposed resolution is to use intrinsic size rules when resolving % to determine column count<br>
&lt;kbabbitt> fantasai1: use intrinsic sizing generally for column count<br>
&lt;kbabbitt> astearns: objections?<br>
&lt;kbabbitt> RESOLVED: use intrinsic sizing generally for column count for percentages<br>
&lt;kbabbitt> fantasai1: if there are other weird rules we should loop them in so that we're consistent<br>
</details>


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


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

Received on Tuesday, 19 August 2025 08:55:17 UTC