Brief   Full   Jump  

Small
Medium
Large

Teal
High contrast
Bluish
Black

Sans-serif
Serif
Monospaced
Close
d
?
Styles

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

12 messages.

[css-grid] Flexible Track Sizing & Indefinite Avail Size
François REMY   Wed, 27 Aug 2014 17:17:22 +0200

www-style > August 2014 > 0387.html

Received on Wednesday, 27 August 2014 15:17:59 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

Dear CSS Grid editors, I’m trying to understand the reasons behind the choice of the sizing algorithm of flexible tracks under no definite size constraint. As a reminder, please find quoted here the algorithm in question: # The used flex fraction is the maximum of: # # - Each flexible track’s base size divided by its flex factor. # # - The result of 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. # # For each flexible track, if the product of the used flex # fraction and the track’s flex factor is greater than the # track’s base size, set its base size to that product. While the reason behind the second set of constraints is obvious to me (we want flexible columns to at least encompass elements inside them, if we're free to give them any size we want), I'm not sure about the reason why the first set of constraints exist. Also, if the plan is to make the layout system stable for flex factors approaching zero (like flexbox), then this first set of constraints will be annoying (as a very small flex factor can create huge track breadths (with a smart epsilon/epsilon-squared pair of flex factor; see test case), while a 0 flex factor is identical to no flex at all which may result in collapsed columns). I'm genuinely interested in the reasoning that shaped the design of this algorithm, and would already find helpful any answer providing a partial answer. Best regards, François --------------------------------------------------------------------------------------- Test case on which people can experiment (in IE): <div style="display: -ms-grid; -ms-grid-columns: auto; -ms-grid-rows: minmax(30px, 0.01fr) minmax(30px, 0.1fr);"> <div style="background: green; min-height: 10px; min-width: 600px; -ms-grid-row: 1;"></div> <div style="background: lime; min-height: 10px; min-width: 600px; -ms-grid-row: 2;"></div> </div> In this example, the first element ends up 600x30px, the second one 600x300px. I don't see why both elements being 600x30px wouldn't be a more natural outcome.
Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size
"Tab Atkins Jr."   Tue, 16 Sep 2014 13:11:29 -0700

www-style > September 2014 > 0217.html

Received on Tuesday, 16 September 2014 20:12:16 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: francois.remy.dev@outlook.com
Copied to: www-style@w3.org.

On Wed, Aug 27, 2014 at 8:17 AM, François REMY <francois.remy.dev@outlook.com> wrote: > Dear CSS Grid editors, > > I’m trying to understand the reasons behind the choice of the sizing > algorithm of flexible tracks under no definite size constraint. As a > reminder, please find quoted here the algorithm in question: > > # The used flex fraction is the maximum of: > # > # - Each flexible track’s base size divided by its flex factor. > # > # - The result of 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. > # > # For each flexible track, if the product of the used flex > # fraction and the track’s flex factor is greater than the > # track’s base size, set its base size to that product. > > While the reason behind the second set of constraints is obvious to me (we > want flexible columns to at least encompass elements inside them, if we're > free to give them any size we want), I'm not sure about the reason why the > first set of constraints exist. Because it's a very direct translation of what Flexbox does, and so seems to make sense? What confuses you about it? > Also, if the plan is to make the layout system stable for flex factors > approaching zero (like flexbox), then this first set of constraints will be > annoying (as a very small flex factor can create huge track breadths (with a > smart epsilon/epsilon-squared pair of flex factor; see test case), while a 0 > flex factor is identical to no flex at all which may result in collapsed > columns). Nah, factors <1 get handled slightly differently to maintain proper behavior. It took me a bit to work it out, but it makes a lot of sense: Basically, you're asking each track "what size should we give an fr to make you maximally happy?". For elements with >=1fr, they want to fill the available space, so their answer is just the available space divided by their fr value, so that when things multiply back out, they're exactly filling the space, as desired. For elements with <1 fr, they want to fill a *fraction* of the space, not the whole thing; thus, they want 1fr to equal the available space, so that when things multiply back out, they're filling the desired fraction of the space, as desired. So, when you're reversing the flex constraints, such as here, you can basically just treat factors <1 as being equal to 1. This works all the way down to 0fr. > I'm genuinely interested in the reasoning that shaped the design of this > algorithm, and would already find helpful any answer providing a partial > answer. fantasai and I didn't actually write this part; most of the layout algorithm is straight from the original MS publication of the spec. That said, I think it makes sense. ~TJ
RE: [css-grid] Flexible Track Sizing & Indefinite Avail Size
François REMY   Tue, 16 Sep 2014 23:22:47 +0200

www-style > September 2014 > 0222.html

Received on Tuesday, 16 September 2014 21:23:20 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: www-style@w3.org.

>> # The used flex fraction is the maximum of: >> # - Each flexible track’s base size divided by its flex factor. >> Why? > > Because it's a very direct translation of what Flexbox > does, and so seems to make sense? What confuses > you about it? I don't see how this is similar to what is defined about flexboxes, but maybe I'm just too unfamiliar with it. I never played with the basis size very much. Just to confirm, let's take an example: If, out of two columns in a grid with no child item, I specify a minimum width for the first column to be 100px, but say that it should take 10% of the free space (i.e. minmax(100px, 1fr)) while the other one gets the remaining 90% (9fr) of the free space. Under a size constraint, there are two possible behaviors for this grid: if its size is less than 1000px, it will work like (100px 1fr), in the other cases, it will work like (1fr 9fr). When I position this grid absolutely, I don't expect it to reach a width of 1000px (=1*100px+9*100px since 1fr=max(100px/1, 0px/9)), but I would rather see it stay at 100px and let the value of 1fr be 0px (this is the smallest fraction that satisfies all max-content constraints).
Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size
"Tab Atkins Jr."   Tue, 16 Sep 2014 15:11:51 -0700

www-style > September 2014 > 0224.html

Received on Tuesday, 16 September 2014 22:12:38 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: francois.remy.dev@outlook.com
Copied to: www-style@w3.org.

On Tue, Sep 16, 2014 at 2:22 PM, François REMY <francois.remy.dev@outlook.com> wrote: >>> # The used flex fraction is the maximum of: >>> # - Each flexible track’s base size divided by its flex factor. >>> Why? >> >> Because it's a very direct translation of what Flexbox >> does, and so seems to make sense? What confuses >> you about it? > > I don't see how this is similar to what is defined about flexboxes, but maybe I'm just too unfamiliar with it. I never played with the basis size very much. > > Just to confirm, let's take an example: If, out of two columns in a grid with no child item, I specify a minimum width for the first column to be 100px, but say that it should take 10% of the free space (i.e. minmax(100px, 1fr)) while the other one gets the remaining 90% (9fr) of the free space. > > Under a size constraint, there are two possible behaviors for this grid: if its size is less than 1000px, it will work like (100px 1fr), in the other cases, it will work like (1fr 9fr). > > When I position this grid absolutely, I don't expect it to reach a width of 1000px (=1*100px+9*100px since 1fr=max(100px/1, 0px/9)), but I would rather see it stay at 100px and let the value of 1fr be 0px (this is the smallest fraction that satisfies all max-content constraints). Why not? Assume that the two columns are just 1fr and 9fr, no min size, and the first column has an item that's 100px wide. You'd expect the grid to be 1000px wide then, right? Fundamentally, Grid tries to reverse the flex relationships to preserve the intention; this is a bit different from Flexbox. (Note also that optimizing for empty grids isn't useful.) ~TJ
RE: [css-grid] Flexible Track Sizing & Indefinite Avail Size
François REMY   Wed, 17 Sep 2014 18:26:00 +0200

www-style > September 2014 > 0232.html

Received on Wednesday, 17 September 2014 16:26:33 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: www-style@w3.org.

> Why not? Assume that the two columns are just > 1fr and 9fr, no min size, and the first column has > an item that's 100px wide. You'd expect the grid > to be 1000px wide then, right? Fundamentally, > Grid tries to reverse the flex relationships to > preserve the intention; this is a bit different from > Flexbox. Okay. That is not what I thought to be natural, but I can understand the reasoning.
Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size
fantasai   Thu, 18 Dec 2014 15:11:53 -0800

www-style > December 2014 > 0317.html

Received on Thursday, 18 December 2014 23:12:22 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 09/17/2014 09:26 AM, François REMY wrote: >> Why not? Assume that the two columns are just >> 1fr and 9fr, no min size, and the first column has >> an item that's 100px wide. You'd expect the grid >> to be 1000px wide then, right? Fundamentally, >> Grid tries to reverse the flex relationships to >> preserve the intention; this is a bit different from >> Flexbox. > > Okay. That is not what I thought to be natural, but I can understand the reasoning. Actually, Flexbox does this as well. See the definition of max-content size for flex containers: http://www.w3.org/TR/css3-flexbox/#intrinsic-sizes (This is a relatively recent update; we noticed the error in the last cycle. But think if we didn't calculate it this way, the flex container would size itself to 100px and then only 10px would be allocated to the 100px item, and that's bad.) ~fantasai
Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size
Javier Fernandez   Thu, 03 Sep 2015 01:58:25 +0200

www-style > September 2015 > 0018.html

Received on Thursday, 3 September 2015 00:37:28 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com, francois.remy.dev@outlook.com
Copied to: www-style@w3.org.

Hi, Sorry for bringing back an old thread, but I've been recently beaten by a bug in chrome pretty related to this discussion, so I think it was good idea to continue here. On 09/16/2014 10:11 PM, Tab Atkins Jr. wrote: > On Wed, Aug 27, 2014 at 8:17 AM, François REMY > <francois.remy.dev@outlook.com> wrote: >> Dear CSS Grid editors, >> >> I’m trying to understand the reasons behind the choice of the sizing >> algorithm of flexible tracks under no definite size constraint. As a >> reminder, please find quoted here the algorithm in question: >> >> # The used flex fraction is the maximum of: >> # >> # - Each flexible track’s base size divided by its flex factor. >> # >> # - The result of 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. >> # >> Also, if the plan is to make the layout system stable for flex factors >> approaching zero (like flexbox), then this first set of constraints will be >> annoying (as a very small flex factor can create huge track breadths (with a >> smart epsilon/epsilon-squared pair of flex factor; see test case), while a 0 >> flex factor is identical to no flex at all which may result in collapsed >> columns). > > Nah, factors <1 get handled slightly differently to maintain proper > behavior. It took me a bit to work it out, but it makes a lot of > sense: I understand that this idea fits perfectly when dealing with flexible tracks in a definite sized container, because we indeed want either to fill or fraction proportionally (based on the flex factors) the *available space*. However, in the case of indefinite containers, there is no such "available space to fill or fraction". The spec precisely states to use the value 1 instead of the sum of factors when trying to "find the size of a fr", but not when considering the "track’s base size divided by its flex factor" value. We want the maximum of these values to be considered as "used flex fraction", so assuming a value of 1 for all the tracks with <1fr won't allow us to keep proportions between them (we will get always their baseSize as it will be bigger) and between >1fr tracks. 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) * 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. * Issue2: When using 1 as value for <1fr, the results are not proportional, since track2 might be 4x. * 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". > > Basically, you're asking each track "what size should we give an fr to > make you maximally happy?". For elements with >=1fr, they want to > fill the available space, so their answer is just the available space > divided by their fr value, so that when things multiply back out, > they're exactly filling the space, as desired. For elements with <1 > fr, they want to fill a *fraction* of the space, not the whole thing; > thus, they want 1fr to equal the available space, so that when things > multiply back out, they're filling the desired fraction of the space, > as desired. Actually, there is another sentence in the spec that makes me wonder if this applies to indefinite sized containers: "When the available space is infinite (which happens when the grid container’s width or height is indefinite), flex-sized grid tracks are sized to their contents while retaining their respective proportions. The used size of each flex-sized grid track is computed by determining the max-content size of each flex-sized grid track and dividing that size by the respective flex factor to determine a “hypothetical 1fr size”. The maximum of those is used as the resolved 1fr length (the flex fraction), which is then multiplied by each grid track’s flex factor to determine its final size." 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". BR -- Javi
Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size
"Tab Atkins Jr."   Fri, 4 Sep 2015 11:03:53 -0700

www-style > September 2015 > 0032.html

Received on Friday, 4 September 2015 18:04:42 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jfernandez@igalia.com
Copied to: francois.remy.dev@outlook.com, www-style@w3.org.

On Wed, Sep 2, 2015 at 4:58 PM, Javier Fernandez <jfernandez@igalia.com> wrote: > On 09/16/2014 10:11 PM, Tab Atkins Jr. wrote: >> On Wed, Aug 27, 2014 at 8:17 AM, François REMY >> <francois.remy.dev@outlook.com> wrote: >>> Dear CSS Grid editors, >>> >>> I’m trying to understand the reasons behind the choice of the sizing >>> algorithm of flexible tracks under no definite size constraint. As a >>> reminder, please find quoted here the algorithm in question: >>> >>> # The used flex fraction is the maximum of: >>> # >>> # - Each flexible track’s base size divided by its flex factor. >>> # >>> # - The result of 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. >>> # >>> Also, if the plan is to make the layout system stable for flex factors >>> approaching zero (like flexbox), then this first set of constraints will be >>> annoying (as a very small flex factor can create huge track breadths (with a >>> smart epsilon/epsilon-squared pair of flex factor; see test case), while a 0 >>> flex factor is identical to no flex at all which may result in collapsed >>> columns). >> >> Nah, factors <1 get handled slightly differently to maintain proper >> behavior. It took me a bit to work it out, but it makes a lot of >> sense: > > I understand that this idea fits perfectly when dealing with flexible > tracks in > a definite sized container, because we indeed want either to fill or > fraction > proportionally (based on the flex factors) the *available space*. > However, in > the case of indefinite containers, there is no such "available space to > fill or > fraction". > > The spec precisely states to use the value 1 instead of the sum of factors > when trying to "find the size of a fr", but not when considering the > "track’s > base size divided by its flex factor" value. We want the maximum of these > values to be considered as "used flex fraction", so assuming a value of 1 > for all the tracks with <1fr won't allow us to keep proportions between > them (we will get always their baseSize as it will be bigger) and between >>1fr tracks. > > 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. > * 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. > * 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): * 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. > * 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. >> Basically, you're asking each track "what size should we give an fr to >> make you maximally happy?". For elements with >=1fr, they want to >> fill the available space, so their answer is just the available space >> divided by their fr value, so that when things multiply back out, >> they're exactly filling the space, as desired. For elements with <1 >> fr, they want to fill a *fraction* of the space, not the whole thing; >> thus, they want 1fr to equal the available space, so that when things >> multiply back out, they're filling the desired fraction of the space, >> as desired. > > Actually, there is another sentence in the spec that makes me wonder > if this applies to indefinite sized containers: > > "When the available space is infinite (which happens when the grid > container’s width or height is indefinite), flex-sized grid tracks are > sized to their contents while retaining their respective proportions. > The used size of each flex-sized grid track is computed by determining > the max-content size of each flex-sized grid track and dividing that > size by the respective flex factor to determine a “hypothetical 1fr > size”. The maximum of those is used as the resolved 1fr length (the flex > fraction), which is then multiplied by each grid track’s flex factor to > determine its final size." > > 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: I'll edit the spec to make the "indefinite" clause also clamp to 1. ~TJ
Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size
Javier Fernandez   Fri, 04 Sep 2015 23:07:49 +0200

www-style > September 2015 > 0035.html

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

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org, francois.remy.dev@outlook.com, jackalmage@gmail.com.

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
Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size
fantasai   Fri, 4 Sep 2015 17:20:18 -0400

www-style > September 2015 > 0036.html

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

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com, jfernandez@igalia.com
Copied to: francois.remy.dev@outlook.com, www-style@w3.org.

On 09/04/2015 02:03 PM, Tab Atkins Jr. wrote: > On Wed, Sep 2, 2015 at 4:58 PM, Javier Fernandez <jfernandez@igalia.com> wrote: >> On 09/16/2014 10:11 PM, Tab Atkins Jr. wrote: >>> >>> Basically, you're asking each track "what size should we give an fr to >>> make you maximally happy?". For elements with >=1fr, they want to >>> fill the available space, so their answer is just the available space >>> divided by their fr value, so that when things multiply back out, >>> they're exactly filling the space, as desired. For elements with <1 >>> fr, they want to fill a *fraction* of the space, not the whole thing; >>> thus, they want 1fr to equal the available space, so that when things >>> multiply back out, they're filling the desired fraction of the space, >>> as desired. >> >> Actually, there is another sentence in the spec that makes me wonder >> if this applies to indefinite sized containers: >> >> "When the available space is infinite (which happens when the grid >> container’s width or height is indefinite), flex-sized grid tracks are >> sized to their contents while retaining their respective proportions. >> The used size of each flex-sized grid track is computed by determining >> the max-content size of each flex-sized grid track and dividing that >> size by the respective flex factor to determine a “hypothetical 1fr >> size”. The maximum of those is used as the resolved 1fr length (the flex >> fraction), which is then multiplied by each grid track’s flex factor to >> determine its final size." >> >> 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: I'll edit the spec to make the "indefinite" clause also clamp to 1. I'm not sure what exactly is the edit you're proposing, but I suspect it's wrong to clamp anything to 1. What should be happening here is the same that's happening in Flexbox: https://drafts.csswg.org/css-flexbox-1/#intrinsic-sizes ~fantasai
Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size
"Tab Atkins Jr."   Fri, 4 Sep 2015 14:24:26 -0700

www-style > September 2015 > 0039.html

Received on Friday, 4 September 2015 21:25:17 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net
Copied to: jfernandez@igalia.com, francois.remy.dev@outlook.com, www-style@w3.org.

On Fri, Sep 4, 2015 at 2:20 PM, fantasai <fantasai.lists@inkedblade.net> wrote: > I'm not sure what exactly is the edit you're proposing, but I suspect > it's wrong to clamp anything to 1. What should be happening here is > the same that's happening in Flexbox: > https://drafts.csswg.org/css-flexbox-1/#intrinsic-sizes This is just finding how large an fr should be if the available space is indefinite. ~TJ
Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size
fantasai   Fri, 4 Sep 2015 23:58:24 -0400

www-style > September 2015 > 0044.html

Received on Saturday, 5 September 2015 03:59:11 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: jfernandez@igalia.com, francois.remy.dev@outlook.com, www-style@w3.org.

On 09/04/2015 05:24 PM, Tab Atkins Jr. wrote: > On Fri, Sep 4, 2015 at 2:20 PM, fantasai <fantasai.lists@inkedblade.net> wrote: >> I'm not sure what exactly is the edit you're proposing, but I suspect >> it's wrong to clamp anything to 1. What should be happening here is >> the same that's happening in Flexbox: >> https://drafts.csswg.org/css-flexbox-1/#intrinsic-sizes > > This is just finding how large an fr should be if the available space > is indefinite. Well, yeah. Although now I think it's Flexbox that has it wrong, and we should still be clamping the factor 1 in step 1 of https://drafts.csswg.org/css-flexbox-1/#intrinsic-sizes ~fantasai