[css-grid] making percentage grid-gaps zero for the purpose of intrinsic sizing doesn't make sense

[MatsPalmgren]

It was resolved in issue 345 that percentage grid-gaps are zero
for the purpose of intrinsic sizing:
#345

I think this needs to be revisited. It's counterintuitive that
percentage grid-gaps are zero while percentages in other properties
actually influence the intrinsic sizing. Making them zero doesn't
respect the author's intent.

It also contradicts how intrinsic sizing works in general:
#347

I think instead we should take either of these alternative options:

A. specify percentage grid-gap in some reasonable way for
the purpose of intrinsic sizing that harmonize with how
we want intrinsic sizing to work in general (issue 347)

B. move percentage grid-gaps to the next level of the CSS Grid spec

To help make a decision on this I have prototyped A in Gecko and
from what I can tell, it seems fairly easy to implement and spec
something that would work well. Here's an example:
https://people.mozilla.org/~mpalmgren/tests/grid/percent-intrinsic-sizing.html
(last two boxes are grids) and here's how it renders:
https://people.mozilla.org/~mpalmgren/tests/grid/percent-intrinsic-sizing.png

Thanks,
Mats

[fantasai]

I think you're confused. Percentage gaps are defined to be sized exactly the same as an empty percentage-sized track. Is that not what you want?

[mrego]

BTW, I've explained how I understand the percentage gaps in: #345 (comment)

For widths I believe for track sizing we're already doing the same than in your example. In your case the 10% gap is 20px.

For heights it's different, I don't see why you're resolving the 10% as 10px.
I believe the behavior should be the same than if you have a grid like:

  grid: auto 10% auto / 100px 10% 100px;

In that case the 10% column is resolved as 200px (against the intrinsic size).
And the 10% row is resolved as 0px, as the height is indefinite.

It strikes me as odd that for a row gap the 10% would be resolved different than a 10% track.

[MatsPalmgren]

Reply to @fantasai:
No, that's not what I want, and I'm pretty sure it's not what
authors wants either. Grid gap percentages should behave slightly
differently from track sizes during intrinsic sizing.

When calculating intrinsic sizes (after track sizing), I want to
do the following:

  let N = "the number of grid gaps";
  let track_size_sum = "sum of track sizes (excluding grid gaps)";
  let grid_gap_coord_sum = N *
      "computed grid-gap resolved with zero percentage base";
  let coord_sum = track_size_sum + grid_gap_coord_sum;
  let grid_gap_percent_sum = N * "the grid-gap percentage part";
  "intrinsic size" = coord_sum / (1.0 - grid_gap_percent_sum);

This is a very simple calculation, and doesn't involve any
changes to the existing track sizing algorithm or any re-layout.
(and we're basically doing all of the above already - it's just
dividing with (1.0 - grid_gap_percent_sum) that is new)

When calculating the number of repeat(auto-fill/fit) tracks (for
intrinsic sizing) we redo the above calculation for each added
repeat-track.

That's it. No other changes are necessary. (In particular:
percentage track sizes continues to be handled as 'auto')

I'm happy to help you with the spec text for this if you want.

[MatsPalmgren]

Reply to @mrego:
I think you misunderstand how percentages contributes to intrinsic
sizing. If you have:

  grid: 100px 100px / 200px 200px;
  grid-gap: 10%;

then the intrinsic size is ~444.44px.
The grid-gap can't be 40px (10% of 200+200) because that would make
the size 440px and 10% of 440px is 44px, not 40px.
The way to calculate it is as I described above:
size = sum_of_coords / (1.0 - sum_of_percentages)

(i.e. 400 / (1.0 - 0.1) for the example above)

[MatsPalmgren]

FYI, the "size = sum_of_coords / (1.0 - sum_of_percentages)"
formula is how we calculate all intrinsic sizing in Gecko.
(I believe it's what css-sizing should say to resolve #347 )
I want grid percentages to contribute to intrinsic sizing like that
for consistency with general intrinsic sizing as much as possible.

I agree it might be too complicated for percentages in track sizes
so I'm fine with treating them as 'auto', but it's seems easy to
implement for grid gaps.

[fantasai]

Okay, hang on a minute. So you're saying you want to back-compute percentages for grid-gap, but not for track sizes? In both axes or just one? I am somewhat interested in having grid-gaps work identically to similarly-sized empty tracks, for simplicity. I'm also open to other ideas. However, I am still confused about what we're doing wrt percentage sizing, in general, per #347, and maybe we should all have a talk about that first. Can you post some kind of position statement from your/Mozilla's perspective into #347 and we can go from there? (Fwiw, TPAC is next week, so it's a good chance to sort this out.)

[MatsPalmgren]

So you're saying you want to back-compute
percentages for grid-gap, but not for track sizes?

Yes.

In both axes or just one?

Both.

I am somewhat interested in having grid-gaps work identically to
similarly-sized empty tracks, for simplicity.

Sure, I can understand that, but what I suggest is a small amendment
that would be a major benefit for authors. And it makes percentages
here more consistent with how they work in general.

Note that I'm not suggesting making any changes to the track sizing
algorithm. It's a fairly simple additional step after that.
(maybe at the end of §5.2. "Sizing Grid Containers"?)

I'm also open to other ideas.

It might be possible to improve percentage min track sizing too.
One idea is that we could also check that each track with a percentage
min sizing that its current size (from 'auto') is at least the size
it would have using the intrinsic size as the percentage basis.
If not, increase the intrinsic size so that each minimum will be met.
(This is just a heuristic nudge though, I'm not suggesting we should
re-run the track sizing algorithm again after that.)

Can you post some
kind of position statement from your/Mozilla's
perspective into #347 and we can go from there?

I'll discuss this with @dbaron et al.

[fantasai]

So the CSSWG discussed this, and concluded that percentage gaps should be treated identically to empty percentage tracks. However, we're leaving open the issue of how percentage tracks are resolved against an intrinsic parent: they can either be treated as auto (like percentage heights in an auto-height container) or be back-computed (as in table cells) but not the mix of both that causes overflow.

Further discussion of percentage sizing against intrinsic containers will be ongoing; it affects shrinkwrapped blocks (like floats) as well, so is a broader topic. We're hoping to resolve that in Seattle if not sooner.

[mrego]

@MatsPalmgren it would be nice if you can share your thoughts on issue #509 too. Thanks!