New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-grid] Percentage tracks and indefinite sizes #1921

Open
mrego opened this Issue Oct 30, 2017 · 12 comments

Comments

Projects
None yet
7 participants
@mrego
Member

mrego commented Oct 30, 2017

This is an issue extracted from #509 (so we can leave #509 only for percentage gaps/gutters).

The behavior of percentage rows has been modified back in September to reflect a resolution from Seatle F2F meeting on January.
The new text of the spec says:

If the size of the grid container depends on the size of its tracks, then the <percentage> must be treated as auto, for the purpose of calculating the intrinsic sizes of the grid container and then resolve against that resulting grid container size for the purpose of laying out the grid and its items.

All the implementations have shipped the previous behavior (percentage rows are treated as auto and never resolved) and are interoperable regarding this. In addition, AFAIK nobody has updated them to follow the new behavior described in the spec.

At the same time we believe that implementing the new behavior might not be that easy, mainly because of the height is usually an output of the width, and you cannot do the same operations in both axis.

I've wrote a codepen trying to explain one of the issues which is the fact that we might need an extra pass of the track sizing algorithm to properly follow this resolution.

The problem is a combination of spanning items with percentage tracks.

  • Columns grid-template-columns: auto 10% auto
    We don't find issues here, during the intrinsic width computation the percentage is treated as auto. In the example the columns have 84px 324px 84px, so the intrinsic width is 492px.
    Status during intrinsic phase
    Then during the layout phase we resolve the percentage column against the intrinsic width, 10% of 492px which would be 49px, and the 1st and 3rd column are still auto so they grow as needed to fit the spanning item (final sizes are 221.5px 49px 221.5px).
    Final result after resolving the percentage during layout

  • Rows grid-template-rows: auto 10% auto
    This is the tricky part as there isn't a phase to compute the intrinsic height.
    So during layout we initially treat the percentage row as auto. In the example the rows are 20px 100px 20px.
    Initial result while treating the percentage row as "auto"
    Then if we decide to use that as intrinsic height (140px) the 2nd row should be resolved as 10% of 140px which is 14px. At this point we'll have the following rows 20px 14px 20px, if we don't do an extra pass we'll have overflow with auto rows which doesn't make sense.
    Result after resolving the percentage track during the first pass
    To get a good result we'd need to do an extra pass of the track sizing algorithm considering a fixed size for the percentage row, something like grid-template-rows: auto 14px auto. In that case the auto tracks will grow as needed to accommodate the sapping item (the final sizes are 63px 14px 63px).
    Final good result after doing a 2nd pass

The purposes of this issue are 2:

  1. Verify that this is the expected behavior, and probably modify the spec accordingly to explain these extra pass (and maybe how all this can be combined with orthogonal spanning items if that brings or not more issues).
  2. Check with other implementors if they're willing to support this new behavior for percentage rows (CC @atanassov and @MatsPalmgren).

Thanks for your time and sorry for the neverending story. 😇

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Nov 6, 2017

Member

The Working Group just discussed Percentage tracks, and agreed to the following resolutions:

  • RESOLVED: percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases
The full IRC log of that discussion <frremy> Topic: Percentage tracks
<fantasai> Github: https://github.com//issues/1921
<Rossen> github:https://github.com//issues/1921
<frremy> lajava: To keep things symmetric, we tried to add cases to resolve percentages for height of rows
<frremy> lajava: But we don't have min-content phase in the block direction, like we do for width
<frremy> lajava: So we would need to duplicate a second pass to make this work
<frremy> lajava: So 1st we would like this recorded clearly in the spec if that is required
<frremy> lajava: And all browsers would have to change their implementation
<frremy> florian: and why not just follow what browsers already have implemented?
<frremy> Rossen: the change would be relatively straighforward, it's no big deal
<frremy> florian: but we would possibly break content, right?
<frremy> Rossen: everything we do ends up breaking someone's content, I don't think this would be an issue here
<frremy> lajava: well, we are still unsure about what would happen in more complex cases like in orthogonal flows
<frremy> lajava: but at the very least it would require a second pass, once you know the intrinsic height
<frremy> Rossen: any opinion from Mozilla?
<frremy> Rossen: there is still time to fix, but window is closing
<frremy> dholbert: I don't have a strong opinion, and Matt hasn't commented on the issue
<frremy> dholbert: I don't like adding new layout steps usually
<frremy> Rossen: but it's easy to know if you need to do it before hand
<frremy> Rossen: only do it if you have percentage-sized row tracks
<frremy> dholbert: but if it is an orthogonal flow, you have to relayout entirely right?
<frremy> lajava: yes, but this already happens anyway
<dholbert> s/Matt/Mats/
<frremy> Rossen: any objection?
<frremy> RESOLVED: percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases
Member

css-meeting-bot commented Nov 6, 2017

The Working Group just discussed Percentage tracks, and agreed to the following resolutions:

  • RESOLVED: percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases
The full IRC log of that discussion <frremy> Topic: Percentage tracks
<fantasai> Github: https://github.com//issues/1921
<Rossen> github:https://github.com//issues/1921
<frremy> lajava: To keep things symmetric, we tried to add cases to resolve percentages for height of rows
<frremy> lajava: But we don't have min-content phase in the block direction, like we do for width
<frremy> lajava: So we would need to duplicate a second pass to make this work
<frremy> lajava: So 1st we would like this recorded clearly in the spec if that is required
<frremy> lajava: And all browsers would have to change their implementation
<frremy> florian: and why not just follow what browsers already have implemented?
<frremy> Rossen: the change would be relatively straighforward, it's no big deal
<frremy> florian: but we would possibly break content, right?
<frremy> Rossen: everything we do ends up breaking someone's content, I don't think this would be an issue here
<frremy> lajava: well, we are still unsure about what would happen in more complex cases like in orthogonal flows
<frremy> lajava: but at the very least it would require a second pass, once you know the intrinsic height
<frremy> Rossen: any opinion from Mozilla?
<frremy> Rossen: there is still time to fix, but window is closing
<frremy> dholbert: I don't have a strong opinion, and Matt hasn't commented on the issue
<frremy> dholbert: I don't like adding new layout steps usually
<frremy> Rossen: but it's easy to know if you need to do it before hand
<frremy> Rossen: only do it if you have percentage-sized row tracks
<frremy> dholbert: but if it is an orthogonal flow, you have to relayout entirely right?
<frremy> lajava: yes, but this already happens anyway
<dholbert> s/Matt/Mats/
<frremy> Rossen: any objection?
<frremy> RESOLVED: percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases
@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Nov 15, 2017

Contributor

To clarify, the spec is currently written in conformance with the above resolution (see https://drafts.csswg.org/css-grid-1/#valdef-grid-template-columns-length-percentage and https://drafts.csswg.org/css-grid-1/#intrinsic-sizes). But overall what's happening doesn't seem to be very clearly described.

Afaict, we could describe what is happening as the following (which is then implemented differently in UAs in order to optimize the number of passes):

  1. Size the Grid Container (per axis, for both axes)
  • If it is definite, just get that size.
  • If it is indefinite, run the grid sizing algorithm under min/max-content constraints, treating percentages as auto, in order to find the indefinite size.
  1. Size the Grid
  • Run the grid sizing algorithm under normal constraints: auto behaves as auto, and percentages resolve against the size of the grid container as calculated in step #1.

Does this seem correct, or are there shortcuts under #1 that aren't reflected here?

Contributor

fantasai commented Nov 15, 2017

To clarify, the spec is currently written in conformance with the above resolution (see https://drafts.csswg.org/css-grid-1/#valdef-grid-template-columns-length-percentage and https://drafts.csswg.org/css-grid-1/#intrinsic-sizes). But overall what's happening doesn't seem to be very clearly described.

Afaict, we could describe what is happening as the following (which is then implemented differently in UAs in order to optimize the number of passes):

  1. Size the Grid Container (per axis, for both axes)
  • If it is definite, just get that size.
  • If it is indefinite, run the grid sizing algorithm under min/max-content constraints, treating percentages as auto, in order to find the indefinite size.
  1. Size the Grid
  • Run the grid sizing algorithm under normal constraints: auto behaves as auto, and percentages resolve against the size of the grid container as calculated in step #1.

Does this seem correct, or are there shortcuts under #1 that aren't reflected here?

@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego Nov 29, 2017

Member

Does this seem correct, or are there shortcuts under #1 that aren't reflected here?

Yes, probably that would be fine, despite Blink/WebKit implementation don't do that. So for us it'll imply an extra pass as described in #1 but probably that's just an implementation detail that shouldn't be considered in the spec.

Regarding this change, I've been checking it again and all browsers (Chromium, Firefox, Edge and Safari) have the old behavior (percentage rows are treated as auto and never resolved), so we currently have interoperability here.
We're not planing to change Blink/WebKit implementations until other browsers do it, so please @dholbert, @MatsPalmgren, @atanassov notify here when you update this.
At the same time we're going to add a use counter, as this has been working like this for a long time (3 Chromium versions, 4 Firefox versions, 1 Edge version and 2 Safari versions) and height: auto is the default, so we want to know how many websites will be affected if we implement this change.

Member

mrego commented Nov 29, 2017

Does this seem correct, or are there shortcuts under #1 that aren't reflected here?

Yes, probably that would be fine, despite Blink/WebKit implementation don't do that. So for us it'll imply an extra pass as described in #1 but probably that's just an implementation detail that shouldn't be considered in the spec.

Regarding this change, I've been checking it again and all browsers (Chromium, Firefox, Edge and Safari) have the old behavior (percentage rows are treated as auto and never resolved), so we currently have interoperability here.
We're not planing to change Blink/WebKit implementations until other browsers do it, so please @dholbert, @MatsPalmgren, @atanassov notify here when you update this.
At the same time we're going to add a use counter, as this has been working like this for a long time (3 Chromium versions, 4 Firefox versions, 1 Edge version and 2 Safari versions) and height: auto is the default, so we want to know how many websites will be affected if we implement this change.

MXEBot pushed a commit to mirror/chromium that referenced this issue Nov 30, 2017

[css-grid] Add use counter for percentage rows and indefinite height
CSSWG resolved back in January 2017 about how percentage rows
in a grid container with indefinite height work, to make them symmetric
to what happens for columns. Which has been ratified in the last
F2F meeting at TPAC 2017.
All this has been discussed in the following issue:
w3c/csswg-drafts#1921

No browser is doing that right now, so it'd be nice to gather some data
about the usage of this before changing the implementation.
For that reason this patch adds a new use counter to check
when this change will have impact on real websites.

Change-Id: I61b82957d2bfe53912fd3e53a6bd41a6491a67be
Reviewed-on: https://chromium-review.googlesource.com/796855
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Commit-Queue: Manuel Rego Casasnovas <rego@igalia.com>
Cr-Commit-Position: refs/heads/master@{#520213}

@tabatkins tabatkins added the Agenda+ label Dec 4, 2017

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Dec 7, 2017

Member

The Working Group just discussed [css-grid] Percentage tracks and indefinite sizes.

The full IRC log of that discussion <dael> Topic: [css-grid] Percentage tracks and indefinite sizes
<dael> github: https://github.com//issues/1921#issuecomment-347993853
<dael> astearns: We decided on a change, but it was pointed out impl have interop.
<dael> fantasai: We discussed that at tpac. We re-resolved to do the thing impl don't do. THis is the are you sure you meant the thing.
<dael> florian: We took impl into account when we decided, yes?
<dael> fantasai: We did.
<dael> TabAtkins: We just want to be able to mark WG is cool with this.
<dael> astearns: I'm looking at tpac discussion and I see Rossen_ said this is fine, not a big deal.
<dael> TabAtkins: He jsut didn't want to do it alone b/c it's a breaking change.
<dael> Rossen_: That's true. That's still my point. I'm still okay as long as others do the change as well.
<dael> Rossen_: We're still cool. Others?
<dael> astearns: webkit or gecko?
<dael> dbaron: It's a question for Mats or dholbert
<dael> astearns: dholbert deferred to Mats
<dael> astearns: Given we have two impl willing to make the change and no obj from the others, shall we reaffirm we want this change?
<dael> astearns: Objections?
<dael> dbaron: Who will change first?
<dael> dbaron: If no one will do that we shouldn't do it.
<dael> fantasai: Rossen_ it looks like webkit and blink will follow if you lead.
<fantasai> mrego said “We're not planing to change Blink/WebKit implementations until other browsers do it”
<dael> Rossen_: I won't do it the same way we tried with control characters. I will allow the market leader to lead and we will happily follow. The change is straight forward, but I don't want to introduce interop change.
<dael> Rossen_: For technical decision I'm fine. For scheduling and who when, we won't be first.
<dael> fantasai: Rego said they won't change until other broswers do it. Igalia folks are good about following up so I don't think it'll get lost. But it will require MS to go first or at least say it's impla ndwill release on a date as long as WB and blink will also trigger.
<dael> Rossen_: How about we table scheduling discussion. If it's as easy for Rego and Igalia as it is for us, let's stop the discussion and we'll discuss timing. As far as spec decision is concerned we'll ship first as long as there are assurances others will follow.
<dael> rego: We checked how many chases will go through this. We first want to gather data on how many websites will break with this change.
<dael> Rossen_: You want us to change to see breakage?
<dael> rego: No, we added a use counter in chromium to gather data. So we want to wait to gather some data before doing anything.
<dael> Rossen_: Sounds good. Let us know that data and what it shows.
<dael> rego: Sure.
<dael> astearns: So anything more on this issue?
<dael> Rossen_: Is take away everyone is still okay pending some data collection from Igalia folks?
<rego> astearns, good summary :-)
<dael> astearns: Yes, pending data collection, impl complexity, and timing of all engines getting change done.
Member

css-meeting-bot commented Dec 7, 2017

The Working Group just discussed [css-grid] Percentage tracks and indefinite sizes.

The full IRC log of that discussion <dael> Topic: [css-grid] Percentage tracks and indefinite sizes
<dael> github: https://github.com//issues/1921#issuecomment-347993853
<dael> astearns: We decided on a change, but it was pointed out impl have interop.
<dael> fantasai: We discussed that at tpac. We re-resolved to do the thing impl don't do. THis is the are you sure you meant the thing.
<dael> florian: We took impl into account when we decided, yes?
<dael> fantasai: We did.
<dael> TabAtkins: We just want to be able to mark WG is cool with this.
<dael> astearns: I'm looking at tpac discussion and I see Rossen_ said this is fine, not a big deal.
<dael> TabAtkins: He jsut didn't want to do it alone b/c it's a breaking change.
<dael> Rossen_: That's true. That's still my point. I'm still okay as long as others do the change as well.
<dael> Rossen_: We're still cool. Others?
<dael> astearns: webkit or gecko?
<dael> dbaron: It's a question for Mats or dholbert
<dael> astearns: dholbert deferred to Mats
<dael> astearns: Given we have two impl willing to make the change and no obj from the others, shall we reaffirm we want this change?
<dael> astearns: Objections?
<dael> dbaron: Who will change first?
<dael> dbaron: If no one will do that we shouldn't do it.
<dael> fantasai: Rossen_ it looks like webkit and blink will follow if you lead.
<fantasai> mrego said “We're not planing to change Blink/WebKit implementations until other browsers do it”
<dael> Rossen_: I won't do it the same way we tried with control characters. I will allow the market leader to lead and we will happily follow. The change is straight forward, but I don't want to introduce interop change.
<dael> Rossen_: For technical decision I'm fine. For scheduling and who when, we won't be first.
<dael> fantasai: Rego said they won't change until other broswers do it. Igalia folks are good about following up so I don't think it'll get lost. But it will require MS to go first or at least say it's impla ndwill release on a date as long as WB and blink will also trigger.
<dael> Rossen_: How about we table scheduling discussion. If it's as easy for Rego and Igalia as it is for us, let's stop the discussion and we'll discuss timing. As far as spec decision is concerned we'll ship first as long as there are assurances others will follow.
<dael> rego: We checked how many chases will go through this. We first want to gather data on how many websites will break with this change.
<dael> Rossen_: You want us to change to see breakage?
<dael> rego: No, we added a use counter in chromium to gather data. So we want to wait to gather some data before doing anything.
<dael> Rossen_: Sounds good. Let us know that data and what it shows.
<dael> rego: Sure.
<dael> astearns: So anything more on this issue?
<dael> Rossen_: Is take away everyone is still okay pending some data collection from Igalia folks?
<rego> astearns, good summary :-)
<dael> astearns: Yes, pending data collection, impl complexity, and timing of all engines getting change done.

@astearns astearns removed the Agenda+ label Dec 7, 2017

@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego Dec 7, 2017

Member

About the use counter, it should start to appear in the following link once the initial data gets gathered: https://www.chromestatus.com/metrics/feature/timeline/popularity/2248

Member

mrego commented Dec 7, 2017

About the use counter, it should start to appear in the following link once the initial data gets gathered: https://www.chromestatus.com/metrics/feature/timeline/popularity/2248

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Mar 26, 2018

Member

Okay, the number looks like it's below our informal threshold, but is rising steadily - at this rate, it'll cross the .03% in two or three months. This is probably just rising with Grid usage in general.

Member

tabatkins commented Mar 26, 2018

Okay, the number looks like it's below our informal threshold, but is rising steadily - at this rate, it'll cross the .03% in two or three months. This is probably just rising with Grid usage in general.

@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego Apr 18, 2018

Member

Note that Grid Layout usage is still quite low ~0.50%: https://www.chromestatus.com/metrics/feature/timeline/popularity/1693

Member

mrego commented Apr 18, 2018

Note that Grid Layout usage is still quite low ~0.50%: https://www.chromestatus.com/metrics/feature/timeline/popularity/1693

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue May 18, 2018

Bug 1458902 - [css-grid] Re-resolve row-gap against the sum of row tr…
…ack sizes for auto-sized grid containers. r=dholbert

Per CSSWG resolution in:
w3c/csswg-drafts#1921 (comment)

sole pushed a commit to sole/gecko that referenced this issue May 21, 2018

Bug 1458902 - [css-grid] Re-resolve row-gap against the sum of row tr…
…ack sizes for auto-sized grid containers. r=dholbert

Per CSSWG resolution in:
w3c/csswg-drafts#1921 (comment)
@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Jun 20, 2018

I'm slightly in favor of the proposal for two reasons:

  1. it does what the author asked for
  2. it's symmetric to how percentage column track sizes are handled

I'd like to note though that it's a performance issue since we have to re-run the grid sizing algo (both axes) with the intrinsic size as a definite block size if there is a percentage row track size. (The usage counter above indicates that's likely rare though...)

MatsPalmgren commented Jun 20, 2018

I'm slightly in favor of the proposal for two reasons:

  1. it does what the author asked for
  2. it's symmetric to how percentage column track sizes are handled

I'd like to note though that it's a performance issue since we have to re-run the grid sizing algo (both axes) with the intrinsic size as a definite block size if there is a percentage row track size. (The usage counter above indicates that's likely rare though...)

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Jun 21, 2018

Given that we sometimes should do two passes of grid sizing, where the first pass is akin to an "intrinsic sizing pass", I think the spec should say explicitly that both passes are supposed to run the algo under "no constraint". And that the grid container's block-axis size is definite and final after the first pass (so that it works similar to the inline-axis).

MatsPalmgren commented Jun 21, 2018

Given that we sometimes should do two passes of grid sizing, where the first pass is akin to an "intrinsic sizing pass", I think the spec should say explicitly that both passes are supposed to run the algo under "no constraint". And that the grid container's block-axis size is definite and final after the first pass (so that it works similar to the inline-axis).

aarongable pushed a commit to chromium/chromium that referenced this issue Jul 3, 2018

[css-grid] Fix use counter for percentage rows and indefinite height
In the past we added a use counter to check the usage of percentage rows
on grid containers with indefinite height.
The name of the use counter is kGridRowTrackPercentIndefiniteHeight,
however it was also counting the cases of percentage columns
on grid containers with indefinite width.

This patch removes the last case from the use counter, as it was wrong.
In addition, the patch adds a new unit test for the use counter
to verify that is only triggered for percentage rows.

JFTR this use counter is related to issue:
w3c/csswg-drafts#1921

Change-Id: I2ab2cc28195e0b5e4f51ea37fff4c838e553cb8a
Reviewed-on: https://chromium-review.googlesource.com/1124840
Reviewed-by: Javier Fernandez <jfernandez@igalia.com>
Commit-Queue: Manuel Rego Casasnovas <rego@igalia.com>
Cr-Commit-Position: refs/heads/master@{#572332}

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 20, 2018

[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height, but then they'll be resolved against
that height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 1, 2018

[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height, but then they'll be resolved against
that height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 2, 2018

[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height, but then they'll be resolved against
that height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 2, 2018

[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 6, 2018

[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 6, 2018

[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 7, 2018

[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348

aarongable pushed a commit to chromium/chromium that referenced this issue Aug 7, 2018

[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348
Reviewed-on: https://chromium-review.googlesource.com/1142409
Commit-Queue: Manuel Rego <rego@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#581185}

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Aug 7, 2018

[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348
Reviewed-on: https://chromium-review.googlesource.com/1142409
Commit-Queue: Manuel Rego <rego@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#581185}

chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Aug 7, 2018

[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348
Reviewed-on: https://chromium-review.googlesource.com/1142409
Commit-Queue: Manuel Rego <rego@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#581185}
@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego Aug 7, 2018

Member

Since Firefox implemented the change for gutters (#509) for Firefox 62 we decided to implement this change for row tracks together with the change for row gutters in Chromium. And we have plans to do it in WebKit too.
In Chromium 69 there is a warning about this change of behavior that will happen in Chromium 70 that will be released in October 2018.

We analized the sites hitting the use counter, only a few (8 out of 178) were broken due to this change, and the workaround to keep the old behavior was as simple as using auto in the percentage rows.
We contacted those sites and explained how to fix the problem.
More info about all this in the following intent-to-implement-and-ship mail thread in blink-dev:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

It'd be nice if Firefox and Edge implement this too, there are tests in WPT checking this changes.

Member

mrego commented Aug 7, 2018

Since Firefox implemented the change for gutters (#509) for Firefox 62 we decided to implement this change for row tracks together with the change for row gutters in Chromium. And we have plans to do it in WebKit too.
In Chromium 69 there is a warning about this change of behavior that will happen in Chromium 70 that will be released in October 2018.

We analized the sites hitting the use counter, only a few (8 out of 178) were broken due to this change, and the workaround to keep the old behavior was as simple as using auto in the percentage rows.
We contacted those sites and explained how to fix the problem.
More info about all this in the following intent-to-implement-and-ship mail thread in blink-dev:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

It'd be nice if Firefox and Edge implement this too, there are tests in WPT checking this changes.

@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego Aug 8, 2018

Member

JFYI, we have implemented the changes in WebKit too.

Member

mrego commented Aug 8, 2018

JFYI, we have implemented the changes in WebKit too.

hubot pushed a commit to WebKit/webkit that referenced this issue Aug 8, 2018

rego@igalia.com
[css-grid] Update behavior of percentage row tracks and gutters
https://bugs.webkit.org/show_bug.cgi?id=188403

Reviewed by Sergio Villar Senin.

LayoutTests/imported/w3c:

Import tests from WPT related to this issue.

* web-platform-tests/css/css-grid/alignment/grid-content-alignment-second-pass-001-expected.txt: Added.
* web-platform-tests/css/css-grid/alignment/grid-content-alignment-second-pass-001.html: Added.
* web-platform-tests/css/css-grid/alignment/grid-content-alignment-second-pass-002-expected.txt: Added.
* web-platform-tests/css/css-grid/alignment/grid-content-alignment-second-pass-002.html: Added.
* web-platform-tests/css/css-grid/alignment/w3c-import.log:
* web-platform-tests/css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001-expected.txt: Added.
* web-platform-tests/css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html: Added.
* web-platform-tests/css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002-expected.txt: Added.
* web-platform-tests/css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html: Added.
* web-platform-tests/css/css-grid/grid-definition/w3c-import.log:
* web-platform-tests/css/css-grid/grid-layout-properties.html: Update test to reflect the new behavior.

Source/WebCore:

The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
- w3c/csswg-drafts#1921
- w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

Tests: imported/w3c/web-platform-tests/css/css-grid/alignment/grid-content-alignment-second-pass-001.html
       imported/w3c/web-platform-tests/css/css-grid/alignment/grid-content-alignment-second-pass-002.html
       imported/w3c/web-platform-tests/css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
       imported/w3c/web-platform-tests/css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html

* rendering/GridTrackSizingAlgorithm.cpp:
(WebCore::GridTrackSizingAlgorithm::gridTrackSize const):
(WebCore::GridTrackSizingAlgorithm::initializeTrackSizes):
(WebCore::GridTrackSizingAlgorithm::setup):
(WebCore::GridTrackSizingAlgorithm::reset):
* rendering/GridTrackSizingAlgorithm.h:
* rendering/RenderGrid.cpp:
(WebCore::RenderGrid::availableSpaceForGutters const):
(WebCore::RenderGrid::repeatTracksSizingIfNeeded):
(WebCore::RenderGrid::layoutBlock):

LayoutTests:

Update tests as needed according to the new behavior.

* TestExpectations: Two grid gutters tests from WPT css-align suite are passing now.
* fast/css-grid-layout/grid-columns-rows-get-set-expected.txt:
* fast/css-grid-layout/grid-columns-rows-get-set-multiple-expected.txt:
* fast/css-grid-layout/grid-columns-rows-get-set-multiple.html:
* fast/css-grid-layout/grid-columns-rows-get-set.html:
* fast/css-grid-layout/grid-gutters-as-percentage-expected.txt:
* fast/css-grid-layout/grid-gutters-as-percentage.html:
* fast/css-grid-layout/grid-track-sizing-with-percentages-and-orthogonal-flows-expected.txt:
* fast/css-grid-layout/grid-track-sizing-with-percentages-and-orthogonal-flows.html:
* fast/css-grid-layout/named-grid-line-get-set-expected.txt:
* fast/css-grid-layout/named-grid-line-get-set.html:
* fast/css-grid-layout/nested-grid-expected.html:
* fast/css-grid-layout/percent-track-breadths-regarding-container-size.html:
* fast/css-grid-layout/resources/grid-columns-rows-get-set-multiple.js:
* fast/css-grid-layout/resources/grid-columns-rows-get-set.js:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@234687 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@dholbert

This comment has been minimized.

Show comment
Hide comment
@dholbert

dholbert Aug 8, 2018

Contributor

It'd be nice if Firefox and Edge implement this too, there are tests in WPT checking this changes.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1481876 to cover this change for tracks (i.e. percent-sized grid rows) in Firefox. (Not sure about the timeline of when we'll get to it, though.)

Contributor

dholbert commented Aug 8, 2018

It'd be nice if Firefox and Edge implement this too, there are tests in WPT checking this changes.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1481876 to cover this change for tracks (i.e. percent-sized grid rows) in Firefox. (Not sure about the timeline of when we'll get to it, though.)

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Aug 11, 2018

Bug 1477230 [wpt PR 12089] - [css-grid] Change how percentage row tra…
…cks and gaps are resolved, a=testonly

Automatic update from web-platform-tests[css-grid] Change how percentage row tracks and gaps are resolved

The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348
Reviewed-on: https://chromium-review.googlesource.com/1142409
Commit-Queue: Manuel Rego <rego@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#581185}

--

wpt-commits: 244c6baf38953eac29840e2fbcb8a42dd8bafe88
wpt-pr: 12089

jankeromnes pushed a commit to jankeromnes/gecko that referenced this issue Aug 12, 2018

Bug 1477230 [wpt PR 12089] - [css-grid] Change how percentage row tra…
…cks and gaps are resolved, a=testonly

Automatic update from web-platform-tests[css-grid] Change how percentage row tracks and gaps are resolved

The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348
Reviewed-on: https://chromium-review.googlesource.com/1142409
Commit-Queue: Manuel Rego <rego@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#581185}

--

wpt-commits: 244c6baf38953eac29840e2fbcb8a42dd8bafe88
wpt-pr: 12089

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Aug 12, 2018

Bug 1477230 [wpt PR 12089] - [css-grid] Change how percentage row tra…
…cks and gaps are resolved, a=testonly

Automatic update from web-platform-tests[css-grid] Change how percentage row tracks and gaps are resolved

The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348
Reviewed-on: https://chromium-review.googlesource.com/1142409
Commit-Queue: Manuel Rego <rego@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#581185}

--

wpt-commits: 244c6baf38953eac29840e2fbcb8a42dd8bafe88
wpt-pr: 12089

jankeromnes pushed a commit to jankeromnes/gecko that referenced this issue Aug 12, 2018

Bug 1477230 [wpt PR 12089] - [css-grid] Change how percentage row tra…
…cks and gaps are resolved, a=testonly

Automatic update from web-platform-tests[css-grid] Change how percentage row tracks and gaps are resolved

The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.

The CSSWG issues are:
* w3c/csswg-drafts#1921
* w3c/csswg-drafts#509

So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.

We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.

JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ

BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html

Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348
Reviewed-on: https://chromium-review.googlesource.com/1142409
Commit-Queue: Manuel Rego <rego@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#581185}

--

wpt-commits: 244c6baf38953eac29840e2fbcb8a42dd8bafe88
wpt-pr: 12089
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment