1404476 - repeat(auto-fill/auto-fit, ...) in indefinite grid container should return one track

Status: RESOLVED INVALID

(Core :: Layout, enhancement, P3)

Description

[fantasai]

“When auto-fill is given as the repetition number, if the grid container has a definite size or max size in the relevant axis, then the number of repetitions is the largest possible positive integer that does not cause the grid to overflow its grid container (treating each track as its max track sizing function if that is definite or as its minimum track sizing function otherwise, and taking gap into account); if any number of repetitions would overflow, then 1 repetition. Otherwise, if the grid container has a definite min size in the relevant axis, the number of repetitions is the smallest possible positive integer that fulfills that minimum requirement. Otherwise, the specified track list repeats only once.”

If the grid container is indefinite, then it falls through to the last Otherwise, yielding one track. Gecko currently fills with a lot of tracks.

Example: This grid should have one column:

div {
  display: grid;
  float: left;
  grid-template-columns: repeat(auto-fill, 10%);
}

Testcase: data:text/html;charset=utf-8,%3C!doctype html%3E%0D%0A%3Ctitle%3ETest%3C%2Ftitle%3E%0D%0A%3Cstyle type%3D"text%2Fcss"%3E%0D%0A div %7B%0D%0A display%3A grid%3B%0D%0A float%3A left%3B%0D%0A grid-template-columns%3A repeat(auto-fill%2C 10%25)%3B %0D%0A %7D%0D%0A p %7B border%3A double orange%3B %7D%0D%0A%3C%2Fstyle%3E%0D%0A%0D%0A%3Cdiv%3E%0D%0A %3Cp%3E1%3Cp%3E2%3Cp%3E3%3Cp%3E4%3Cp%3E5%3Cp%3E6%0D%0A%3C%2Fdiv%3E%0D%0A

Comment 1

[Jet Villegas (inactive)]

Elika: this test looks the same in Chromium. Are you asserting that Chrome and Firefox don't follow this spec text?
https://www.w3.org/TR/2015/WD-css-grid-1-20150917/#valdef-repeat-auto-fill

Comment 2

[fantasai]

Yes. Here, I'll paste it in with indentation:

When auto-fill is given as the repetition number,
  if the grid container has a definite size or max size in the relevant axis,
    then the number of repetitions is the largest possible positive integer [...]
  Otherwise, if the grid container has a definite min size in the relevant axis,
    the number of repetitions is the largest possible positive integer that fulfills that minimum requirement.
  Otherwise, the specified track list repeats only once.

The grid container here doesn't have a definite size, max size, or min size, so it falls into the last clause.

Comment 3

[Mats Palmgren (inactive)]

@fantasai I believe both Gecko and Blink render this testcase correctly
according to the relevant specifications.
The column repeat count is resolved three times; the first two are for
determining the float's intrinsic size and in these cases the percentage
basis for 10% is indeed indefinite and the last clause applies. This
results in the float's intrinsic width becoming "1ch + 2*3px".
The third time we resolve the repeat count is during reflow and this
time the percentage basis is definite, namely the intrinsic width, so
we resolve 10% as "0.1 * (1ch + 2*3px)" which results in 10 columns
with very small size. (If you add "font: 20px/1 Ahem" to the test you
get 2.6px in both Gecko/Blink (with some rounding)).

Given that this is a "cyclic percentage" I'm assuming the general rules in:
https://drafts.csswg.org/css-sizing-3/#percentage-sizing
applies (i.e. treat it as indefinite for intrinsic sizing, then resolve against
that result during layout). If you want a different result in this case then
you'd have to add specific spec text for it. I'd be mildly opposed to such
a change though, because it would contradict the general rule that the
inline-size is always definite during layout, so we'd have to add code to
treat it as indefinite for this as a special case. Also, the CSSWG has
specifically resolved that percentages of other properties that resolves
percentages against the content size, e.g. text-indent and gaps / track
sizes, do it like this so doing something different for the repeat size
would be inconsistent.

Comment 4

[fantasai]

@mats I don't think it's at all intuitive for the column count to change between intrinsic sizing and layout. It is not something I would expect, nor is it something I think any author would expect, nor does it help with the fulfillment of the purpose of intrinsic sizing, which is to ensure that boxes fit their content (to the extent that we can performantly do so).

Comment 5

[Mats Palmgren (inactive)]

Asking for an element's intrinsic size currently results in a singular value: a length (that is either its min-content or max-content size, depending on what you asked for). This is what "intrinsic sizing" is and has been since the dawn of CSS. Now you're proposing that the intrinsic "size" should be a set of values, namely a length and a repeat-count[1]. That seems like a rather fundamental change to the CSS layout model to me.

Your example seems rather contrived as well, so it doesn't seem to justify such a fundamental change.

[1] two repeat-counts actually, since the row repeat-count can affect the result in case of grid-auto-flow:column

Comment 6

[fantasai]

I'm not sure how you jumped from my comment to yours. I definitely don't think that an intrinsic size should be anything other than a size. I just think that auto-fill and auto-fit should resolve their counts up front and keep them steady throughout all phases of layout. They're specifically defined to not rely on the results of an intrinsic size calculation so that this is possible.

Comment 7

[Mats Palmgren (inactive)]

What I said is exactly equivalent to propagating that state "throughout all phases of layout". We don't store any state from the intrinsic sizing at all on the boxes themselves and I'd rather not start doing that now.

Comment 8

[Mats Palmgren (inactive)]

Also, it would be very inconsistent if percentages in this particular case does not resolve against the definite inline-size during layout, like all other percentages do.

Comment 9

[fantasai]

We don't store any state from the intrinsic sizing at all on the boxes themselves and I'd rather not start doing that now.

You don't have to store state from intrinsic sizing. You just need to check whether intrinsic sizing was necessary to resolve the size before recalculating the number of columns. I suppose that might require looking up the tree, but it should be doable by only checking computed styles, no?

Also, it would be very inconsistent if percentages in this particular case does not resolve against the definite inline-size during layout, like all other percentages do.

The percentages should indeed resolve.