- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 07 Jul 2014 10:35:29 -0700
- To: Sergio Villar Senin <svillar@igalia.com>, www-style@w3.org
On 06/19/2014 08:20 AM, Sergio Villar Senin wrote:> > The issue pointed out by Simon is quite valid IMO and hasn't got any > response yet. Could it be clarified please? It looks like the > contradiction is pretty obvious unless I'm missing something also pretty > obvious :) Should be fixed. :) > FWIW before the rewrite the algorithm was using 0 unconditionally for > flex tracks. Yes. We realized this wouldn't work properly for things sized under a min-content constraint: a grid container sized to 1fr would shrink down to zero, when what's wanted is to fit everything in the smallest amount of space possible without overflow. We're not sure yet if this is the right way to solve that constraint, though. > Also "minimum" sizing function is not used at all in the rest of the > spec. Are we talking about the min track sizing function? If so I think > it would be better to replace the "minimum" word as it's confusing. Yep, fixed now. > I also have some extra questions about the paragraph bellow the bullets: > - when it says "is treated" does it refer to the initialization phase > only or does it mean that we should use the new min sizing function (0 > or min-content) for the rest of the algorithm? > - should it be considered only for the initialization phase then I guess > it can be simplified a lot since it will mean that either: > a) grid container is sized under min-content -> min sizing function > = min-content -> it's a content-dependent function -> initial base size > = 0 and grow limit = infinity > b) grid container is not sized under min-content -> min sizing > function = 0 We're not sure. We'll start a new thread for dealing with minimum sizes. (Digging into it more, we realize there are a lot of things to think about here.) ~fantasai and TJ
Received on Monday, 7 July 2014 17:36:02 UTC