- From: Alison Maher via GitHub <noreply@w3.org>
- Date: Fri, 01 Aug 2025 20:42:28 +0000
- To: public-css-archive@w3.org
alisonmaher has just created a new issue for https://github.com/w3c/csswg-drafts:
== [css-sizing-3][css-grid-3][Masonry] Compressible Replaced Elements ==
[yisibl](https://github.com/yisibl) [recently brought up](https://github.com/w3c/csswg-drafts/issues/12432#issuecomment-3095419852) the following case:
> Currently the img width in Chrome is equal to 0.5px, which is not expected anyway.
>
> <img width="1248" height="244" alt="Image" src="https://github.com/user-attachments/assets/60624553-8707-4362-8ac9-914eb79dd2ea" />
> <style>
> .box {
> display: masonry;
> item-tolerance: 0;
> grid-template-columns: repeat(auto-fill, auto);
> width: 600px;
> min-height: 20px;
> outline: 1px solid red;
> }
>
> img {
> width: 100%;
> height: auto;
> display: block;
> }
> </style>
I originally thought this rendering in Chromium was a bug, but @bfgeek mentioned this is expected per css-sizing-3 (specifically the section on [compressible replaced elements](https://drafts.csswg.org/css-sizing-3/#min-content-zero)).
As a result, this sort of scenario can be hit in Grid, for example, as well, but may be hit by authors more often in Masonry.
What ends up happening is that when we size the auto tracks to get the auto repeat track count for `repeat(auto-fill, auto`, we calculate the min content size for the images to 0. Then the tracks are sized according to this min-content size.
Should we consider not taking the min-content size when sizing the tracks, or consider other alternatives to the [compressible replaced elements](https://drafts.csswg.org/css-sizing-3/#min-content-zero) logic for Masonry (and Grid)?
cc: @tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12563 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 1 August 2025 20:42:29 UTC