[css-grid] Implement fit-content track size

[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

From the parsing POV fit-content was implemented as a new type of function
which only takes one argument. That forced us to refactor some code because
minmax() was the only allowed function for <track-size>s so far.

The implementation key is a new attribute in GridTrack called growthLimitCap
which is precisely the attribute of fit-content(). Some parts of the track sizing
algorithm were adapted to this change like for example the sorting of tracks by
growth potential (we need to consider the caps).

BUG=618972
Committed: https://crrev.com/1993c05386140afe56921048784bf3ca449f4b63
Cr-Commit-Position: refs/heads/master@{#415676}

[svillar, 2016-08-29 10:29:52]

Description was changed from

==========
[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

R=cbiesinger@chromium.org, eae@chromium.org, jfernandez@igalia.com,
rego@igalia.com
==========

to

==========
[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

From the parsing POV fit-content was implemented as a new type of function which
only takes one argument. That forced us to refactor some code because minmax()
was the only allowed function for <track-size>s so far.

The implementation key is a new attribute in GridTrack called growthLimitCap
which is precisely the attribute of fit-content(). Some parts of the track
sizing algorithm were adapted to this change like for example the sorting of
tracks by growth potential (we need to consider the caps).
==========

[svillar, 2016-08-29 10:30:45]

Description was changed from

==========
[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

From the parsing POV fit-content was implemented as a new type of function which
only takes one argument. That forced us to refactor some code because minmax()
was the only allowed function for <track-size>s so far.

The implementation key is a new attribute in GridTrack called growthLimitCap
which is precisely the attribute of fit-content(). Some parts of the track
sizing algorithm were adapted to this change like for example the sorting of
tracks by growth potential (we need to consider the caps).
==========

to

==========
[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

From the parsing POV fit-content was implemented as a new type of function
which only takes one argument. That forced us to refactor some code because
minmax() was the only allowed function for <track-size>s so far.

The implementation key is a new attribute in GridTrack called growthLimitCap 
which is precisely the attribute of fit-content(). Some parts of the track
sizing 
algorithm were adapted to this change like for example the sorting of tracks by 
growth potential (we need to consider the caps).
==========

[eae, 2016-08-29 18:19:40]

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/LayoutGrid.cpp (right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:655: LayoutUnit maxSize =
std::max(LayoutUnit(), sizingData.availableSpace());
LayoutUnit maxSize = sizingData.availableSpace().clampNegativeToZero();

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:669: if
(!gridLength.hasPercentage() || hasDefiniteFreeSpace)
Where is percentage lengths handled?

[svillar, 2016-08-29 20:01:55]

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/LayoutGrid.cpp (right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:655: LayoutUnit maxSize =
std::max(LayoutUnit(), sizingData.availableSpace());
On 2016/08/29 18:19:40, eae wrote:
> LayoutUnit maxSize = sizingData.availableSpace().clampNegativeToZero();

Acknowledged.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:669: if
(!gridLength.hasPercentage() || hasDefiniteFreeSpace)
On 2016/08/29 18:19:40, eae wrote:
> Where is percentage lengths handled?

Precisely here. We only consider percentage lengths when we have a definite free
space.

[cbiesinger, 2016-08-29 20:07:08]

lgtm

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/style/GridTrackSize.h (right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/style/GridTrackSize.h:79: GridLength
maxTrackBreadth() const { return !isFitContent() ? m_maxTrackBreadth :
GridLength(Length(MaxContent)); }
please don't use negation like that, it's harder to read -- just to
isFitContent() ? GridLength(...) : m_MaxTrackBreadth

[eae, 2016-08-29 22:31:27]

Oh right, I misread it. Thanks for the clarificaiton!
LGTM

[Manuel Rego, 2016-08-31 07:24:29]

Please add a reference to bug #618972 in the description.

The patch looks good to me, but I don't fully understand the changes in
LayoutGrid::distributeSpaceToTracks(). Dunno if we could explain it better
in the description or if I need to read the spec with more detail.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html
(right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:13:
.fc0 { grid-template-columns: minmax(auto, 0px);}
The name of the class is not accurate (as it's not fit-content anymore)
I understand it's made to be the same than the one in the test file.

Anyway I'm wondering why you're not using "auto"
instead of "minmax(auto, 0px)"?

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:19:
.fc40x2 { grid-template-columns: repeat(2, minmax(auto, 40px)); }
You're not using this class and maybe other defined in this file.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:69:
<div class="grid fc0">
I guess "grid-template-columns: auto" could be enough here.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:74:
<div class="grid fc0x2">
Same here for "auto auto".

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:81:
<div class="grid fc40">
Maybe here "grid-template-columns: 40px" is more explicit.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:92:
<div class="grid" style="grid-template-columns: minmax(auto, 40px) auto;">
Why not "40px auto" instead of "minmax(auto, 40px) auto"?

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:99:
<div class="grid fc80">
And here maybe "80px".

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:104:
<div class="grid fc80x2">
This is confusing as you're using "repeat(2, minmax(auto, 80px))".
Only because the grid container is "100px",
this behaves the same than "repeat(2, fit-content(80px))",
and the columns have 55px each of them.

If we had "width: 200px" in the container the results would be:
* repeat(2, fit-content(80px)): 2 columns of 55px.
* repeat(2, minmax(auto, 80px)): 2 columns of 80px.

Using "auto auto" would be probably simpler.

IMHO it'd be nice if you can review the rest of the -expected file
and try to make it more explicit.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns.html
(right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns.html:60:
.thirdColumn { grid-column: 3 / 4; }
You can use "autoRowFirstColumn",
"autoRowSecondColumn" and "autoRowThirdColumn"
for these.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp (right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp:2932: return
result;
I'm wondering if it'd be nice to move this to a separated method,
as it's supposed that "fit-content()" will apply to any block in the future:
https://drafts.csswg.org/css-sizing-4/#valdef-width-fit-content-length-percen...

Of course this can be done later once that's implemented eventually.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/css/resolver/StyleBuilderConverter.cpp
(right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/css/resolver/StyleBuilderConverter.cpp:543: if
(function.functionType() == CSSValueFitContent)
Probably would be nice to add an assert to verify that it only has 1 argument:
    SECURITY_DCHECK(function.length() == 1);

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/LayoutGrid.cpp (right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:107: DCHECK(!growthLimitCap
|| *growthLimitCap >= 0);
Why you don't use growthLimitCap.value() here?

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:691:
track.setGrowthLimitCap(WTF::nullopt);
So I guess in one phase we ignore the limit for sorting,
but in other phases we use it (otherwise I don't understand
the changes in sortByGridTrackGrowthPotential().

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:1120: if
(track.growthLimit() == infinity)
Why this change?

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:1343: LayoutUnit
distanceToCap = track.growthLimitCap().value() - track.sizeDuringDistribution();
Nit: "distanceToCap"? Maybe better "sizeToCap".

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/style/GridTrackSize.h (right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/style/GridTrackSize.h:47: // them. The only
special case is fit-content(argument) which is similar to
minmax(auto,max-content)
Nit: Missing space after "auto,".

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/style/GridTrackSize.h:117: GridLength
m_maxTrackBreadth;
Probably it's good adding a comment to explain that this field
is used sometimes as m_maxTrackBreadth and other times
as m_fitContentCap.
I know it's already explained above but I think it doesn't harm.

Another option would be avoid to reuse m_maxTrackBreadth
for this and add a new attribute to this class, bur probably
it's not worth.

[svillar, 2016-08-31 09:50:05]

Thanks for the awesome review as usual.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html
(right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:69:
<div class="grid fc0">
On 2016/08/31 07:24:29, Manuel Rego wrote:
> I guess "grid-template-columns: auto" could be enough here.

In this case yes, but I'm using exactly the same names as in the original test
so it's easier to identify which one are we testing.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:74:
<div class="grid fc0x2">
On 2016/08/31 07:24:29, Manuel Rego wrote:
> Same here for "auto auto".

Ditto.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:81:
<div class="grid fc40">
On 2016/08/31 07:24:28, Manuel Rego wrote:
> Maybe here "grid-template-columns: 40px" is more explicit.

Ditto.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:92:
<div class="grid" style="grid-template-columns: minmax(auto, 40px) auto;">
On 2016/08/31 07:24:29, Manuel Rego wrote:
> Why not "40px auto" instead of "minmax(auto, 40px) auto"?

Because they are not the same. A 40px track is always 40px. In minmax(auto,
40px) you could get any value between auto and 40px (even higher than 40px if
the minimum size of the items are larger).

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns-expected.html:99:
<div class="grid fc80">
On 2016/08/31 07:24:28, Manuel Rego wrote:
> And here maybe "80px".

Ditto about using the exact same class names as in the test.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns.html
(right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/fast/css-grid-layout/fit-content-columns.html:60:
.thirdColumn { grid-column: 3 / 4; }
On 2016/08/31 07:24:29, Manuel Rego wrote:
> You can use "autoRowFirstColumn",
> "autoRowSecondColumn" and "autoRowThirdColumn"
> for these.

Acknowledged.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp (right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp:2932: return
result;
On 2016/08/31 07:24:29, Manuel Rego wrote:
> I'm wondering if it'd be nice to move this to a separated method,
> as it's supposed that "fit-content()" will apply to any block in the future:
>
https://drafts.csswg.org/css-sizing-4/#valdef-width-fit-content-length-percen...
> 
> Of course this can be done later once that's implemented eventually.

That's a good idea. Actually using consumeGridBreadth is not a good idea because
that allows the usage of some other things apart from lengths or percentages.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/css/resolver/StyleBuilderConverter.cpp
(right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/css/resolver/StyleBuilderConverter.cpp:543: if
(function.functionType() == CSSValueFitContent)
On 2016/08/31 07:24:29, Manuel Rego wrote:
> Probably would be nice to add an assert to verify that it only has 1 argument:
>     SECURITY_DCHECK(function.length() == 1);

Acknowledged.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/layout/LayoutGrid.cpp (right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:107: DCHECK(!growthLimitCap
|| *growthLimitCap >= 0);
On 2016/08/31 07:24:29, Manuel Rego wrote:
> Why you don't use growthLimitCap.value() here?

I can use it indeed, they're equivalent in any case.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:691:
track.setGrowthLimitCap(WTF::nullopt);
On 2016/08/31 07:24:29, Manuel Rego wrote:
> So I guess in one phase we ignore the limit for sorting,
> but in other phases we use it (otherwise I don't understand
> the changes in sortByGridTrackGrowthPotential().

While computing the sizes of content sized tracks we need to take caps into
account in order not to compute too large growth limits. But once the "resolve
content sized tracks" phase is over we should not use them because that could
lead to weird results.

It's easier to understand with one example. Imagine a single track with
fit-content(100px). Inside it we have an item with this contents: XX XX, so the
track will be (20, 50) after the "resolve content sized tracks" phase.

For the "Maximime Tracks" step we should consider that the track could only grow
30px. If we don't remove the cap, when sorting tracks by growth potential, the
sorting algorithm will think that the track could still grow 100px - 20px = 80px
which is not true.

Perhaps I could modify the sorting algorithm to take that into account (i.e. to
consider the track limit as the std::min(growthLimit, growthLimitCap)) and
remove this change.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/layout/LayoutGrid.cpp:1120: if
(track.growthLimit() == infinity)
On 2016/08/31 07:24:29, Manuel Rego wrote:
> Why this change?

Because growthLimitIsInfinite() is private now. I made it private because it was
only used here and I wanted to simplify the interface of GridTrack.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/style/GridTrackSize.h (right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/style/GridTrackSize.h:47: // them. The only
special case is fit-content(argument) which is similar to
minmax(auto,max-content)
On 2016/08/31 07:24:29, Manuel Rego wrote:
> Nit: Missing space after "auto,".

Acknowledged.

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/style/GridTrackSize.h:117: GridLength
m_maxTrackBreadth;
On 2016/08/31 07:24:29, Manuel Rego wrote:
> Probably it's good adding a comment to explain that this field
> is used sometimes as m_maxTrackBreadth and other times
> as m_fitContentCap.
> I know it's already explained above but I think it doesn't harm.

As you know it's in the policy of the project not to add comments unless
strictly needed because they usually became obsolete and misleading as nobody
updates them. As you mentioned is already explained above.

[svillar, 2016-08-31 10:14:19]

Description was changed from

==========
[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

From the parsing POV fit-content was implemented as a new type of function
which only takes one argument. That forced us to refactor some code because
minmax() was the only allowed function for <track-size>s so far.

The implementation key is a new attribute in GridTrack called growthLimitCap 
which is precisely the attribute of fit-content(). Some parts of the track
sizing 
algorithm were adapted to this change like for example the sorting of tracks by 
growth potential (we need to consider the caps).
==========

to

==========
[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

From the parsing POV fit-content was implemented as a new type of function
which only takes one argument. That forced us to refactor some code because
minmax() was the only allowed function for <track-size>s so far.

The implementation key is a new attribute in GridTrack called growthLimitCap 
which is precisely the attribute of fit-content(). Some parts of the track
sizing 
algorithm were adapted to this change like for example the sorting of tracks by 
growth potential (we need to consider the caps).

BUG=618972
==========

[cbiesinger, 2016-08-31 15:18:44]

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/style/GridTrackSize.h (right):

https://codereview.chromium.org/2287113004/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/style/GridTrackSize.h:117: GridLength
m_maxTrackBreadth;
On 2016/08/31 09:50:04, svillar wrote:
> On 2016/08/31 07:24:29, Manuel Rego wrote:
> > Probably it's good adding a comment to explain that this field
> > is used sometimes as m_maxTrackBreadth and other times
> > as m_fitContentCap.
> > I know it's already explained above but I think it doesn't harm.
> 
> As you know it's in the policy of the project not to add comments unless
> strictly needed because they usually became obsolete and misleading as nobody
> updates them. As you mentioned is already explained above.

FWIW, I really don't think that's the policy in blink, unlike webkit.

[svillar, 2016-08-31 15:42:55]

The CQ bit was checked by svillar@igalia.com

[svillar, 2016-08-31 15:42:55]

The patchset sent to the CQ was uploaded after l-g-t-m from
cbiesinger@chromium.org, eae@chromium.org
Link to the patchset: https://codereview.chromium.org/2287113004/#ps20001
(title: "Patch for landing")

[commit-bot: I haz the power, 2016-08-31 15:43:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 17:40:38]

Description was changed from

==========
[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

From the parsing POV fit-content was implemented as a new type of function
which only takes one argument. That forced us to refactor some code because
minmax() was the only allowed function for <track-size>s so far.

The implementation key is a new attribute in GridTrack called growthLimitCap 
which is precisely the attribute of fit-content(). Some parts of the track
sizing 
algorithm were adapted to this change like for example the sorting of tracks by 
growth potential (we need to consider the caps).

BUG=618972
==========

to

==========
[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

From the parsing POV fit-content was implemented as a new type of function
which only takes one argument. That forced us to refactor some code because
minmax() was the only allowed function for <track-size>s so far.

The implementation key is a new attribute in GridTrack called growthLimitCap 
which is precisely the attribute of fit-content(). Some parts of the track
sizing 
algorithm were adapted to this change like for example the sorting of tracks by 
growth potential (we need to consider the caps).

BUG=618972
==========

[commit-bot: I haz the power, 2016-08-31 17:40:39]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-08-31 17:43:13]

Description was changed from

==========
[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

From the parsing POV fit-content was implemented as a new type of function
which only takes one argument. That forced us to refactor some code because
minmax() was the only allowed function for <track-size>s so far.

The implementation key is a new attribute in GridTrack called growthLimitCap 
which is precisely the attribute of fit-content(). Some parts of the track
sizing 
algorithm were adapted to this change like for example the sorting of tracks by 
growth potential (we need to consider the caps).

BUG=618972
==========

to

==========
[css-grid] Implement fit-content track size

This CL implements the new <fit-content> track size which is defined as
follows: "Represents the formula min(max-content, max(auto, argument)),
which is calculated similar to auto (i.e. minmax(auto, max-content)), except
that the track size is clamped at argument if it is greater than the auto
minimum."

From the parsing POV fit-content was implemented as a new type of function
which only takes one argument. That forced us to refactor some code because
minmax() was the only allowed function for <track-size>s so far.

The implementation key is a new attribute in GridTrack called growthLimitCap
which is precisely the attribute of fit-content(). Some parts of the track
sizing
algorithm were adapted to this change like for example the sorting of tracks by
growth potential (we need to consider the caps).

BUG=618972

Committed: https://crrev.com/1993c05386140afe56921048784bf3ca449f4b63
Cr-Commit-Position: refs/heads/master@{#415676}
==========

[commit-bot: I haz the power, 2016-08-31 17:43:15]

Patchset 2 (id:??) landed as
https://crrev.com/1993c05386140afe56921048784bf3ca449f4b63
Cr-Commit-Position: refs/heads/master@{#415676}