W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2017

Re: [csswg-drafts] [css-grid] Doubts regarding implied minimum size of images

From: fantasai via GitHub <sysbot+gh@w3.org>
Date: Thu, 30 Mar 2017 21:35:22 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-290551887-1490909720-sysbot+gh@w3.org>
After some thought, @tabatkins and I think we found what's wrong in the spec, and how to fix it.

With respect to examples 1/2/5/6:

Grid is using the same "automatic minimum size" algo that Flexbox does, which sets the min to the smaller of the content size and the specified/transferred size.  This is correct for Flexbox - it gives us a reasonable minimum size that the image won't shrink below.  But it serves a different purpose in Grid, effectively setting the layout size of the *track* while the item itself sizes into that containing block, potentially overflowing it. (Or, in other words, Flexbox actually sizes the item with the information; Grid sizes the track, and then the item lays itself out, and we don't want the item to overflow its track by default.)

Therefore, in Grid it doesn't make as much sense to pay attention to the content size when a specified/transferred size exists. So, we think the right fix is to just change Grid's automatic minimum size to be the specified size if it exists, else the transferred size if it exists, else the content size.

This will make examples 1, 2, 5, and 6 all render basically the same way, with a 200px tall first row, and the image filling that row.  (Examples 3, 4, 7, and 8 rely on a different issue, so we won't worry about them here right now.) This gives more sensible results in size-constrained grids when the item's transferred size is larger than its content size, by keeping the contents of the track in sync and avoiding overlap of adjacent grid items.

Note: A similar consideration about overlapping overflow was used in [resolving issue 283](https://github.com/w3c/csswg-drafts/issues/283#issuecomment-268125974).

Refiling this particular issue as https://github.com/w3c/csswg-drafts/issues/1149

The second problem is in examples 3/4/7/8:

@mrego writes:
    
> ```
><div style="display: grid; width: 200px;">
>  <img style="width: 100%;" src="http://placehold.it/50x50">
> </div>
>```
> 
> Here to resolve the size of the auto column, we check our children.
> auto is somehow equivalent to minmax(auto, max-content).
> The image has width: 100%; which cannot be resolved as the column has auto size, so for the minimum track size we consider 0px. And we use 50px, the content size of the image as maximum track size. And for the row, we use 50px too (the content size of the image).
> Then the column size is affected by the default justify-content: stretch; which makes the auto column to grow up to 200px. The image is sized against that size of the column, so it ends up being 200x200. However the row is still 50px.

The problem here is that the row height of 50px is entirely unexpected. The author would expect this to behave similar to fr sizing: the content and the row height are calculated based on the stretched track size, not the initial track size.

The responsible spec prose is in https://drafts.csswg.org/css-grid/#algo-overview where `stretch` is processed at the end of the grid sizing algorithm. It should instead be integrated as a final step of track sizing, after fr sizing, in order to be looped into later track-sizing passes.

Refiling this issue as https://github.com/w3c/csswg-drafts/issues/1150

Please let us know if this seems to address all of the doubts or if we missed something. :)

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1117#issuecomment-290551887 using your GitHub account
Received on Thursday, 30 March 2017 21:35:28 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:30:30 UTC