W3C home > Mailing lists > Public > www-style@w3.org > May 2015

Re: [css-grid] About "infinitely growable" tracks in the sizing algorithm

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 7 May 2015 14:47:41 -0700
Message-ID: <CAAWBYDDWyDNCuc8E+cSqhgGf1dXjNKqhnq50_G7k5j8ypD5gxw@mail.gmail.com>
To: Sergio Villar Senin <svillar@igalia.com>
Cc: www-style list <www-style@w3.org>
On Tue, Feb 3, 2015 at 1:01 AM, Sergio Villar Senin <svillar@igalia.com> wrote:
> On 02/02/15 19:04, Peter Salas wrote:
>> Sergio Villar Senin wrote:
>>> I was lately wondering why we need this thing of "mark/unmark as infinitely
>>> growable"[1] step in the track sizing algorithm. I'm including some Microsoft
>>> folks on Cc because this comes from the initial algorithm. My point is, I think
>>> having something like this is useless as it does not add any specific new
>>> behavior to the algorithm. Let me explain why.
>>> The last two steps of "Increase sizes to accommodate spanning items"
>>> section are only run for those tracks whose max track sizing function is max-
>>> content (tracks with min-content as max track sizing function are only
>>> considered for the first of those two steps).
>>> So we have two possibilities when evaluating intrinsic maximums:
>>> 1- the growth limit does not change from infinite to finite: then the track is
>>> still infinitely growable for the last step and we don't need to mark anything
>>> as infinitely growable.
>>> 2- the growth limit changes from infinite to finite: in this case we don't need
>>> to mark anything as infinitely growable, because when evaluating the max-
>>> content maximums all those tracks will be eligible to grow beyond limits (as
>>> they're max-content) so they'll effectively behave as if they were infinitely
>>> growable.
>>> Am I missing something?
>> I think this is the same question that we discussed here:
>> http://lists.w3.org/Archives/Public/www-style/2014Mar/0512.html
>> Does that thread answer your question?
> It makes total sense and indeed answers my question. Thanks.

That link was embedded in a comment in the source, but I've gone ahead
and exposed it in a note in the draft, so it's visible to
implementors. ^_^

Received on Thursday, 7 May 2015 21:48:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC