Re: [csswg-drafts] [css-grid] Percentages and intrinsic size

> 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:
```html
<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.

![Example of back computing percentage gaps with intrinsic tracks](https://user-images.githubusercontent.com/11602/31122672-0699ecf4-a83d-11e7-99d9-a268f5b26811.png)

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.

-- 
GitHub Notification of comment by mrego
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333812409 using your GitHub account

Received on Tuesday, 3 October 2017 11:19:40 UTC