Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size

Hi,

On 09/04/2015 08:03 PM, Tab Atkins Jr. wrote:
>>
>> I'll try to use an example now:
>>
>> .grid {
>>     display: grid;
>>     grid-template-columns: 50px;
>>     grid-template-rows: minmax(min-content, 0.5fr) minmax(18px, 2fr);
>>     font: 10px/1 Ahem;
>>    width: 50px;
>> }
>>
>> <div class="grid">
>>      <div class="firstRowFirstColumn">XXXXX XXXXX XXXXX XXXXX</div>
>>      <div class="secondRowFirstColumn" ></div>
>> </div>
>>
>> Let's focus on grid item's height, which is computed using the flex track
>> sizing algorithm when available space is indefinite:
>>
>> 1-First, find the used flex fraction:
>>   * Maximum of baseSize / factor for each flex track
>>     - track1: baseSize: 40px / factor: 0.5 = 200px
>>         + factor 1 => 40px
>>     - track2: baseSize: 18px / factor: 2 = 36px
>>     - max = 200px or 40px (depending on whether we assume or not a
>> factor value of 1)
> 
> Ignoring the obvious 200px typo (you meant 20px), you were supposed to
> *divide*, not multiply - you wrote down the equation correctly, just
> did the opposite operation.  So the answers are actually 80px/40px for
> track 1, and 9px for track 2.
> 

Yeah, too bad; sorry about that.
It's indeed 80px/40px for track1 and 9px for track2.

>>  * Maximum result when finding the size of an fr for each grid item that
>> crosses a flexible track, using all the grid tracks that the item
>> crosses and a space to fill of the item’s max-content contribution.
>>    - track1:
>>        + leftover space:  spaceToFill (40px) - base sizes of the
>> non-flexible tracks (0px) = 40px
>>        + flex factor sum: 0.5 < 1 => 1
>>        + hypothetical fr size: leftover space  / flex factor sum = 40px
>>        + hypothetical fr size * flexible track’s flex factor = 20px <
>> track’s base size (40px)
>>            - restart this algorithm treating all such tracks as inflexible.
>>   - track2
>>        + leftover space:  spaceToFill (0px) - base sizes of the
>> non-flexible tracks (0px) = 0px
>>        + flex factor sum: 2
>>        + hypothetical fr size: leftover space  / flex factor sum = 0px
>>        + hypothetical fr size * flexible track’s flex factor = 0px <
>> track’s base size (18px)
>>            - restart this algorithm treating all such tracks as inflexible.
>>
>> 2- If we use 1 as factor value for tracks with <1fr, the used used flex
>> fraction is 40px
>>    - track1: used flex fraction (40px) * flex factor (0.5) = 20px <
>> baseSize ( 40px ) => 40px
>>    - track2:  used flex fraction (40px) * flex factor (2) = 80px
>>
>> * Issue1: I'm not sure how to deal with the "restart", since there are
>> nor more flex tracks to process.
> 
> Then the flex factor sum is 0 (an empty sum is always 0), which gets
> corrected to 1, and the hypothetical fr size is set to the leftover
> space.
> 

Yes, well. The algorithm states that it's expected to have a group of
tracks and
an amount of space to fill. But it's ok, I understand. We were still
using the old
algorithm, which uses the baseSize of all the tracks (flex and non-flex) to
determine the leftover space. Is this new step really necessary ?

>> * Issue2: When using 1 as value for <1fr, the results are not
>> proportional, since track2 might be 4x.
> 
> Your math was off enough that I'm not sure what you're basing this off
> of.  Let's run through it (assuming we correct <1 to 1):
> 

I meant that track2 should be 4x of track1's size, but as you commented
below we accept breaking proportions to avoid exponential increasing when
using fraction factors. Fair enough.

> * First track yields an fr size of 40px.
> * Second track yields an fr size of 9px.
> * First item yields an fr size of 40px.
> * Second item yields an fr size of 0px.
> 
> So, the size of an fr is 40px.
> 
> * 40px*.5 is 20px, less than the first track's base size, so no change
> - it remains 40px.
> * 40px*2 is 80px, greater than the second track's base size, so its
> base size is set to 80px.
> 
> This does change the ratio, from 4x to 2x.  But that's okay!  If you'd
> used 5fr and 20fr, that would maintain a 4x ratio, but we're dealing
> with something below 1.  We don't want a .01fr item to make the entire
> thing blow up; in particular, a 0fr item doesn't influence the size of
> the fr *at all*, and we should make sure that the behavior approaches
> that in the limit.  That's what we get here; .5fr has a lesser effect
> on the size of the fr than it would naively appear.
> 

ok, understood.

>> * Issue3: If we don't use 1, we get the expected results, but then we
>> need a way to deal with division
>> by zero in the computation of " Maximum of baseSize / factor for each
>> flex track".
> 
> Division by zero isn't the only problem. ^_^ If the first track was
> .01fr, and we naively maintained ratios, it would make the second item
> 8000px tall.  That's an outcome we want to avoid.
> 

Yeah, I see. Thanks for the explanation, I haven't considered that case.

>>
>> The sentence **flex-sized grid tracks are sized to their contents while
>> retaining their respective proportions** make me think that we don't
>> want to fraction the content-sized space, just to make it bigger
>> proportionally, based on the flex factors. Hence, "0.1fr 0.2fr" should
>> produce the same results than "1fr 2fr".
> 
> Nah, we don't want that.
> 

So, perhaps the sentence **flex-sized grid tracks are sized to their
contents
while retaining their respective proportions** is not clear enough.

> So: I'll edit the spec to make the "indefinite" clause also clamp to 1.
> 

Thanks, that will help.

--
Javi

Received on Friday, 4 September 2015 21:08:20 UTC