Re: [css-grid] Grid Layout Algorithm Rewritten!

This looks much nicer, thanks! A few comments / questions:


In §10.3 Initialize Track Sizes:

> Initialize each track’s base size and growth limit. For each track,
> if the track’s min track sizing function is:
>
> * For fixed track sizes, resolve to an absolute length and use that
> size.

Use that size for both the initial base size and the initial growth limit?

Also, the "If XX is: / For YY, …" wording doesn’t really work. Maybe 
"Depending on XX: / For YY, …" or "If XX is: / A YY, …"

> * For intrinsic track sizes, use an initial base size of zero and an
> initial growth limit of infinity.
> * For flexible track sizes, use an initial base size of infinity.
>
> A track with a flexible minimum sizing function is treated exactly as
> if it had a fixed min track sizing function of zero; except when the
> grid container is being sized under a min-content constraint, in
> which case it is treated exactly as min-content.

Isn’t that paragraph in contradiction with the last bullet point above?

Do "<em>minimum</em> <i>sizing function</i>" and "<i>min track sizing 
function</i>" (in Bikeshed markup) refer to the same thing? If so, it 
may be preferable to use the same markup and cross-reference links.


In §10.4 Resolve Content-Based Track Sizing Functions:

> Note: […] This algorithm may be updated in the future to take into
> account more advanced heuristics as they are identified.

Hopefully I don’t need to, but I’ll point out that once web content 
starts to depend on this algorithm, we may not be able to change it 
without breaking something.


In the "Increase sizes to accommodate spanning items" sub-algorithm, the 
first sub-step has a bold label "For min-content minimums", but then 
affects tracks with either min-content or max-content minimums.

Same for the third sub-step "For min-content maximums".

It seems that it’s the labels that should be fixed, since the list is 
ordered and the order only matters if the sets of affected tracks are 
not disjoint.


> (This prevents the size increases from becoming order-dependent.)

Is this referring to the order of the grid items?


> Distribute the space equally to the planned increase of each spanned
> track with an affected size, freezing tracks as their planned size
> reaches their growth limits (and continuing to grow the unfrozen
> tracks as needed).

What does "their planned size reaches their growth limits" means when 
the affected size *is* the growth limit?

Also, I don’t quite understand what this freezing is about. The "as […] 
reaches" and "continuing" wording implies a flow of time, while CSS is 
stateless. I can guess what is intended by imagining pouring a fixed 
amount of liquid (extra space) into a number of buckets (tracks) at an 
equal rate, and stopping with a given bucket when it’s full (thus 
increasing the amount of remaining space-liquid for each of the 
remaining tracks-buckets.)

But I shouldn’t have to guess, and the spec perhaps shouldn’t use my 
liquid metaphor :)

I suppose the spec should spell out an iterative algorithm rather than 
try to condense it in one sentence with "freezing" tracks. It would 
possibly look like:

While extra-space > 0 and len(tracks) > 0:
   increase = min(
     extra-space / len(tracks),
     min(track.growth-limit - track.planned-increase
         for track in tracks))
   extra-space -= increase * len(tracks)
   for track in tracks:
     track.planned-increase += increase
     if track.planned-increase == track.growth-limit:
       remove track for tracks

The above is just my guess and may be wrong. And I’m sure it can be 
expressed more nicely :)


> If a track was marked as infinitely growable for this phase, treat
> its growth limit as infinite for this calculation (and then unmark
> it).

The earlier occurrence of "infinitely growable" should be a <dfn>, and 
this one should link to it.

> (If the growth limit is infinite, set it to the track’s base size
> plus the calculated increase.)

Does this apply always, or only when the affected size is a growth limit?

> At this point, all intrinsic base sizes and growth limits will have
> been resolved to absolute lengths.

Is "this point" the end of a single invocation of "distribute extra 
space", or the end of "Resolve Content-Based Track Sizing Function"?


In §10.5 Grow All Tracks To Their Max
> If the free space is positive, distribute it equally to all tracks,
> freezing tracks as they reach their growth limits (and continuing to
> grow the unfrozen tracks as needed).

Same comment about "freezing" than above. Perhaps this could be a named 
sub-algorithm used in two places.


In §10.6.1 Find the Size of an fr
> Let leftover space be the space to fill minus the base sizes of all
> the non-flexible grid tracks.

Does "all the non-flexible grid tracks" mean all in the grid, or all in 
the input to this sub-algorithm? I suppose only the latter makes sense, 
but "all" is misleading. Perhaps just removing "all" is enough.

(Same for two occurrences of "all flexible tracks".)

> For all flexible tracks, if the product of the hypothetical flex
> fraction and the track’s flex factor is less than the track’s base
> size, restart this algorithm treating all such tracks as having a
> flex factor of zero.

Restart if *any* or *all* of the flexible tracks have a greater product 
than base size? Does "such" refer to all flexible tracks, or only those 
with a greater product?

-- 
Simon Sapin

Received on Friday, 25 April 2014 17:18:49 UTC