- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 7 May 2015 14:47:41 -0700
- 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. ^_^ ~TJ
Received on Thursday, 7 May 2015 21:48:29 UTC