- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 19 Aug 2025 07:38:31 +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`. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> alisonmaher: this is about a new functionality we're proposing for masonry track definitions<br> <kbabbitt> ... add intrinsic sizes to repeat auto-fill auto fit track defs<br> <kbabbitt> ... reason it's possible with masonry is it places items in different order in grid<br> <kbabbitt> ... so we're able to have a good heuristic for handling intrinsic repeaters<br> <kbabbitt> ... raised this issue to see if it's something we should add to spec<br> <kbabbitt> ... and what it means for grid<br> <kbabbitt> ... since we agreed to reuse grid-template properties we want it to do something in grid<br> <kbabbitt> ... but can't do same thing as masonry in all cases<br> <kbabbitt> ... one potential option is to resolve repeats in grid to only repeat intrinsic sizes once<br> <kbabbitt> ... and in masonry do what's in spec<br> <astearns> ack fantasai1<br> <kbabbitt> fantasai1: I think it would be good to do something a little more useful<br> <astearns> ack fantasai<br> <kbabbitt> ... we could for example reuse the same concept of place everything everywhere to figure out track count<br> <kbabbitt> ... it would then size differently one you actually put stuff into tracks<br> <kbabbitt> ... but for many use cases that might be fine<br> <kbabbitt> ... it would not be ideal but might be acceptable for typical use cases that are unlikely to...<br> <kbabbitt> alisonmaher: so you propose to have similar placement to masonry<br> <kbabbitt> fantasai1: that's one possibility<br> <kbabbitt> ... other thing it could do is introduce some kind of keyword that says, pretend we have all items, and then do auto<br> <kbabbitt> ... auto all the things, min-intrinsic, max-intrinsic<br> <kbabbitt> ... then use same sizing<br> <kbabbitt> ... because it's weird that you get a different behavior in repeat than outside it<br> <kbabbitt> ... I think the issue was originally, do we have this at all<br> <kbabbitt> alisonmaher: yes, is this useful in grid and masonry?<br> <kbabbitt> fantasai1: I think we were looking at use cases, we found some, for having this in masonry<br> <kbabbitt> ... not the common case<br> <kbabbitt> ... for a footer you want every item to fit without wrapping, but you want them all to be same size columns, this would give you that ability<br> <kbabbitt> ... usefulness of it in masonry vs grid is somewhat similar but limited use cases I think<br> <kbabbitt> alisonmaher: in implementing it, I think it works fairly well<br> <kbabbitt> ... actual algo does make sense, works well for masonry<br> <kbabbitt> ... open question I have is percentage handling<br> <kbabbitt> fantasai1: so maybe let's defer this question until we sort through rest?<br> <kbabbitt> alisonmaher: potentially yes<br> <kbabbitt> astearns: take this back to the issue for now?<br> <kbabbitt> ... you mentioned the use cases are slight for grid and maybe also slight for masonry<br> <kbabbitt> ... though more supported<br> <kbabbitt> fantasai1: potentially<br> <kbabbitt> alisonmaher: I think it also depends what we decide for default track definition<br> <kbabbitt> ... we;re proposing repeat(auto-fill, auto) as the default track definition for masonry in the grid direction<br> <kbabbitt> ... so if we do want that, we'd want to allow this in the first version of masonry<br> <astearns> s/though more supported/though more supported - could this be postponed to another level?/<br> <kbabbitt> astearns: that's enough on this issue for now?<br> <kbabbitt> fantasai1: yes, we'll get to all these questions beloe<br> <kbabbitt> s/beloe/below/<br> <kbabbitt> astearns: given that, and next issue is also a repeat issue, should we skip that issue?<br> <kbabbitt> fantasai1: let's go through issues on repeat stuff and see where we get to<br> <kbabbitt> astearns: ok let's move on<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-3199589165 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 07:38:32 UTC