Re: [css-grid] Initial review of the rewritten layout algorithm

On 02/28/2014 04:35 AM, Simon Sapin wrote:
> Hi,
> Here are some random comments and questions based on reading
>> Each track has a minimum and a maximum sizing function (which may be
>> the same).
> Please explain (with appropriate cross-referenced links) in the
> definition of grid-template-columns and grid-template-rows how
> these are determined.

Ok, this is in the spec now. It may get shuffled around, but should
hopefully not be lost. :)

>> A fixed size (<length> or resolved <percentage>).
> How are percentages resolved? The refer to the size of the grid container,
> but is that determined by the time we run this algorithm?

If it's not, then it's treated as 'auto' per

   # If the measure or extent of the grid container is an indefinite size,
   # <percentage> values relative to that size are treated as auto.

>> 11.1 Initialize Minimum and Maximum Track Sizes
>> For fixed track sizes, use that resolved size.
>> [...]
> What are the different things being manipulated here? Reading between the lines, I’m guessing that each track has:
> * A pair (min and max) of sizing functions which are constant inputs to this algorithm. Each of these is a fixed size,
> intrinsic size, or a flexible size.
> * A pair (also min and max) of "track sizes" (which perhaps deserve a more specific name) that are initialized here and
> modified several times in the rest of the algorithm. Each of these is a (potentially infinite) length.
> In other words, please define explicitly the "data structures" used in the algorithm.

Ok, we've got some terms. This should all be clearer now.
(Better terms accepted, however.)

>> Set any 'min-content' track size to the maximum of their min-size
>> contributions.
> This (and several other places in the algorithm) seems to confuse a sizing function that can be 'min-content', and the
> corresponding "track size" being set which is a length.

Should be expanded out a bit better now...

>> Subtract the corresponding (non-infinite) sizes of all spanned tracks
>> from its size contribution to find the item’s remaining size
>> contribution. This is the space to distribute.
>> extra-space = size-contribution - ∑track-sizes
> Are the "corresponding sizes" those of all spanned tracks, or only
> these with the intrinsic sizing function (min-content or max-content)
> relevant to this run of the "distribute extra space" sub-algorithm?

All of them. It says "all", doesn't it? :)

>> Distribute the space evenly to the tracked increase of each spanned
>> track with an affected size, dropping maxed-out tracks as they hit
>> their maximums.
>> track-size-increase = max(track-size-increase, share-of-extra-space)
> What does "maxed-out track" mean? Is it something like
> "track size + planned increase > fixed size sizing function" ?

Yes. Clarified.

> What does "dropping maxed-out tracks as they hit their maximums" mean?

Switched terminology to solid state changes. Maxing out is too
slangy for specs, apparently. :P

> How exactly is share-of-extra-space determined? Is it always extra-space
> divided number of "corresponding sizes", or is it affected by
> "maxed-out tracks"?

If you imagine this as a continuous process of pouring space into
growable tracks rather than a one-step calculation, it will make
more sense. I'm not sure how to convey that in the spec, though.
(Although the current wording probably implies that more strongly
than the previous wording.)

>> If space remains after all tracks max out, continue to increase…
>> for min-content minimum sizes, any affected tracks that happen to
>> also have intrinsic maximum sizes; else all affected tracks.
>> for max-content minimum sizes, any affected tracks that happen to
>> also have max-content maximum sizes; else all affected tracks.
>> for intrinsic maximum sizes, all affected tracks
> I don’t understand what any of this means, sorry.

Ok, tried rewording a bit.

Try now?


Received on Thursday, 17 April 2014 21:14:46 UTC