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] Percentages gaps and intrinsic size #509

Closed
mrego opened this Issue Sep 21, 2016 · 56 comments

Comments

Projects
None yet
@mrego
Member

mrego commented Sep 21, 2016

There were some discussion on the TPAC but we didn't arrive any conclusion regarding how percentages should be resolved during intrinsic size computation.
The only resolution was that both tracks and gutters should resolve percentages in the same way.

Basically we've some different options that I'll try to explain here and also compare with what we've on regular blocks and tables.

1. Percentage resolution for width on regular blocks

Let's start by the most basic stuff, how a percentage is resolved in a simple case like this:

  <div style="float: left; border: thick solid magenta;">
    <div style="width: 150%; background: cyan; font: 25px/1 Ahem;">XX X</div>
  </div>

Note: Ahem is a font commonly used for browser testing. Here we know that the size of the element will be 100px, due each char "X" and space has a 25px width.

Percentage resolution on regular blocks

The behavior here is the same in any browser, and the 150% is resolved against the intrinsic size of the element (100px), in this case the result is 150px.
And the element overflows as the size of the container is 100px.

2. Percentage resolution for margins

However the discussion is now was triggered by the difference between Firefox and the rest of browsers resolving percentage on padding/border/margin (see issue #347 ).

A very simple example showcasing this:

  <div style="float: left; border: thick solid magenta;">
    <div style="margin-left: 20%; font: 25px/1 Ahem;">XXXX</div>
  </div>

Comparison between Chromium and Firefox resolving percentage margins

Here Firefox does something different to the rest of the browsers in order to resolve the 20% margin. It uses the 100px intrinsic size, to compute back the percentages, so the final size of the container is 125px and the 20% is resolved to 25px. To calculate the size the formula is basically: 100px / (1 - 0.2). The really good thing is that the element doesn't overflow the container.

The rest of the browsers resolve the 20% percentage against the intrinsic size of the element 100px. So they consider it as 20px. And the element overflows.

3. Percentage resolution for grid tracks

So now the question is what to do on grid tracks and gutters regarding how to resolve percentages on these situations.

Let's start by percentage tracks:

  <div style="display: inline-grid; grid: 100px / 50% 100px; border: thick solid magenta;">
    <div style="background: cyan;"></div>
    <div style="background: yellow;"></div>
  </div>

Grid with percentage tracks

Right now all the implementations have the same behavior here. The 50% track is resolved against the intrisic size of the grid container, which is 100px (the fixed track). So the percentage track has a 50px width. And the tracks overflow the grid container.

The idea was to check if we could do something similar to what Firefox does for margins on a regular block or not in the grid cases. If we follow that idea in this case the percentage track would be resolved to 100px and the the grid container will have 200px width so the tracks won't overflow.

Back computing percentage tracks on a grid

This is actually the same the behavior of tables in all browsers:

  <div style="display: table; border: thick solid magenta;">
    <div style="display: table-cell; width: 50%; height: 100px; background: cyan;"></div>
    <div style="display: table-cell; width: 100px; height: 100px; background: yellow;"></div>
  </div>

However when you add content to the table, the behavior is different as the 2nd column grows more than the 100px width we set:

  <div style="display: table; font: 25px/1 Ahem; border: thick solid magenta;">
    <div style="display: table-cell; width: 50%; height: 100px; background: cyan;">XXXXXX</div>
    <div style="display: table-cell; width: 100px; height: 100px; background: yellow;"></div>
  </div>

Percentage tracks on a table with content

As you can see the first column is 150px (due to the content) and the 2nd one is grown up to 150px, in order that the the intrinsic size of the table is 300px and the 50% of the first track is matches the 50% computation.
This shows the issues with back computing the percentages if the elements have contents.

Probably this doesn't make sense if we think on grid layout tracks, it'd be weird that a fixed track grows over their specific size. If we do a similar example with grid:

  <div style="display: inline-grid; grid: 100px / 50% 100px; font: 25px/1 Ahem; border: thick solid magenta;">
    <div style="background: cyan;">XXXXXX</div>
    <div style="background: yellow; opacity: 0.8;"></div>
  </div>

Grid with percentage tracks and contents

The percentage is resolved against the intrinsic size, which in this case is 150px (due to the contents on the first column) + 100px = 250px. So the 50% of the column is resolved as 125px (the content would overflow), and the 2nd column keeps being 100px.
Again this is the current behavior in all the implementations.

And I believe the same would happen for both tracks and gutters. As a grid gap is not more than a fixed track with the given size from the track sizing algorithm point of view, but it can have contents if an item is spanning several tracks. So we might have similar issues regarding back computing percentage gaps.

4. Options

I think the options we've right now are:
A) Compute percentage tracks & gutters the same than we do in regular blocks.
B) Compute percentage tracks & gutters as 0px for intrinsic size computations.
C) Back compute percentage tracks & gutters.

IMHO, I'd discard option C) due to the issues explained before when a percentage track has contents.
B) would mean a completely different behavior to the one in regular blocks. It could be ok as a specific behavior only for grid.
A) matches the current implementations.

What do you think? Opinions, feedback, corrections, etc. are welcomed.

@jensimmons

This comment has been minimized.

Show comment
Hide comment
@jensimmons

jensimmons Sep 21, 2016

I don't have a overwhelming preference. On the one hand, having something that looks broken will help authors know they should rethink their code. On the other hand, I can see this coming up in real world usecases, and having Grid return a broken result is a bad idea. It would be better for it to resolve in some kind of useable way.

Here's the real world usecase where I think this might come up. An author creates a 'media block' component in their new style guide. It uses Grid to layout a photo, a headline, and a teaser paragraph. They defined things in percents because Grid is new to them, and they aren't used to the new options. Then they take that component's code and use it in many places around the site. It works fine in the legacy full-page layout (that has a fixed overall fixed-size columns). It works fine in every use case, for months. And then they redo their full-page layout using Grid, and this component is dropped into an auto-sized track, on a parent Grid. Suddenly it breaks. And the author doesn't know why.

Maybe we want the % track to resolve to zero if it's empty. Basically — have it always act like it's auto.

Maybe we want the % track to act like it's minmax(backcomputethingy, auto) — where it acts like auto if the content is making it grow beyond the competed size. But if there's not that much content / is no content, then it acts like the examples where the size is computed based on the other sizes. Basically giving us both of these, depending on whether or not there is content.

css-grid percentages and intrinsic size issue 509 w3c csswg-drafts 2016-09-21 15-10-38

css-grid percentages and intrinsic size issue 509 w3c csswg-drafts 2016-09-21 15-10-26

jensimmons commented Sep 21, 2016

I don't have a overwhelming preference. On the one hand, having something that looks broken will help authors know they should rethink their code. On the other hand, I can see this coming up in real world usecases, and having Grid return a broken result is a bad idea. It would be better for it to resolve in some kind of useable way.

Here's the real world usecase where I think this might come up. An author creates a 'media block' component in their new style guide. It uses Grid to layout a photo, a headline, and a teaser paragraph. They defined things in percents because Grid is new to them, and they aren't used to the new options. Then they take that component's code and use it in many places around the site. It works fine in the legacy full-page layout (that has a fixed overall fixed-size columns). It works fine in every use case, for months. And then they redo their full-page layout using Grid, and this component is dropped into an auto-sized track, on a parent Grid. Suddenly it breaks. And the author doesn't know why.

Maybe we want the % track to resolve to zero if it's empty. Basically — have it always act like it's auto.

Maybe we want the % track to act like it's minmax(backcomputethingy, auto) — where it acts like auto if the content is making it grow beyond the competed size. But if there's not that much content / is no content, then it acts like the examples where the size is computed based on the other sizes. Basically giving us both of these, depending on whether or not there is content.

css-grid percentages and intrinsic size issue 509 w3c csswg-drafts 2016-09-21 15-10-38

css-grid percentages and intrinsic size issue 509 w3c csswg-drafts 2016-09-21 15-10-26

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 21, 2016

Contributor

The other option we discussed as making the percentages behave as auto if they are specified as resolving against an indefinite size (i.e. one that is auto/or *-content). That would avoid overflow by ignoring the percentage entirely.

Contributor

fantasai commented Sep 21, 2016

The other option we discussed as making the percentages behave as auto if they are specified as resolving against an indefinite size (i.e. one that is auto/or *-content). That would avoid overflow by ignoring the percentage entirely.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 21, 2016

Contributor

(FWIW, I don't have a strong opinion on this except that an auto-sized thing should not have its contents overflow.)

Contributor

fantasai commented Sep 21, 2016

(FWIW, I don't have a strong opinion on this except that an auto-sized thing should not have its contents overflow.)

@meyerweb

This comment has been minimized.

Show comment
Hide comment
@meyerweb

meyerweb Sep 21, 2016

Of Manuel’s three options, I have a slight preference for A. This might be due to my having gotten very used to the idea that tracks can spill out of grid containers. Maybe a little too used to the idea, honestly. But it’s straightforward to explain and understand, and fits with what authors generally expect from regular blocks.

I greatly dislike B—assuming any percentage to be zero will lead to deeply unintuitive results, effectively indistinguishable from bugs to the average author.

I kind of like C, given that it taps into long-extant behavior. There are already descriptions of how to resolve similar situations in the table-layout module of CSS, and they could be leveraged. I’m just not sure they’re the best behavior for grids, so I lean away from C a bit.

But I think Jen’s onto something with treating these situations as if they were a species of minmax() values. The trick is picking the right minimum and maximum values. Jen’s values might be right, or there might be better; I don’t know.

meyerweb commented Sep 21, 2016

Of Manuel’s three options, I have a slight preference for A. This might be due to my having gotten very used to the idea that tracks can spill out of grid containers. Maybe a little too used to the idea, honestly. But it’s straightforward to explain and understand, and fits with what authors generally expect from regular blocks.

I greatly dislike B—assuming any percentage to be zero will lead to deeply unintuitive results, effectively indistinguishable from bugs to the average author.

I kind of like C, given that it taps into long-extant behavior. There are already descriptions of how to resolve similar situations in the table-layout module of CSS, and they could be leveraged. I’m just not sure they’re the best behavior for grids, so I lean away from C a bit.

But I think Jen’s onto something with treating these situations as if they were a species of minmax() values. The trick is picking the right minimum and maximum values. Jen’s values might be right, or there might be better; I don’t know.

@meyerweb

This comment has been minimized.

Show comment
Hide comment
@meyerweb

meyerweb Sep 21, 2016

(FWIW, I don't have a strong opinion on this except that an auto-sized thing should not have its contents overflow.)

@fantasai: Does that mean you want the grid container to overflow its parent, in preference to the grid’s contents overflowing the grid container? That would upend the way blocks are usually treated: given an auto-width div containing a very wide image, the div’s width is controlled by its parent’s width, and the image inside it spills out. Are you saying given a similar case, except with a very wide grid track, the grid container should spill out of its parent in order to contain the grid track?

meyerweb commented Sep 21, 2016

(FWIW, I don't have a strong opinion on this except that an auto-sized thing should not have its contents overflow.)

@fantasai: Does that mean you want the grid container to overflow its parent, in preference to the grid’s contents overflowing the grid container? That would upend the way blocks are usually treated: given an auto-width div containing a very wide image, the div’s width is controlled by its parent’s width, and the image inside it spills out. Are you saying given a similar case, except with a very wide grid track, the grid container should spill out of its parent in order to contain the grid track?

@jensimmons

This comment has been minimized.

Show comment
Hide comment
@jensimmons

jensimmons Sep 21, 2016

I also think there might be something to setting the track sizes to auto. Which would make them the content size when there's content, and make them collapse to zero when they are empty. Which it seems is better than letting things overflow. If an author wants them to not be zero, they'll likely start trying to figure out why they are zero — and then realize, oh, % of unknown = oh, zero, ok. It makes sense. Makes more sense than random sizes that are too big and cause overflow.

jensimmons commented Sep 21, 2016

I also think there might be something to setting the track sizes to auto. Which would make them the content size when there's content, and make them collapse to zero when they are empty. Which it seems is better than letting things overflow. If an author wants them to not be zero, they'll likely start trying to figure out why they are zero — and then realize, oh, % of unknown = oh, zero, ok. It makes sense. Makes more sense than random sizes that are too big and cause overflow.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Sep 21, 2016

Contributor

Does that mean you want the grid container to overflow its parent, in preference to the grid’s contents overflowing the grid container?

That's not at all the issue here. The analogy is a percentage-sized child inside an auto-sized (shrinkwrapped) float. That is, the percentage child is resolved against the container, and the container is resolved against the size of the child. (If the grid is sized to fill its container, then that size is definite and we can resolve the percentage no problem.)

Contributor

fantasai commented Sep 21, 2016

Does that mean you want the grid container to overflow its parent, in preference to the grid’s contents overflowing the grid container?

That's not at all the issue here. The analogy is a percentage-sized child inside an auto-sized (shrinkwrapped) float. That is, the percentage child is resolved against the container, and the container is resolved against the size of the child. (If the grid is sized to fill its container, then that size is definite and we can resolve the percentage no problem.)

@meyerweb

This comment has been minimized.

Show comment
Hide comment
@meyerweb

meyerweb Sep 21, 2016

@fantasai: Ah, I see. I took your statement to be generic, not contextually narrowed. My apologies.

meyerweb commented Sep 21, 2016

@fantasai: Ah, I see. I took your statement to be generic, not contextually narrowed. My apologies.

@rachelandrew

This comment has been minimized.

Show comment
Hide comment
@rachelandrew

rachelandrew Sep 21, 2016

Contributor

I've been thinking about this and don't have a strong preference. It makes most sense to me that they would be set to auto, as described by Jen above, and that was my first thought when I read the initial Issue - prior to seeing the subsequent comments - that they could just set set to auto.

Contributor

rachelandrew commented Sep 21, 2016

I've been thinking about this and don't have a strong preference. It makes most sense to me that they would be set to auto, as described by Jen above, and that was my first thought when I read the initial Issue - prior to seeing the subsequent comments - that they could just set set to auto.

@svillar

This comment has been minimized.

Show comment
Hide comment
@svillar

svillar Sep 22, 2016

I'd like to state that making gaps work as auto tracks will complicate a lot the implementation of the track sizing algorithm, something that we should not do being so close to CR IMHO. Fixed size gaps are easy to accommodate in the algorithm machinery because they only involve reducing the available space to distribute, but making them content-sized will require major changes in the algorithm.

svillar commented Sep 22, 2016

I'd like to state that making gaps work as auto tracks will complicate a lot the implementation of the track sizing algorithm, something that we should not do being so close to CR IMHO. Fixed size gaps are easy to accommodate in the algorithm machinery because they only involve reducing the available space to distribute, but making them content-sized will require major changes in the algorithm.

@rachelandrew

This comment has been minimized.

Show comment
Hide comment
@rachelandrew

rachelandrew Sep 22, 2016

Contributor

well that sounds like a good reason not to do it given lack of strong preferences. I'd probably lean towards suggestion A of the other suggestions.

Contributor

rachelandrew commented Sep 22, 2016

well that sounds like a good reason not to do it given lack of strong preferences. I'd probably lean towards suggestion A of the other suggestions.

@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego Sep 22, 2016

Member

Yeah I was thinking on this the whole night and I believe we should just keep the current implementation.
I've found some very weird issues, if a grid-row-gap: 10% would be treated as auto we could end up having gaps of different sizes.
An example to represent it with percentage tracks in a grid with grid-template-rows: 100px 10% 100px 10% 100px.

Example to represent it with percentage tracks

  • One item spanning the first 3 rows with a content of 300px height, the 10% of the 2nd row ends up being 100px.
  • Another item spanning the last 3 rows, with a content of 250px height, the 10% of the 4th row ends up being 50px.

Probably the spec needs to be updated:

  1. The percentage resolution should be done exactly as it was before (like in regular blocks).
  2. We should explicitly say that percentage gaps are resolved as 0px when the height is indefinite (for widths they'll behave like regular blocks).
Member

mrego commented Sep 22, 2016

Yeah I was thinking on this the whole night and I believe we should just keep the current implementation.
I've found some very weird issues, if a grid-row-gap: 10% would be treated as auto we could end up having gaps of different sizes.
An example to represent it with percentage tracks in a grid with grid-template-rows: 100px 10% 100px 10% 100px.

Example to represent it with percentage tracks

  • One item spanning the first 3 rows with a content of 300px height, the 10% of the 2nd row ends up being 100px.
  • Another item spanning the last 3 rows, with a content of 250px height, the 10% of the 4th row ends up being 50px.

Probably the spec needs to be updated:

  1. The percentage resolution should be done exactly as it was before (like in regular blocks).
  2. We should explicitly say that percentage gaps are resolved as 0px when the height is indefinite (for widths they'll behave like regular blocks).
@svillar

This comment has been minimized.

Show comment
Hide comment
@svillar

svillar Sep 22, 2016

As @mrego perfectly explained that would lead to gaps with different sizes, a.k.a. something that is not gaps. Authors wanting such a behavior could always use auto tracks.

svillar commented Sep 22, 2016

As @mrego perfectly explained that would lead to gaps with different sizes, a.k.a. something that is not gaps. Authors wanting such a behavior could always use auto tracks.

@meyerweb

This comment has been minimized.

Show comment
Hide comment
@meyerweb

meyerweb Sep 22, 2016

I begin to understand a little bit why the WG never permitted percentage widths for borders. Kind of tempting to do the same here…

meyerweb commented Sep 22, 2016

I begin to understand a little bit why the WG never permitted percentage widths for borders. Kind of tempting to do the same here…

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Jan 9, 2017

Here's my proposal for percentages in intrinsic sizing:

  • treat percentage track sizes as auto (as currently specced)
  • back-compute grid-gap percentages

I think the reasoning that grid-gap must be treated the same as a track size is flawed. Grid gaps never contain any child content so they are more like internal padding IMO. This is why they can be back-computed safely (unlike percentage track sizes which cannot because its contents provides the min-content size that provides the basis for the back-computing. We tried back-computing those too in Gecko at first, but it didn't work out for that reason.).

Here's a testcase with some examples (the two boxes at the end are grids, the first is a flexbox and the second is a block with percentage padding for comparison):
https://people-mozilla.org/~mpalmgren/tests/grid/percent-intrinsic-sizing.html
and here's how it renders in Firefox Nightly and Chrome Canary respectively:
https://people-mozilla.org/~mpalmgren/tests/grid/percent-intrinsic-sizing.png

MatsPalmgren commented Jan 9, 2017

Here's my proposal for percentages in intrinsic sizing:

  • treat percentage track sizes as auto (as currently specced)
  • back-compute grid-gap percentages

I think the reasoning that grid-gap must be treated the same as a track size is flawed. Grid gaps never contain any child content so they are more like internal padding IMO. This is why they can be back-computed safely (unlike percentage track sizes which cannot because its contents provides the min-content size that provides the basis for the back-computing. We tried back-computing those too in Gecko at first, but it didn't work out for that reason.).

Here's a testcase with some examples (the two boxes at the end are grids, the first is a flexbox and the second is a block with percentage padding for comparison):
https://people-mozilla.org/~mpalmgren/tests/grid/percent-intrinsic-sizing.html
and here's how it renders in Firefox Nightly and Chrome Canary respectively:
https://people-mozilla.org/~mpalmgren/tests/grid/percent-intrinsic-sizing.png

@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego Jan 10, 2017

Member
  • treat percentage track sizes as auto (as currently specced)

I'm not sure I like this approach, as I've shown in the previous example 2 tracks of 10% will have different sizes; that seems quite strange to me.

Grid gaps never contain any child content so they are more like internal padding IMO.

If an item spans several tracks, the item is somehow inside the gap. The spec says: "For the purpose of track sizing, each gutter is essentially treated as an extra, empty track of the specified size."

Of course, it depends on how you resolve the percentage of the gap for the gutter, but if we use auto we might end up having gaps of different sizes (which again seems weird o me).

IMHO, we should try to make percentage tracks the very same than percentage gaps. So it'd be the same to use grid-template-rows: 100px 10% 100px 10% 100px; than grid-template-rows: 100px 100px 100px; grid-row-gap: 10%;.

Member

mrego commented Jan 10, 2017

  • treat percentage track sizes as auto (as currently specced)

I'm not sure I like this approach, as I've shown in the previous example 2 tracks of 10% will have different sizes; that seems quite strange to me.

Grid gaps never contain any child content so they are more like internal padding IMO.

If an item spans several tracks, the item is somehow inside the gap. The spec says: "For the purpose of track sizing, each gutter is essentially treated as an extra, empty track of the specified size."

Of course, it depends on how you resolve the percentage of the gap for the gutter, but if we use auto we might end up having gaps of different sizes (which again seems weird o me).

IMHO, we should try to make percentage tracks the very same than percentage gaps. So it'd be the same to use grid-template-rows: 100px 10% 100px 10% 100px; than grid-template-rows: 100px 100px 100px; grid-row-gap: 10%;.

@astearns astearns removed the Agenda+ F2F label Jan 11, 2017

@svillar

This comment has been minimized.

Show comment
Hide comment
@svillar

svillar Jan 17, 2017

I totally agree with @mrego, having gaps of different sizes is a total blocker, we would not certainly ship an implementation allowing that. And again gaps DO have child content whenever a child spans through various tracks.

svillar commented Jan 17, 2017

I totally agree with @mrego, having gaps of different sizes is a total blocker, we would not certainly ship an implementation allowing that. And again gaps DO have child content whenever a child spans through various tracks.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Feb 2, 2017

Contributor

Gaps are defined to be treated as empty tracks, so there is no way they would end up with different sizes.

Contributor

fantasai commented Feb 2, 2017

Gaps are defined to be treated as empty tracks, so there is no way they would end up with different sizes.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Feb 2, 2017

Member

They're not defined that way; there's a non-normative summary sentence (using the word "essentially", and another one using "as if") making a general statement that they operate as if they're empty. But there's nothing normative stating that; as the spec is written, "treat as auto" would indeed result in different sizes in some cases.

However, we discussed this at the F2F (resolution) and resolved that percentages are 0 for determining intrinsic width, but still resolve at used-value time, giving us the Chrome behavior (where the yellow track overflows the grid container, in Manuel's example).

Member

tabatkins commented Feb 2, 2017

They're not defined that way; there's a non-normative summary sentence (using the word "essentially", and another one using "as if") making a general statement that they operate as if they're empty. But there's nothing normative stating that; as the spec is written, "treat as auto" would indeed result in different sizes in some cases.

However, we discussed this at the F2F (resolution) and resolved that percentages are 0 for determining intrinsic width, but still resolve at used-value time, giving us the Chrome behavior (where the yellow track overflows the grid container, in Manuel's example).

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Feb 2, 2017

Contributor

I dropped the word "essentially". This is intended to be exactly how gutters behave.

Contributor

fantasai commented Feb 2, 2017

I dropped the word "essentially". This is intended to be exactly how gutters behave.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Feb 2, 2017

Member

No it's not; the layout algorithm has no concept of tracks that "act like they're empty" when things span across them. The gutter tracks are just ordinary tracks; it just happens that it's impossible to place an item directly in them.

Member

tabatkins commented Feb 2, 2017

No it's not; the layout algorithm has no concept of tracks that "act like they're empty" when things span across them. The gutter tracks are just ordinary tracks; it just happens that it's impossible to place an item directly in them.

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Feb 2, 2017

Contributor

Hum, I didn't follow the "essentially" discussion but I just wanted to correct that we did not resolve that percentages "resolve to 0 for intrinsic width computation" but that "percentages are ignored for the purpose of comping the intrinsic width, but resolve at layout time". Those two things are different.

myles 1. Ignore percentage and treat as auto
myles 2. Back compute percentages
myles 3. percentages contribute zero, but resolve afterwards
myles 4. percentages contribute intrinsic size, resolve afterwards
myles 5. #3 unless all siblings are percentage, else #1

then narrowed down to

myles 1. Ignore percentages
myles 2. Backcompute percentages
myles 3. Percentages contribute intrinsic size, but resolve afterwards
myles 4. #3 with a switch based on min-width
dbaron #4 renumbered to #3, #6 renumbered to #4

then

myles RESOLVED: "Percentages contribute intrinsic size and they resolve after layout"

https://log.csswg.org/irc.w3.org/css/2017-01-13/#e761591

Contributor

FremyCompany commented Feb 2, 2017

Hum, I didn't follow the "essentially" discussion but I just wanted to correct that we did not resolve that percentages "resolve to 0 for intrinsic width computation" but that "percentages are ignored for the purpose of comping the intrinsic width, but resolve at layout time". Those two things are different.

myles 1. Ignore percentage and treat as auto
myles 2. Back compute percentages
myles 3. percentages contribute zero, but resolve afterwards
myles 4. percentages contribute intrinsic size, resolve afterwards
myles 5. #3 unless all siblings are percentage, else #1

then narrowed down to

myles 1. Ignore percentages
myles 2. Backcompute percentages
myles 3. Percentages contribute intrinsic size, but resolve afterwards
myles 4. #3 with a switch based on min-width
dbaron #4 renumbered to #3, #6 renumbered to #4

then

myles RESOLVED: "Percentages contribute intrinsic size and they resolve after layout"

https://log.csswg.org/irc.w3.org/css/2017-01-13/#e761591

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Feb 2, 2017

Contributor

Though, yes, in the case of gutters, since there is no content inside them to give them an intrinsic width, that means that percentages act like if they were in actuality nullified during that computation. For another track that has content directly inside, the result would vary.

Contributor

FremyCompany commented Feb 2, 2017

Though, yes, in the case of gutters, since there is no content inside them to give them an intrinsic width, that means that percentages act like if they were in actuality nullified during that computation. For another track that has content directly inside, the result would vary.

@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego Feb 15, 2017

Member

For widths that would cause that a percentage track and a percentage gap are not equivalent (which probably is not bad).
For example:

  <div style="display: inline-grid; font: 10px/1 Ahem; border: dotted;
                    grid-template-columns: 50px 20% 50px;">
    <div style="grid-column: 1;">X</div>
    <div style="grid-column: 3;">X</div>
    <div style="grid-column: 1 / span 3;">XXXXXXXXXXXXXXX</div>
  </div>

Grid using percentage track

During intrinsic size computation, the 20% is treated as auto, so the size of the columns is 50px 50px 50px (total size of the grid container is 150px).
Then during the actual layout the percentage is resolved 20% of 150px = 30px. So the final size of the colums is 50px 30px 50px.

Then if we've a similar example but using gaps:

  <div style="display: inline-grid; font: 10px/1 Ahem; border: dotted;
                    grid-template-columns: 50px 50px; grid-gap: 20%;">
    <div style="grid-column: 1;">X</div>
    <div style="grid-column: 2;">X</div>
    <div style="grid-column: 1 / span 2;">XXXXXXXXXXXXXXX</div>
  </div>

Grid using percentage gaps

During intrinsic size computation, the percentage track is treated as 0px (as it's an empty track). So the size of the columns is 50px 50px (with a 0px gap in between).
Later during layout the percentage is resolved 20% of 100px = 20px. And the final size of the columns is still 50px 50px but with a 20px gap.

If we want to have the same output in both cases, a possible solution would be to treat percentage gaps as an auto track during intrinsic size computation (that would be the same we do for percentage tracks).
However for heights that would lead to similar issues that we've with percentage tracks, that the same percentage can be end up being different sizes if the height is indefinite (check example in a previous comment). And I guess we don't want that the size of 2 percentage gaps is not the same.

Member

mrego commented Feb 15, 2017

For widths that would cause that a percentage track and a percentage gap are not equivalent (which probably is not bad).
For example:

  <div style="display: inline-grid; font: 10px/1 Ahem; border: dotted;
                    grid-template-columns: 50px 20% 50px;">
    <div style="grid-column: 1;">X</div>
    <div style="grid-column: 3;">X</div>
    <div style="grid-column: 1 / span 3;">XXXXXXXXXXXXXXX</div>
  </div>

Grid using percentage track

During intrinsic size computation, the 20% is treated as auto, so the size of the columns is 50px 50px 50px (total size of the grid container is 150px).
Then during the actual layout the percentage is resolved 20% of 150px = 30px. So the final size of the colums is 50px 30px 50px.

Then if we've a similar example but using gaps:

  <div style="display: inline-grid; font: 10px/1 Ahem; border: dotted;
                    grid-template-columns: 50px 50px; grid-gap: 20%;">
    <div style="grid-column: 1;">X</div>
    <div style="grid-column: 2;">X</div>
    <div style="grid-column: 1 / span 2;">XXXXXXXXXXXXXXX</div>
  </div>

Grid using percentage gaps

During intrinsic size computation, the percentage track is treated as 0px (as it's an empty track). So the size of the columns is 50px 50px (with a 0px gap in between).
Later during layout the percentage is resolved 20% of 100px = 20px. And the final size of the columns is still 50px 50px but with a 20px gap.

If we want to have the same output in both cases, a possible solution would be to treat percentage gaps as an auto track during intrinsic size computation (that would be the same we do for percentage tracks).
However for heights that would lead to similar issues that we've with percentage tracks, that the same percentage can be end up being different sizes if the height is indefinite (check example in a previous comment). And I guess we don't want that the size of 2 percentage gaps is not the same.

@rachelandrew

This comment has been minimized.

Show comment
Hide comment
@rachelandrew

rachelandrew Jul 29, 2017

Contributor

I've ended up here again while doing some poking around at interop issues with percentage sizing of gaps. Currently there seems to be decent interop on column-gap as a percentage. Chrome, Safari TP and the Edge Preview all seem to do the same thing.

When I look at row-gap, I believe from the above discussion we expect that to resolve as per an auto-sized track. Currently Blink collapses the gap to zero if the grid does not have a fixed height set, Firefox is - I think - using a percentage of the height of the grid, however Firefox collapses an auto sized track down when it is empty.

Both seem to agree when the grid has a fixed height. Quick demo here: https://codepen.io/rachelandrew/pen/xLZbMm

I was going to raise an issue with Firefox, but I don't know if this was ever officially resolved on here.

I know this is still marked as at-risk in the spec, however an author pointed out a use case for percentage gaps that I hadn't considered. They enable the use of a grid layout component in a layout that uses a flexbox or float based grid, which relies on percentages for responsive spacing.
https://twitter.com/minamarkham/status/891029296604618752

Contributor

rachelandrew commented Jul 29, 2017

I've ended up here again while doing some poking around at interop issues with percentage sizing of gaps. Currently there seems to be decent interop on column-gap as a percentage. Chrome, Safari TP and the Edge Preview all seem to do the same thing.

When I look at row-gap, I believe from the above discussion we expect that to resolve as per an auto-sized track. Currently Blink collapses the gap to zero if the grid does not have a fixed height set, Firefox is - I think - using a percentage of the height of the grid, however Firefox collapses an auto sized track down when it is empty.

Both seem to agree when the grid has a fixed height. Quick demo here: https://codepen.io/rachelandrew/pen/xLZbMm

I was going to raise an issue with Firefox, but I don't know if this was ever officially resolved on here.

I know this is still marked as at-risk in the spec, however an author pointed out a use case for percentage gaps that I hadn't considered. They enable the use of a grid layout component in a layout that uses a flexbox or float based grid, which relies on percentages for responsive spacing.
https://twitter.com/minamarkham/status/891029296604618752

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Apr 30, 2018

Member

Agenda+ to confirm that we should go with @mrego's suggested wording, due to implementation complexity of the spec wording and current implementation confluence on his suggested wording.

Member

tabatkins commented Apr 30, 2018

Agenda+ to confirm that we should go with @mrego's suggested wording, due to implementation complexity of the spec wording and current implementation confluence on his suggested wording.

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot May 2, 2018

Member

The Working Group just discussed Percentages gaps and intrinsic size, and agreed to the following resolutions:

  • RESOLVED: Take option B (contribute 0 and resolve as percentage for column and row gaps)
The full IRC log of that discussion <dael> Topic: Percentages gaps and intrinsic size
<fantasai> s/contribute to fr resolution/contribute to fr track minimums/
<dael> github: https://github.com/w3c/csswg-drafts/issues/509
<rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-381759138
<dael> Rossen_: Let me paste the time stamp instead of the whole issue
<dael> Rossen_: rego has it
<dael> rego: I reopened it.
<dael> rego: All browsers now support % in column gap in multi column
<dael> rego: All of them are interop. But they're not following new text in spec. Chrome and webkit we don't see an easy way to follow for width so I suggest we change the text to says something like % resolves to 0 when resolved against the base size. Something like the indefinite size is what we should say because the logical width is not indefinite.
<dael> rego: That causes overflow in some cases but I don't think there's a way to do it better and changing spec text would make it match impl.
<fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-356256873
<dael> fantasai: If we go back to the options before there was option b which was contribute 0 resolve as 0. Igalia is saying we don't know when to resolve if it's at 0 or not because that info isn't part of what's given to grid when it's doing layout.
<dael> fantasai: It's easier for impl if they just continue tracking or continue tracking into the container and therefore the percent resolves.
<fantasai> s/or continue tracking into the container/continue tracking just the information they have already, i.e. the size of the container/
<dael> Rossen_: I can't speak to other impl, in our grid impl we know if we're doing layout for sizing and measuing the content vs sizing when we're not shrink to fit. From that PoV I don't think we have anything in the spec that prevents a impl from passing this info
<dael> Rossen_: Looking at current interop around this....based on the codepen from the issue seemed like we all agree on behavior of grid.
<fantasai> s/that info/information on whether the current size of the container was a content-based size/
<dael> Rossen_: rego what I hear is once we go down...if we change resolution from b to d, contribute 0 resolve as 0, we minimize amount of potential overflow, but also drop ability to have % column gaps. Last time we discussed the one constant feedback from webdev was they don't want to drop the gap. It's more intutive if you see overflow and go and fix it rather then add values and have no effect.
<dael> Rossen_: I'm not sure we're driving toward an ergonomic.
<dael> fantasai: Previous resolution was b and we're proposing switch to d.
<dael> Rossen_: In that case I agree and misunderstood the proposal.
<fantasai> s/ergonomic/ergonomic solution/
<dael> rego: It would be more like f.
<dael> rego: It would be like when grid resolves % for width and height in regular blocks they're different so same here.
<dael> Rossen_: Okay, I'm with you.
<dael> Rossen_: Other opinions on this?
<dael> fantasai: Proposal is to resolved the % in column gaps but not row gaps?
<dael> s/resolved/resolve
<dael> rego: Yes. To resolve the % when the size is definite, but not when indefinite. width is only indefinite for intrinsic sizes.
<dael> fantasai: That gets to the point where we wanted symmetry and we don't have that.
<dael> Rossen_: Same concern. Only thing that is symmetric is we're talking definite vs indefinite instead of width and height. I wasn't going to object hard, but I'm with fantasai that we want to keep as symmetric as possible. Just because of how flow layout works today more often then not width wiill be definite and height indefinite or vice versa.
<dael> rego: There is the other issue about how % tracks work where they should be symmetric and resolve always. So maybe that's an option here. But no one is supporting the heights for % rows yet. Maybe that's the way to go.
<dael> Rossen_: This is option f?
<dael> rego: Option b I guess.
<rego> https://github.com/w3c/csswg-drafts/issues/1921
<dael> rego: Following what we resolved in issue #1921. It's not impl, but we resolved that way in the past.
<dael> Rossen_: Going through 1921 resolution it makes sense, but impl have to catch up. Once we do we'll have symmetric behavior. Then we need to do same thing for gaps. That would be behavior b.
<dael> rego: For multi column it's what we're doing right now. We're always resolving the % because multi col only has column gap.
<dael> Rossen_: Right but for grid it's both column and row.
<dael> dbaron: I'm not an expert on grid, but I felt like I liked the original proposal from rego a bit more. There's a lot of stuff where width and height just doesn't work the same way. Things that happen in intrinsic width pass shouldn't effect layout pass.
<dael> Rossen_: I wouldn't disagree in general, but I would slightly disagree in teh case of grid because we've been trying for as symmetric as possible. We had a fully symmetric implementation and that fell through. It will require more passes to make symmetry stable, but it's possible.
<dael> Rossen_: Let's try and move forward.
<dael> Rossen_: Proposal in the issue was we resolve to have a contribute 0 and resolve as percentage
<dael> Rossen_: Correct?
<dael> rego: That's not what's in the issue, but yeah. That's the new proposal to keep symmetric behavior following the tracks resolution.
<dael> Rossen_: Which is option B.
<dael> Rossen_: Any opinions or objections?
<dael> RESOLVED: Take option B (contribute 0 and resolve as percentage for column and row gaps)
Member

css-meeting-bot commented May 2, 2018

The Working Group just discussed Percentages gaps and intrinsic size, and agreed to the following resolutions:

  • RESOLVED: Take option B (contribute 0 and resolve as percentage for column and row gaps)
The full IRC log of that discussion <dael> Topic: Percentages gaps and intrinsic size
<fantasai> s/contribute to fr resolution/contribute to fr track minimums/
<dael> github: https://github.com/w3c/csswg-drafts/issues/509
<rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-381759138
<dael> Rossen_: Let me paste the time stamp instead of the whole issue
<dael> Rossen_: rego has it
<dael> rego: I reopened it.
<dael> rego: All browsers now support % in column gap in multi column
<dael> rego: All of them are interop. But they're not following new text in spec. Chrome and webkit we don't see an easy way to follow for width so I suggest we change the text to says something like % resolves to 0 when resolved against the base size. Something like the indefinite size is what we should say because the logical width is not indefinite.
<dael> rego: That causes overflow in some cases but I don't think there's a way to do it better and changing spec text would make it match impl.
<fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-356256873
<dael> fantasai: If we go back to the options before there was option b which was contribute 0 resolve as 0. Igalia is saying we don't know when to resolve if it's at 0 or not because that info isn't part of what's given to grid when it's doing layout.
<dael> fantasai: It's easier for impl if they just continue tracking or continue tracking into the container and therefore the percent resolves.
<fantasai> s/or continue tracking into the container/continue tracking just the information they have already, i.e. the size of the container/
<dael> Rossen_: I can't speak to other impl, in our grid impl we know if we're doing layout for sizing and measuing the content vs sizing when we're not shrink to fit. From that PoV I don't think we have anything in the spec that prevents a impl from passing this info
<dael> Rossen_: Looking at current interop around this....based on the codepen from the issue seemed like we all agree on behavior of grid.
<fantasai> s/that info/information on whether the current size of the container was a content-based size/
<dael> Rossen_: rego what I hear is once we go down...if we change resolution from b to d, contribute 0 resolve as 0, we minimize amount of potential overflow, but also drop ability to have % column gaps. Last time we discussed the one constant feedback from webdev was they don't want to drop the gap. It's more intutive if you see overflow and go and fix it rather then add values and have no effect.
<dael> Rossen_: I'm not sure we're driving toward an ergonomic.
<dael> fantasai: Previous resolution was b and we're proposing switch to d.
<dael> Rossen_: In that case I agree and misunderstood the proposal.
<fantasai> s/ergonomic/ergonomic solution/
<dael> rego: It would be more like f.
<dael> rego: It would be like when grid resolves % for width and height in regular blocks they're different so same here.
<dael> Rossen_: Okay, I'm with you.
<dael> Rossen_: Other opinions on this?
<dael> fantasai: Proposal is to resolved the % in column gaps but not row gaps?
<dael> s/resolved/resolve
<dael> rego: Yes. To resolve the % when the size is definite, but not when indefinite. width is only indefinite for intrinsic sizes.
<dael> fantasai: That gets to the point where we wanted symmetry and we don't have that.
<dael> Rossen_: Same concern. Only thing that is symmetric is we're talking definite vs indefinite instead of width and height. I wasn't going to object hard, but I'm with fantasai that we want to keep as symmetric as possible. Just because of how flow layout works today more often then not width wiill be definite and height indefinite or vice versa.
<dael> rego: There is the other issue about how % tracks work where they should be symmetric and resolve always. So maybe that's an option here. But no one is supporting the heights for % rows yet. Maybe that's the way to go.
<dael> Rossen_: This is option f?
<dael> rego: Option b I guess.
<rego> https://github.com/w3c/csswg-drafts/issues/1921
<dael> rego: Following what we resolved in issue #1921. It's not impl, but we resolved that way in the past.
<dael> Rossen_: Going through 1921 resolution it makes sense, but impl have to catch up. Once we do we'll have symmetric behavior. Then we need to do same thing for gaps. That would be behavior b.
<dael> rego: For multi column it's what we're doing right now. We're always resolving the % because multi col only has column gap.
<dael> Rossen_: Right but for grid it's both column and row.
<dael> dbaron: I'm not an expert on grid, but I felt like I liked the original proposal from rego a bit more. There's a lot of stuff where width and height just doesn't work the same way. Things that happen in intrinsic width pass shouldn't effect layout pass.
<dael> Rossen_: I wouldn't disagree in general, but I would slightly disagree in teh case of grid because we've been trying for as symmetric as possible. We had a fully symmetric implementation and that fell through. It will require more passes to make symmetry stable, but it's possible.
<dael> Rossen_: Let's try and move forward.
<dael> Rossen_: Proposal in the issue was we resolve to have a contribute 0 and resolve as percentage
<dael> Rossen_: Correct?
<dael> rego: That's not what's in the issue, but yeah. That's the new proposal to keep symmetric behavior following the tracks resolution.
<dael> Rossen_: Which is option B.
<dael> Rossen_: Any opinions or objections?
<dael> RESOLVED: Take option B (contribute 0 and resolve as percentage for column and row gaps)

@css-meeting-bot css-meeting-bot removed the Agenda+ label May 2, 2018

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren May 3, 2018

So, just to make sure I understand the resolution above correctly, the resolution is that gaps resolves percentages the same as was decided for margin/padding in #347, except that the percentage basis for grid-row-gap/grid-column-gap continues to be same-axis content-box size, right?

Also, since there is some discussion of percentage track sizes in general in this issue - those continue to "behave as auto" when the percentage base is indefinite as before, right?

MatsPalmgren commented May 3, 2018

So, just to make sure I understand the resolution above correctly, the resolution is that gaps resolves percentages the same as was decided for margin/padding in #347, except that the percentage basis for grid-row-gap/grid-column-gap continues to be same-axis content-box size, right?

Also, since there is some discussion of percentage track sizes in general in this issue - those continue to "behave as auto" when the percentage base is indefinite as before, right?

@mrego

This comment has been minimized.

Show comment
Hide comment
@mrego

mrego May 3, 2018

Member

So, just to make sure I understand the resolution above correctly, the resolution is that gaps resolves percentages the same as was decided for margin/padding in #347, except that the percentage basis for grid-row-gap/grid-column-gap continues to be same-axis content-box size, right?

I understand the same thing regarding that.

Also, since there is some discussion of percentage track sizes in general in this issue - those continue to "behave as auto" when the percentage base is indefinite as before, right?

No, they would behave as auto but then they'll be resolved during layout.
That's what all browsers do for column tracks, but none for row tracks.
That was resolved in the past in #1921, but none of the implementations have supported this yet.

With the resolution here from yesterday, gaps would be working pretty similar to tracks.
Contributing zero during intrinsic size computation and resolving after layout,
so row-gap will work the same than column-gap.

So for gaps if we have this example:

<div style="display: inline-grid; border: 10px dotted red;
            grid-template-columns: auto auto; grid-gap: 25%;
            font: 50px/1 Ahem;">
  <div style="grid-column: 1; background: magenta;">XÉpp</div>
  <div style="grid-column: 2; background: cyan;">XÉpp</div>
  <div style="grid-column: 1 / 3; background: yellow;">XÉpp</div>
</div>

It'll have a column gap of 100px and a row gap of 25px. While the size of the grid container will be 400px width and 100px height.

Expected output of the previous example

Member

mrego commented May 3, 2018

So, just to make sure I understand the resolution above correctly, the resolution is that gaps resolves percentages the same as was decided for margin/padding in #347, except that the percentage basis for grid-row-gap/grid-column-gap continues to be same-axis content-box size, right?

I understand the same thing regarding that.

Also, since there is some discussion of percentage track sizes in general in this issue - those continue to "behave as auto" when the percentage base is indefinite as before, right?

No, they would behave as auto but then they'll be resolved during layout.
That's what all browsers do for column tracks, but none for row tracks.
That was resolved in the past in #1921, but none of the implementations have supported this yet.

With the resolution here from yesterday, gaps would be working pretty similar to tracks.
Contributing zero during intrinsic size computation and resolving after layout,
so row-gap will work the same than column-gap.

So for gaps if we have this example:

<div style="display: inline-grid; border: 10px dotted red;
            grid-template-columns: auto auto; grid-gap: 25%;
            font: 50px/1 Ahem;">
  <div style="grid-column: 1; background: magenta;">XÉpp</div>
  <div style="grid-column: 2; background: cyan;">XÉpp</div>
  <div style="grid-column: 1 / 3; background: yellow;">XÉpp</div>
</div>

It'll have a column gap of 100px and a row gap of 25px. While the size of the grid container will be 400px width and 100px height.

Expected output of the previous example

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren May 3, 2018

No, they would behave as auto but then they'll be resolved during layout.

Right, that's what I meant with "when the percentage base is indefinite" qualification
and with referring to the resolution in #347, which uses exactly that language.

That's what all browsers do for column tracks, but none for row tracks.
That was resolved in the past in #1921, but none of the implementations have supported this yet.

Interesting. I wasn't aware that was the intention of #1921.
But yes, it does seem reasonable that both axes behave the same for symmetry, although it does make the track sizing dependencies circular. (I filed this bug to fix this in Gecko.)

MatsPalmgren commented May 3, 2018

No, they would behave as auto but then they'll be resolved during layout.

Right, that's what I meant with "when the percentage base is indefinite" qualification
and with referring to the resolution in #347, which uses exactly that language.

That's what all browsers do for column tracks, but none for row tracks.
That was resolved in the past in #1921, but none of the implementations have supported this yet.

Interesting. I wasn't aware that was the intention of #1921.
But yes, it does seem reasonable that both axes behave the same for symmetry, although it does make the track sizing dependencies circular. (I filed this bug to fix this in Gecko.)

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren May 3, 2018

Another testcase:

<style>
.grid {
  display: inline-grid;
  grid-row-gap: 10%;
  border: solid;
}

x { background: lightgrey; }
</style>

<div class="grid">
  <x>CSS Grid</x>
  <x>IS</x>
  <x>AWESOME</x>
</div>

Expected rendering:
grid-awesome

Coffee mug salesmen around the world, rejoice!

MatsPalmgren commented May 3, 2018

Another testcase:

<style>
.grid {
  display: inline-grid;
  grid-row-gap: 10%;
  border: solid;
}

x { background: lightgrey; }
</style>

<div class="grid">
  <x>CSS Grid</x>
  <x>IS</x>
  <x>AWESOME</x>
</div>

Expected rendering:
grid-awesome

Coffee mug salesmen around the world, rejoice!

fantasai added a commit that referenced this issue May 4, 2018

[css-align-3] Percentage gaps resolve against zero for intrinsic size…
… contribution, resolve against containing block during layout. #509
@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai May 4, 2018

Contributor

@MatsPalmgren Truly, this is why I hate percentages in CSS. :/

Anyway, pushed changes. Please re-open if they're wrong, or if there's something else the CSSWG needs to consider.

Contributor

fantasai commented May 4, 2018

@MatsPalmgren Truly, this is why I hate percentages in CSS. :/

Anyway, pushed changes. Please re-open if they're wrong, or if there's something else the CSSWG needs to consider.

@fantasai fantasai closed this May 4, 2018

@fantasai fantasai removed the Needs Edits label May 4, 2018

fergald added a commit to fergald/csswg-drafts that referenced this issue May 7, 2018

[css-align-3] Percentage gaps resolve against zero for intrinsic size…
… contribution, resolve against containing block during layout. #509

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}

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

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