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 12:00:47 -0800
To: Sergio Villar Senin <svillar@igalia.com>, www-style@w3.org, Manuel Rego Casasnovas <rego@igalia.com>, Mats Palmgren <matspal@gmail.com>
Message-ID: <56A138EF.6040408@inkedblade.net>
On 01/21/2016 11:35 AM, fantasai wrote:
> 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.)

Okay, Tab and I added this edit, which we think solves the problem:

Let us know if this seems to make sense. :)

~fantasai and TJ
Received on Thursday, 21 January 2016 20:01:21 UTC

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