Re: [csswg-drafts] [css-grid-2] Resolving padding in indefinite intrinsic size calculation and using that to resolve indefinite size? (#8963)

> > we fall back to the default intrinsic size of 300px by 150px
> 
> This doesn't make sense to me, the grid is not a replaced element. https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes says that 300x150 is for "replaced elements without natural sizes".
> 
> AFAIK what should happen is basically this:
> 
> * 1st we need to know the intrinsic contribution of the grid container. So we resolve `repeat(auto-fill, 100px)`. Per https://www.w3.org/TR/css-grid-2/#auto-repeat it should be 3 repetitions, using the `max-width`. So we run the track sizing algorithm under a min/max-content constraint, we get 3 tracks of 100px each and no gap, so the grid is 300px.
> * Then we use the 300px as the size of the content area of the grid container. There is also a `padding: 10%`, but per https://drafts.csswg.org/css-sizing-3/#min-percentage-contribution it resolves to 0.
> * So the intrinsic contribution is 300px, and the parent element is also sized to 300px.
> * Then we lay out the grid container "for real".
> * We can now resolve `padding: 10%` against the parent, so padding becomes 30px.
> * This means that the border area would be 360px, but we have `max-width: 300px; box-sizing: border-box`, so the content area shrinks to 240px so that the border area doesn't exceed 300px.
> * Now when resolving `repeat(auto-fill, 100px)` we can only have 2 repetitions without overflowing the content area. So we get 2 tracks of 100px each.
> 
> I think it should be analogous in the block axis, maybe Firefox does a different thing since it doesn't implement the 2nd pass (https://bugzilla.mozilla.org/show_bug.cgi?id=1481876).

The discrepancy here is actually in the inline size, where Blink/WebKit resolve to 240px as you describe, and Firefox is the one at 300px. After reading your breakdown, I believe I was incorrect in how some of these values are computed and that you described it more accurately. 

In the block axis, Firefox matches what Blink/Webkit are doing in the inline axis. I don't think it's the second-pass logic as you described. 

Are we in agreement that this particular test case expectations are wrong, and that the inline sizes for cases 16 and 19 should be 240px instead of 300px? If so, I can get a PR ready to update it.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 13 June 2023 22:02:48 UTC