- 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
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