- From: Alison Maher via GitHub <noreply@w3.org>
- Date: Fri, 15 Aug 2025 23:01:42 +0000
- To: public-css-archive@w3.org
Likely, the usefulness of this value for images comes down to [how we decide to resolve %'s](https://github.com/w3c/csswg-drafts/issues/12432) in this mode of track sizing. The initial proposal was to resolve %'s against the container, which would mean in the examples using `width: 100%` would produce one column filling out the entire container. I would argue this would give similar results to what you would get with the current default - which should lead an author to produce a different set of track definitions as they would today. The following demo is an example of how this works in Chromium today, which implements this as a prototype: https://developer.chrome.com/blog/masonry-update <img width="558" height="342" alt="Image" src="https://github.com/user-attachments/assets/609cc250-9905-46ec-851a-ee5f0b01344b" /> In this example, there is a div surrounding each image. The div has a `min-width` of 100px and the images have `width: 100%`. This produces a reasonable result. If the items are not % sized, or have some sort of intrinsic size from its content, like text, `repeat(auto-fill, auto)` would produce a better result out of the gate than the current default. As a result, I think `repeat(auto-fill, auto)` at worst produces the same result as the current definition for `none`, in other cases it produces a better initial result. In either case, there are times when an author will want to provide a different track sizing definition than the default provided, and I think that should be encouraged, but I don't see a reason to avoid providing a better default track sizing definition out of the gate if we can. -- GitHub Notification of comment by alisonmaher Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10869#issuecomment-3192963175 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 August 2025 23:01:43 UTC