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

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:
   https://hg.csswg.org/drafts/diff/78ad218000af/css-grid/Overview.bs

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

~fantasai and TJ

Received on Thursday, 21 January 2016 20:01:21 UTC