- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Oct 2025 16:01:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3] Allow <auto-repeat> (i.e. repeat(auto-fill|auto-fit, ...)) to accept intrinsic sizes`, and agreed to the following: * `RESOLVED: accept the heuristic in the spec just for masonry` <details><summary>The full IRC log of that discussion</summary> <ydaniv> fantasai: several quesiton, one is do we want to have this in masonry?<br> <ydaniv> ... there's a heuristic in the spec which allows to calculate a value for the number of repeated tracks<br> <ydaniv> ... assuming all are placed items, we take each item and use that to calculate tracks, works reasoably well if all reeapted tracks have same size, and not if different<br> <ydaniv> ... one thing to consider is allowing only one track with intrinsic size<br> <ydaniv> ... can we use same heurisitic in masonry?<br> <ydaniv> astearns: I'm not prepared, anyone with opinion?<br> <ydaniv> almaher: for intrinsic auto-repeat there are a few useful cases, regarding mixing of different intrinsic sizes, got reasonable results<br> <ydaniv> astearns: other comments?<br> <ydaniv> fantasai: for mixing could work for mixing sizes, that if you have mixed sizes it will overflow<br> <ydaniv> ... all intrisic will prevent overflow, makes sense?<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/10915<br> <ydaniv> almaher: I'll need to see an example<br> <ydaniv> fantasai: there's one on the issue<br> <fantasai> Item is 300px wide. Track listing is repeated of 100px + auto<br> <ydaniv> ... example is 1 is 100px wide and auto<br> <ydaniv> ... it might end up being to small and overflow<br> <ydaniv> ... <missed example><br> <ydaniv> ... problem will occur if you have many to repeat and no extra space<br> <ydaniv> oriol: can you post this? a bit lost<br> <ydaniv> fantasai: [giving example]<br> <fantasai> 500px wide container<br> <fantasai> 300px-wide items (one or many)<br> <fantasai> Track listing is repeat(auto-fill, 100px auto)<br> <fantasai> Items span 2 columns<br> <fantasai> We assume the item contribution is 150px (300px/2) for the auto tracks<br> <ydaniv> fantasai: we assume that item conrtibution is 300px<br> <ydaniv> almaher: so end up with one repeat and then overflow<br> <ydaniv> fantasai: I think this is the track listing for repeat, do we want to have the same for grid?<br> <ydaniv> ... I'd argue we have same heuristic<br> <ydaniv> ... could have wierd behavior if <missed><br> <ydaniv> ... in most cases people would use it won't be a problem<br> <alisonmaher> q+<br> <astearns> ack alisonmaher<br> <ydaniv> ... and could switch between layout they want, so proposing to ahve the same for grid, would be more consistent than disallowing<br> <ydaniv> almaher: could be a footgun for perf, since it's multi pass already, if we allow this for users<br> <oriol> q+<br> <ydaniv> alisonmaher: the big problem here is preformance<br> <astearns> ack oriol<br> <ydaniv> oriol: a bit lost here, what was that heuristic we applied? and also that it could behave weird in grid, can you explain?<br> <ydaniv> fantasai: heuristic is we take one repeation. then assume that every item occurs in every track, but for those that span mutiple we divide by span and get some auto size for that<br> <ydaniv> alisonmaher: it could lead to some weirdness in cases where ordering is different. works good for masonry but not for grid<br> <ydaniv> fantasai: in masonry you need a size to repeat, but in grid you do cols, rows, cols, rows<br> <ydaniv> ... you take a few shortcuts to find the size for repeattion<br> <ydaniv> ... this is a temp size we're using to figure how many tracks we need to fit<br> <astearns> ack fantasai<br> <ydaniv> ... I think that would work for both cases<br> <ydaniv> astearns: are we resolving or taking back to issue?<br> <ydaniv> alisonmaher: perhaps resolve first for masonry? and later gird?<br> <ydaniv> fantasai: yea<br> <ydaniv> alisonmaher: using the heuristic in the spec for masonry<br> <ydaniv> PROPOSED RESOLUTION: accept the heuristic in the spec just for masonry<br> <ydaniv> astearns: objections?<br> <ydaniv> RESOLVED: accept the heuristic in the spec just for masonry<br> <ydaniv> astearns: proposing another masonry breakout on the 15th<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-3357091876 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 October 2025 16:01:29 UTC