Csswg-drafts: [css-grid] Percentages gaps and intrinsic size

[mrego]

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._

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>

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>

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.

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>

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>

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]

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.

[fantasai]

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]

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

[meyerweb]

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]

(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]

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]

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]

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

[rachelandrew]

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]

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]

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]

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.

• 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]

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]

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]

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]

• 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%;.

[svillar]

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]

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

[tabatkins]

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]

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

[tabatkins]

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]

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]

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]

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>

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>

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]

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

[FremyCompany]

This resolution was extended to flexbox margins in #347
It was mentioned that the text of the resolution is specifically for width, and it was specified that for percentages margins the "intrinsic width" is 0px

[fantasai]

Ok, edits checked in for track sizing, so we're down to only how to treat percentage gaps in indefinitely-sized containers. The proposed solutions so far are:

A = contribute back-computatation ratio, resolve as percent

Back-compute percentages on gaps: the intrinsic size of the grid container is the sum of the intrinsic sizes of the tracks multiplied by a ratio computed from the sum of the percentage gaps. (@MatsPalmgren will provide the exact formula for this ratio, which presumably includes some clamping, and is implemented in Gecko.) The gaps then resolve against that size.

B = contribute zero, resolve as percent

Percentage gaps contribute zero, resolve against intrinsic size: the intrinsic size of the grid container is the sum of the intrinsic sizes of the tracks. The gaps then resolve against that size in both axes.

C = contribute auto, resolve as percent

Percentage gaps contribute based on content that was spanned, exactly as if they were percentage tracks. The intrinsic size of the grid container is the sum of the intrinsic sizes of the tracks assuming the gaps are also `auto` tracks. The gaps then resolve against that size in both axes.

D = contribute zero, resolve as zero

Percentage gaps contribute zero, resolve against intrinsic size: the intrinsic size of the grid container is the sum of the intrinsic sizes of the tracks. The gaps also resolve as zero: the percentage is treated exactly as zero inside indefinite containers.

E = contribute auto, resolve as auto

Percentage gaps contribute based on content that was spanned, exactly as if they were percentage tracks. The intrinsic size of the grid container is the sum of the intrinsic sizes of the tracks assuming the gaps are also `auto` tracks. The gaps are also resolved as auto: they behave exactly as an ''auto'' track inside indefinite containers, and therefore may vary in size.

F = contribute zero, resolve as percent (for column-gap) or zero (for row-gap)

B for column gaps (contribute zero, resolve as percentage), D for row gaps (contribute zero, resolve as zero). (This is apparently what Blink does?)

E is right out. Agenda+ to discuss, @MatsPalmgren it would be great if you provided the formula so people don't dismiss your proposal as “but that's hard” and also if we can have you involved in the discussion. :)

[mrego]

About the edits in the spec:

then the 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 browsers do that for columns, but none of them do that for rows we'd need to change the behavior there. Are we sure we really want to do it?
For columns percentage will behave like in regular blocks for width, but for rows they will work different than regular blocks for heights.
A very simple example:

<div style="display: inline-grid; border: thick solid;
            grid: 200% / 200%;">
  <div style="background: magenta">foobar</div>
</div>

Ok, edits checked in for track sizing, so we're down to only how to treat percentage gaps in indefinitely-sized containers.

Note that in TPAC the resolution was that both percentage tracks and gaps should resolve percentages in the same way.
RESOLVED: percentage gaps and percentage tracks use same resolution method

So I guess the new discussion implies that they'll be now behaving differently.

[mrego]

A = contribute back-computatation ratio, resolve as percent
Back-compute percentages on gaps: the intrinsic size of the grid
container is the sum of the intrinsic sizes of the tracks multiplied
by a ratio computed from the sum of the percentage gaps.
(@MatsPalmgren https://github.com/matspalmgren will provide the
exact formula for this ratio, which presumably includes some
clamping, and is implemented in Gecko.) The gaps then resolve
against that size.

So here the formula (if I got it right) would be something like.
sum of the track sizes / (1 - sum of percentages)

For example if you've grid-template-columns: 50px 50px; grid-column-gap: 20%; you'll do:
(50 + 50) / (1 - 0.20)
The result would be 125px and the gap size would be 25px (20% of 125px).

We think we've found an issue with this idea. Let's use another example:

<div style="display: inline-grid; font: 10px/1 Ahem; border: thick dotted;
            grid-template-columns: auto 50px; grid-template-rows: 20px 20px; grid-column-gap: 20%;">
  <div style="grid-column: 1; background: pink; color: magenta;">X</div>
  <div style="grid-column: 2; background: cyan; color: blue;">X</div>
  <div style="grid-column: 1 / span 2; background: yellow; color: maroon;">XXXXXXXXXXXXXXX</div>
</div>

Here we've 2 tracks, the first track one is auto and the 2nd one has 50px. Then we've a gap of 20%.
Then we've an item that is spanning both tracks with a size of 150px.

To backcompute the perctenage gap, Firefox does 150 / (1-0.2) = 187.5. And the gap is 37.5px (20% of 187.5px).
But then we've a grid container of 187.5px when the biggest element is 150px, so we don't need such a big grid container.
Would we want this kind of result?

B = contribute zero, resolve as percent
Percentage gaps contribute zero, resolve against intrinsic size: the
intrinsic size of the grid container is the sum of the intrinsic
sizes of the tracks. The gaps then resolve against that size in both
axes.

On Blink we do this for column gaps.
Which is somehow similar to what happens with perecentea widths in regular blocks.

C = contribute auto, resolve as percent
Percentage gaps contribute based on content that was spanned,
exactly as if they were percentage tracks. The intrinsic size of the
grid container is the sum of the intrinsic sizes of the tracks
assuming the gaps are also auto tracks. The gaps then resolve
against that size in both axes.

This would be really hard to implement for us.
The problem is that right now we consider that the gaps have a fixed size during the track sizing algorithm.
If we need to consider them as auto tracks, then we'll need to deal on how the spanning elements are placed on those extra tracks, which won't be easy at all for our implementations.

D = contribute zero, resolve as zero
Percentage gaps contribute zero, resolve against intrinsic size: the
intrinsic size of the grid container is the sum of the intrinsic
sizes of the tracks. The gaps also resolve as zero: the percentage
is treated exactly as zero inside indefinite containers.

This is what we do for rows in Blink.
Which is somehow similar to what happens with perecentea heights in regular blocks.

E = contribute auto, resolve as auto
Percentage gaps contribute based on content that was spanned,
exactly as if they were percentage tracks. The intrinsic size of the
grid container is the sum of the intrinsic sizes of the tracks
assuming the gaps are also auto tracks. The gaps are also resolved
as auto: they behave exactly as an ''auto'' track inside indefinite
containers, and therefore may vary in size.

I guess this is discarted becuase the size of the gaps will be different, which doesn't make a lot of sense.

F = contribute zero, resolve as percent (for column-gap) or zero (for
row-gap)
B for column gaps (contribute zero, resolve as percentage), D for
row gaps (contribute zero, resolve as zero). (This is apparently
what Blink does?)

Yeah, that's what we do now for gaps.

We're more inclined to do anyone of B, D or F.

[mrego]

One thing I don't know how is resolved for percentage gaps is when the sum of the percentages are 100% or more.
Example:

grid-template-columns: 20px 20px; grid-column-gap: 100%;

Another example:

grid-template-columns: 20px 20px 20px; grid-column-gap: 50%;

Current Firefox implementation has issues with that things:

Also it seems it was agreed that percentage margins shouldn't back-compute either (
https://github.com/w3c/csswg-drafts/issues/347), so I don't know if it makes any sense to do it only for grid gaps.

[mrego]

Again more comments about the new text on the spec:

then the 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.

As I said for columns that's what all browser do, but for rows that's not the case (and I'm not 100% sure if it'd be possible to do that or not).

Let me explain my thoughts. For a grid container with indefinite width and height, on Blink/WebKit we do the following things:

1. First we calculate the intrinsic width (for that we run the algorithm for the columns).
   If we find a percentage column we treat it as auto.
   As a result we set the intrinsic width of the grid container.
2. Then we layout the grid container, first the columns and then the rows:
   
   
   
   • For columns, if we find a percentage column at this stage, we simply resolve the percentage against the intrinsic width. Like it happens on regular blocks for percentage widths.
   
   
   • For rows, if we find a percentage row we treat it as auto (we cannot resolve it yet, as we don't have an intrinsic height). This is the same that happens on regular blocks for percentage heights.
     
     With these result we set the grid container height.
   
   

So we're not resolving the percentages for rows. If we want to resolve the percentage at this point, we'd need to re-run the algorithm (an extra pass) setting the previously computed height as a grid container fixed height. In that way when we're in 2. For rows, we'll resolve the percentage rows against that height calculated in the previous iteration.
If we do that, percentage rows will behave like percentage colums, but different to percentage heights in regular blocks.

Before trying to implement something like this we'd like to know if the rest of the browsers will be happy to do so (cc @MatsPalmgren @atanassov).

[css-meeting-bot]

The Working Group just discussed Percentages and intrinsic size (decide on indefinitely-sized containers).

The full IRC log of that discussion

<dael> Topic: Percentages and intrinsic size (decide on indefinitely-sized containers)

<fantasai> ACTION: file follow-up issue to #1777

<trackbot> Error finding 'file'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.

<dael> github: https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096

<dael> astearns: Sounds like we have everything resolved except dealing with indefinitely sized containers.

<dael> astearns: I have no run through the presented options.

<dael> fantasai: I haven't either.

<dael> fantasai: I can describe, but rego made a lot of comments I haven't reviewed.

<dael> astearns: rego is here anything you can summerize or should we move this to next week?

<dael> rego: I was commenting because some may not be possible, but realized the previous resolution...the issue was about % in gutters or gaps. We resolved for % tracks something that changes all impl and I"m not sure we really want to do that. Prob better to discuss more on GH first and come back

<dael> astearns: sgtm. Anyone else have a comment now?

<dael> rego: Would be good for other impl to look through the last comments.

<dael> astearns: Def. rossen is out this week but might have time next week. Anyone know what Mats is up to? [silence] let's table for now and come back once this has been discussed more on GH

[fantasai]

Wrt https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333759551 / https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334437618 about the symmetry of percentage resolution for rows and columns: the changes to the spec treating them as symmetrical was intentional, as this is as far as we can tell what the WG resolved. An overarching principle of the grid layout algorithm was to treat rows and columns symmetrically, so this seemed consistent with that goal. Tab and I aren't specifically opposed to making them asymmetrical to match implementations; we're happy to spec whichever behavior implementers and authors prefer. It would be good to hear from @MatsPalmgren, @atanassov, @rachelandrew, and @jensimmons here.

Wrt percentage gaps, we just listed all the possible options. Imho options C and E are super broken--E because of the variation in gaps across the grid, and C because in that method the gap tells the grid algorithm "I can handle the extra space requirements of this spanning element, assign that space to me!" and then during percentage resolution splits off that space amongst all the gaps which isn't helpful. :) I think I'd object to either one. Option A is listed because @MatsPalmgren was advocating for it.

[css-meeting-bot]

The Working Group just discussed Percentages and intrinsic size.

The full IRC log of that discussion

<dael> Topic: Percentages and intrinsic size

<dael> github: https://github.com/w3c/csswg-drafts/issues/509

<tantek> ready for CSS3-UI PR?

<dael> florian: Briefly on previous, but that prob takes us to a passing test suite and we can begin to move toward rec

<tantek> SGTM

<dael> Rossen: fantasai summary?

<fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333759551

<dael> fantasai: There is...the never ending topic keeps branching into variations. The current variation has 2 issues. First is that the resolution we took on % sizing, we made edits that are symmetrical for block and inline axis. Igalia guys said we impl asymmetric. So that's an issue of do we want to change for symmetric.

<dael> fantasai: Summary comment ^

<dael> fantasai: Basically, I think we resolved this is correc tbehavior, but if someone thinks different we should discuss.

<fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096

<dael> fantasai: Second is what do we do with % gaps. All options ^

<rego> related to first issue, this comment is also important: https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334437618

<dael> fantasai: C and E are terrible. F is impl by chrome. B and D are the ones we're combining. Gecko does A.

<dael> fantasai: I don't have a strong opinion, but we should think carefully. We havea mix of impl and we need impl, spec, and authors to agree on best option.

<fantasai> s/we're/they're/

<dael> rego: Regarding first issue, I think the change to make symmetric for columns and rows is contrary to rest of impl. We've been checking options and if we do it we have to do extra passes. We'd like to check if other impl will do that or if we should revert status.

<dael> fantasai: Another pass for track sizing algo, or jsut through the items?

<dael> rego: We believe it needs another pass of the algo. We were finding some strange issues to resolve that.

<dael> Rossen: Are you talking about the % resolution of gaps?

<dael> rego: Tracks

<dael> Rossen: Okay.

<dael> Rossen: And there's no interop?

<dael> rego: There is interop, but it's contrary to what the resolution says.

<dael> fantasai: It's an intrinisically sized grid with a % size grid track. Does that % resolve. It does with columns, not with rows. Spec says resolve in both axises.

<dael> TabAtkins: Current is similar to how block works.

<rego> the spec text is:

<rego> > then the 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.

<dael> Rossen: But block has nothing to do with grid. We shouldn't define one layout system with a completely different. The original desire to keep things symmetric in grid was based on how a good system should work. it's up to us to decline from that model, that's fine if this is what everyone agrees we should do. but let's not justify current with what we internded.

<dael> TabAtkins: Sure. We're just saying block behavior wasn't an accident. It was reasonable to avoid extra layout in common cases. Might not be right for grid, but there was good reason behind our choice to copy it over.

<dael> Rossen: Trying for progress. Current proposal is to back out on our original resolution from Seattle and go with the asymmetric one.

<dael> TabAtkins: Intention isn't to get a resolution this week, it's to bring it up for talk later.

<dael> Rossen: If you're not asking for a resolution, let's keep working on it. We should resolve on this during F2F at the latest.

<dael> fantasai: agree

<rego> this was the change from the resolution: https://github.com/w3c/csswg-drafts/commit/15cf0c6d56efdbb44383134ebe19dff672b01546

<dael> Rossen: We should put a time limit on this. We'll have to get consensus.

<tantek> It does feel like an issue that would benefit from seeing / discussing diagrams in person at the f2f

<tantek> Have we made progress on this at previous f2fs?

<dael> fantasai: It would be useful for people to think and comment on the GH. Understanding the ramifications of this is most useful if people t hink through use cases and behavior and we're not going to get that around the table.

<dael> Rossen: Agree.

<dael> Rossen: Did you want to discuss gap % resolution or should we let that go?

<dael> TabAtkins: I don't think we'd get that in 4 minutes

[MatsPalmgren]

This is the code for back-computing percentage grid-gaps in Gecko:
http://searchfox.org/mozilla-central/rev/d0448c970093f94bd986a21d3a9e8c366b316eb4/layout/generic/nsGridContainerFrame.cpp#4768
http://searchfox.org/mozilla-central/rev/d0448c970093f94bd986a21d3a9e8c366b316eb4/layout/base/nsLayoutUtils.h#1484

Assume the grid-gap is calc(Apx + B%) and we have N gaps,
then we calculate the intrinsic size (Size) as:

1. let Size = sum all track lengths
2. add Apx * N to Size
3. let Percent = B% * N
4. if Size or Percent is negative goto 7
5. if Percent >= 100% then let Size = "infinity", goto 7
6. let Size = Size / (100% - Percent)
7. if Size is negative let Size be zero

(A or B may be a negative number)

Percentage grid-gaps also affect how we calculate the number of
repeat auto-fill/fit tracks (when the size is auto), that code lives here:
http://searchfox.org/mozilla-central/rev/d0448c970093f94bd986a21d3a9e8c366b316eb4/layout/generic/nsGridContainerFrame.cpp#905
it's basically the same algorithm as above, repeated in a loop
with N=1, N=2 etc until the min/max are satisfied.

All of the above is symmetrical in both axes.

Note that once the intrinsic size is known it is treated as
a definite percentage basis, so for example:

.grid {
  display: inline-grid;
  grid: repeat(2,20px) / repeat(2,20px);
  grid-gap:calc(10px - 10%);
}

The content area size of the grid is 50px x 50px, so the final grid-gap
is 10px - (0.1 * 50px) = 5px, which results in a 5px empty space at
the end of the grid.

However, "grid-gap:calc(10px - 50%)" would make the grid-gap negative
so we clamp that to zero.

Some testcases for the above.

Rendering in Firefox.

(BTW, I'm not claiming our handling of a negative percentage part in calc() is ideal -
I just wanted to document what we're currently doing.)

[css-meeting-bot]

The Working Group just discussed Percentages and intrinsic size.

The full IRC log of that discussion

<dael> Topic: Percentages and intrinsic size

<dael> github: https://github.com/w3c/csswg-drafts/issues/509

<dael> Rossen_: mats added a quick explinantion of what Mozilla's back computation looks like for grid-gap.

<dael> Rossen_: I want to ask if anyone is prepared to speak to this issue.

<dael> Rossen_: If not we can push to next week or F2F.

<rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334075296

<dael> rego: Last week we said we'd leave for TPAC. We need more impl. We resolved that we should back compute, but anyway it needs a lot further discussion.

<dael> Rossen_: I agree. It sounds like...I don't see in last week'sresolution we'll discuss for F2F. I'll tag for F2F and remove the agenda+ for weekly calls.

<dael> Rossen_: I propose we switch topics if there are any.

[mrego]

I've opened a new issue to discuss the percentage tracks #1921, leaving this one for percentage gaps/gutters only.

In the new issue we try to explain one of the cases were we believe the new spec text requires an extra pass of the algorithm for percentage rows (as it was commented in a previous confcall).

[css-meeting-bot]

The Working Group just discussed css grid, and agreed to the following resolutions:

• RESOLVED: Option D: percentage gaps in shrink-wrapped grids min-size as 0 and layout as 0

The full IRC log of that discussion

<bkardell_> topic: css grid

<Rossen> github: https://github.com/w3c/csswg-drafts/issues/509

<bkardell_> ??: we have two different issues

<lajava> me

<astearns> s/??/lajava/

<bkardell_> <lajava> :we have undefined width and height

<fantasai> all options for percentage gaps listed in https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096

<bkardell_> <lajava> the issue we are discussing now is for grid gaps

<bkardell_> <lajava> fantasai listed different options after some discussion

<bkardell_> <lajava> our discussion from blink/webkit : we prefer to keep exisitng behavior keeping, treat them as 0 for intrinsic size/layout

<fantasai> lajava: is requesting option F = contribute zero, resolve as percent for columns, resolve as zero for rows

<bkardell_> <lajava> in the issue there is an explanation

<bkardell_> <lajava> we think that what happens in ff is broken with that approach

<bkardell_> <lajava> if we dont do that for margins, we should be consistent

<bkardell_> <lajava> we have to decide from the options fantasai listed and agree to do it the same

<bkardell_> fantasai: my concern with f) in that list is that it has been a goal of grid to have symetric behavior in both axis

<dbaron> fantasai (before previous): I think we agreed to eliminate C and E.

<dbaron> We're discussing the list in https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096 , I assume?

<bkardell_> <lajava> related to that, we think there are issues to do that with tracks as well

<astearns> yes, dbaron

<bkardell_> <lajava> it's not impossible, but there is no browser doing that

<bkardell_> <lajava> all of the browsers consider cols and rows diff

<bkardell_> <lajava> so I'm not sure that should be important in solving for gaps - perhaps we decide not to do it for the tracks

<bkardell_> rachelandrew: there are issues teaching this to authors. generally people understand when you say this will resolve to 0, the goal of having symmetrical gaps would be nice.

<bkardell_> rachelandrew: if we can't have them symmetical, having the rows go to 0 makes sense

<bkardell_> lajava: I agree with that

<bkardell_> ??: are we just talking about intrinsically resized grids

<TabAtkins> s/??/dholbert/

<bkardell_> lajava: d) tries to resolve the same way in both axis

<astearns> so rachelandrew is for F, not D

<bkardell_> rachelandrew: if we didn't have % gaps, if we changed existing behavior ...?

<bkardell_> jensimmons: if you had that situation in the inline direction where you didn't have an explicit width those gaps would also resolve to 0, it's just not a common use case

<bkardell_> jensimmons: if you said you want this to be 100x100px - in both directions the gap would be 10

<bkardell_> jennsimmons: i dont know if what you are describing is that the algo is doing the math diff ?

<fantasai> ScribeNick: fantasai

<dbaron> ScribeNick: dbaron

<frremy> ScribeNick: frremy

<frremy> lajava: there are two reasons we don't want back compute for the gaps

<frremy> lajava: backcomputing when the percentages are close or bigger than 100% the solution isn't that great

<frremy> lajava: the second reason is that we decided not to do that for margins, and so we would like to work the same for gaps

<Rossen> q?

<frremy> dholbert: well, on that, I think margins are just a legacy thing

<frremy> TabAtkins: I would be opposed to anything that could yield to sizes bigger than the max size a browser can allocate

<frremy> TabAtkins: it's very easy to end up in such cases with back-computing

<frremy> Rossen: +1

<frremy> Rossen: for this issue, the currently listed options are on the screen, and the github

<frremy> Igalia would prefer B, D, or F

<frremy> lajava: yes

<frremy> Rossen: Edge's preference would be to keep symmetry

<frremy> Rossen: if resolving in one of the pass is not possible, though, resolving to zero as usual is fine

<frremy> Rossen: F is therefore not a great solution

<frremy> Rossen: between B and D, I would like to hear more opinions

<frremy> TabAtkins: B is expensive, there might be fragmentation issues

<frremy> Rossen: which fragmentation issue?

<frremy> TabAtkins: could contribute, but we could discuss this later when this comes up

<frremy> dholbert: What would happen for auto grid with percent columns?

<frremy> Rossen: let's say you have a 2x2 grid that has to shrink in both dimentions

<frremy> Rossen: if that grid had a size, we would compute properly and things would be symmetric

<frremy> Rossen: but if the grid is floated, we will have to compute percentages has zero

<frremy> Rossen: but in the second pass, we are given a choice

<gregwhitworth> here's the example Rossen is stating: http://jsbin.com/dozonezuvi/edit?html,css,output

<frremy> Rossen: either add the gaps and overflow slightly

<fantasai> The float will have the width & height of 2x item size, then have choice of how to compute percentages

<frremy> Rossen: or you can continue to resolve to zero

<frremy> Rossen: this is the difference between B and D

<gregwhitworth> sorry - wrong snapshot: http://jsbin.com/lalayakuxe/1/edit?html,css,output

<frremy> lajava: Igalia doesn't mind B but the problem is that if you are auto and overflow by default, that seems counter-intuitive

<frremy> Rossen: the only con of D seems that some authors could be unhappy about this

<frremy> Rossen: but I would like to make sure that is really the case

<frremy> Rossen: because authors can still use other units, or give a specified size to the grid

<frremy> fantasai: (reading a summary of the A-F proposals)

<fantasai> A = contribute back-computatation ratio,

<fantasai> resolve as percent

<fantasai> B = contribute zero, resolve as percent

<fantasai> NOT C = contribute auto, resolve as percent

<fantasai> D = contribute zero, resolve as zero

<fantasai> NOT E = contribute auto, resolve as auto

<fantasai> F = contribute zero, resolve cols as percent &

<fantasai> rows as zero

<fantasai> NOTE: only for intrinsically-sized grids

<fantasai> explicit / stretch-fit grids always resolve

<fantasai> Cons:

<fantasai> A = contribution can explode grid

<fantasai> B = unhappy authors with overflowing grids

<fantasai> C = super broken

<fantasai> D = unhappy authors missing % column-gap?

<fantasai> E = even more broken

<fantasai> F = B + D + asymmetrical

<frremy> Rossen + florian discussing why A cannot be fixed

<Rossen> q?

<frremy> (aka, see previous times this was discussed)

<Rossen> ack fantasai

<frremy> jensimmons: Using percentages for gaps for auto-sized things is not great

<frremy> jensimmons: because they will see their gap change size when the content changes

<frremy> jensimmons: so they will realize this is not what they wanted

<frremy> fantasai: yeah, I can see that happening, I'm getting convinced by D too now

<frremy> Rossen: Proposed resolution: gaps expressed in percentages resolved and layouted as 0 in auto-sized directions

<frremy> rachelandrew: there might be a few people that are going to hit this problem if they try to replace parts of an existing layout they cannot entirely control

<frremy> fantasai: but this would apply to cases where the grid is auto-sized

<fantasai> s/auto-sized/shrinkwrapped/

<fantasai> not to cases that have a definite containing block

<frremy> rachelandrew: yes, but I don't know how common that would be

<frremy> iank_: we are at 0.1% of all pages for grid all up

<frremy> iank_: so I guess this case wouldn't be frequent at all

<frremy> Rossen: but the conversation is about porting content that currently uses percentages to grids

<fantasai> s/at all/at all once you consider it has to be also using percentage gaps, in a shrink-wrapped context/

<frremy> Rossen: though I don't really see how they can achieve this today in a way that works in all browsers

<frremy> jensimmons: I think those cases are very fragile currently, they use margins/paddings on floats

<frremy> jensimmons: but in those cases usually, the container has a width, even if it is 100%

<frremy> rachelandrew: (general feeling of doubt, but I didn't catch the exact words)

<Rossen> q?

<frremy> dholbert: so this would only happen about floated grids, and abspos grids

<frremy> dholbert: but in a flexbox, you are suppose to layout as having a definite size after flexing, so percentages would work there right?

<frremy> TabAtkins: correct

<frremy> rachelandrew & jensimmons talking about author's work to port existing things, ex: new york times shipping grid inside bootstraps

<frremy> Rossen: so, would your doubts be enough to raise an exception today?

<frremy> rachelandrew: no, I just wanted to shed some light on this, we can come back on this if needed

<frremy> Rossen: any objection?

<fantasai> D = contribute zero, resolve as zero

<frremy> RESOLVED: Option D: percentage gaps in shrink-wrapped grids min-size as 0 and layout as 0

<fantasai> s/min-size as/contribute/

[fantasai]

Fix checked in as “Percentages resolve to zero when specified against an indefinite size (such as the logical width of a float or the ''height/auto'' logical height of a block-level grid container).”

@mrego @javifernandez @dholbert Please let me know if this is clear or if there are further implications which we need to consider. Thanks!~

[mrego]

Percentages resolve to zero when specified against an indefinite size (such as the logical width of a float or the ''height/auto'' logical height of a block-level grid container).

I think the height: auto part is clear and it's fine.

However I'm not convinced about the width part, basically I'm not sure if there's any case where the width is indefinite.

Let's go to the definite and indefinite definitions in css-sizing:

definite size

A size that can be determined without performing layout; that is, a , a measure of text (without consideration of line-wrapping), a size of the initial containing block, or a or other formula (such the “stretch-fit” sizing of non-replaced blocks [CSS2]) that is resolved solely against definite sizes.

Additionally, the size of the containing block of an absolutely positioned element is always definite with respect to that element.

indefinite size

A size that is not definite. Indefinite available space is essentially infinite.

The edit says as an example of indefinite width "the logical widh of a float". But it seems we don't need to perform any layout to calculate the width a float as defined in CSS2:

Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).

For checking the preferred minimum width and preferred width we don't need to perform a layout, it's somehow what's in the definite size definition as "a measure of text".

In any case, I'd love to get feedback from other implementors as I might be biased due to how Blink/WebKit rendering engine works.

[tabatkins]

Switched "indefinite" for "content-based", to correctly include float widths/etc as well. Please let us know if this resolves the issue!

[mrego]

I guess the content-based thing should work, it'd be nice to have that term defind in css-sizing so we can link to it.

Still I believe that for widths this is going to be tricky to determine on Bink/WebKit, dunno about other engines if this is easier for them.
As usual feedback from other implementors will be really appreciated. :wink:

[mstensho]

Thinking about multicol: As far as I understand, the only problem with percentages is when you have nothing to resolve them against. This will never be the case for multicol, since the logical width is always known, and column-gap percentages are resolved against the logical width of the content box of the multicol container. Am I right?

I'm thinking that this is only an issue for row-gap, if the logical height of the container is auto.

[fantasai]

@mstensho A floated or otherwise shrinkwrapped multicol would also have its percentage tracks resolve to zero--it's not any different from Grid in this respect.

[mstensho]

@fantasai I don't understand the rationale behind this. We're able to resolve the column width to something non-zero, so why not the gap width?

[mrego]

@mstensho The last discussion about what to do with percentage gaps was focused on the following options from a previous comment:

• B = contribute zero, resolve as percent
• D = contribute zero, resolve as zero
• F = contribute zero, resolve as percent (for column-gap) or zero (for row-gap)

F is what currently is implemented in Chromium, Safari and Edge. Firefox has a different implementation to back-compute percentage gaps that was discarded for other issues.
This is following more or less the same line than what happens for percentage widths and heights on regular blocks.

During the discussion a clear goal was to make both grid-column-gap and grid-row-gap symmetric.
For that reason F was discarded and the options were B and D, and finally D was the selected one.

I agree with you that being able to resolve grid-template-columns: 40% 40%; in a floated grid container but not grid-column-gap: 10%; is somehow strange and not very intuitive.

Also knowing that for tracks it was decided to change the percentage rows behavior (see #1921) to be symmetric with what happens for percentage columns; maybe the choice for gaps should have been B instead of D.

[mrego]

We've added support for multi-column column-gap percentages in both Blink and WebKit, but we're not using the last resolution where they should resolve to zero for content-based containers.
We're treating them as zero to compute intrinsic size and then resolving during layout.
That's working the same in all browsers that have column-gap percentage support for multi-column (Chromium, Safari and Edge).
There's a new WPT test that verifies those cases: http://w3c-test.org/css/css-multicol/multicol-gap-percentage-001.html

Why we're not following the last text in the spec?
Because in Blink/WebKit it's not possible for us right now to know during layout that a multicol container is content-based or not. We could try to implement that, but I believe it'll be quite complex and could bring performance penalties, e.g. if you have width: auto you'll need to look through all your parents to check if any of them has width: min-content and you'll be content-based sized then (and many other different scenarios).

At the same time I realized that resolving the percentages gaps in grid containers doesn't imply that you have overflow.
Overflow happens in some cases like:

<div style="display: inline-grid; border: thick dotted;
            grid-template-columns: auto auto; grid-column-gap: 20%;">
  <div style="grid-column: 1; background: magenta;">Hello</div>
  <div style="grid-column: 2; background: cyan;">World!</div>
</div>

But if you have more text, then the overflow is gone:

<div style="display: inline-grid; border: thick dotted;
            grid-template-columns: auto auto; grid-column-gap: 20%;">
  <div style="grid-column: 1; background: magenta;">Hello World!</div>
  <div style="grid-column: 2; background: cyan;">This is just an example.</div>
</div>

With the last resolution, the gap should be zero and you won't have overflow in any case.

[mrego]

I believe we should reopen this issue and modify the text on the spec.

Current text says:

Percentages resolve to zero when specified against a content-based size (such as the logical width of a float or the auto logical height of a block-level grid container).

I think the text should be:

Percentages resolve to zero when specified against an indefinite size (such the auto logical height of a block-level grid container).

The reason is what I have explained in the previous comment, the content-based size term is not valid for the engines.
At least all the browsers (Chromium, Safari, Firefox and Edge) that implement this are consistent with my proposed text, check the following codepen (which is interoperable): https://codepen.io/mrego/pen/XEvGom

So the thing is while you're computing the intrinsic width, the width is indefinite and the percentages are resolved to zero; but during layout the width is never indefinite and percentages are always resolved.
For the heights we don't compute intrinsic heights, so during layout if the height is indefinite the percentage is resolved as zero.

[mstensho]

Makes sense to me. I think what the spec wants to say here is that we should treat percentages exactly as in any other case (e.g. percentage box widths) when the containing block size is shrink-to-fit or similar. I couldn't find anything on it in the CSS Intrinsic & Extrinsic Sizing, though.

[tabatkins]

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]

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)

[MatsPalmgren]

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]

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.

[MatsPalmgren]

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]

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:

Coffee mug salesmen around the world, rejoice!

[fantasai]

@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]

Sorry, wrong issue.