W3C home > Mailing lists > Public > www-style@w3.org > January 2016

Re: [css-grid] Resolve Intrinsic Track Sizes: min-content vs auto minimums

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 21 Jan 2016 11:35:54 -0800
To: Sergio Villar Senin <svillar@igalia.com>, www-style@w3.org
Message-ID: <56A1331A.3010806@inkedblade.net>
On 01/21/2016 01:00 AM, Sergio Villar Senin wrote:
> On 21/01/16 04:30, fantasai wrote:
>>
>>> 3) width: auto; min-width: 0px;
>>> 3.A) grid-template-columns: auto;        => Column's width: 0px;
>>> 3.B) grid-template-columns: min-content; => Column's width: 50px;
>>
>> Not 100% sure on 3.A. It might be 50px. 'auto' as a size generally
>> passes down any min/max-content constraints, and passes up through
>> it the min/max-content contribution. The min-content contribution
>> of the grid item is still 50px, even if its min-width is zero.
>
> In order to be consistent with the other use cases I think it should be
> 0px (that's how it works also in Blink and WebKit), you even said it in
> a reply to Mats:
>
> "If all items in a grid track have 'width: auto; min-width: 0',
> then an 'auto' track size will result in a base track size of 0."

Well, yes, but the issue here that's interesting is that we're sizing
the grid under a min-content constraint. If this was a floated block
container with a min-width of zero, its min-content size will nonetheless
be 50px. Meaning, you can make the float zero-width, and its content will
overflow, but if you ask it to shrink-to-fit into a small space, it will
refuse to get smaller than 50px. The grid container should probably behave
consistently with that, at least in the case of a single 'auto' track.

So I think we might want to special case either the base size calculation
or the "grow tracks to max" calculation in order to bring the track up to
its min-content size when sized under a min-content constraint.

(Not 100% sure atm, but that's what I'm thinking.)

~fantasai
Received on Thursday, 21 January 2016 19:36:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:34 UTC