[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

[fantasai]

Sorry, wrong issue.