Re: Fwd: [css-grid] question on clamping grid items to fixed track size

-------- Forwarded Message --------
Subject: Re: [css-grid] question on clamping grid items to fixed track size
Date: Sun, 11 Feb 2018 23:22:09 -0800
From: fantasai
To: Mats Palmgren

On 02/11/2018 07:06 PM, Mats Palmgren wrote:
 > Hello Elika,
 >
 > Sorry for intruding but I have a question about the Grid spec that I think
 > is important enough to reach out directly to confirm I understand the spec
 > correctly.

You're not intruding, it is literally my *job* to make sure your questions
get good answers. :) I appreciate your questions, and I can only hope I can
live up to the request.

 > Here's an example to illustrate:
 >
 > <style type="text/css">
 > .grid {
 >    display: inline-grid;
 >    grid-template-columns: minmax(auto, 0px);
 >    border: 2px solid blue;
 >    margin-bottom: 2px;
 > }
 >
 > .grid div {
 >    background: grey;
 >    width: 20px;
 >    height: 10px;
 > }
 > </style>
 >
 > <div class="grid">
 >    <div></div>
 > </div>
 >
 > As I understand it, the grid item width, column size, and grid container
 > width should all be zero in this case.  Is this correct?

Per spec, I think so. See below.

 > The text about clamping grid items in §6.6 says:
 > "... its specified size and content size in that dimension (and the input
 > to the transferred size in the other dimension) are further clamped ..."
 > https://drafts.csswg.org/css-grid/#min-size-auto
 >
 > 20px qualifies as a "specified size" here and should be clamped to zero.
 >
 > I'm assuming that the clamping in §6.6 occurs regardless of whether
 > we're sizing the grid container under a min-content constraint,
 > max-content constraint, or no constraint.  Is this correct?

Yes.

 > I'm also assuming that the clamping in §6.6 occurs regardless of the value
 > of justify-/align-self.  Is this correct?

Yes.

Walking through the spec...

https://www.w3.org/TR/css-grid-1/#valdef-grid-template-columns-minmax>
 > minmax(min, max)
 >     Defines a size range greater than or equal to min and less than
 >     or equal to max. If max < min, then max is ignored and
 >     minmax(min,max) is treated as min.

If `auto` is greater than `0px`, then it wins.

 > auto
 >     As a maximum, identical to max-content. As a minimum, represents
 >     the largest minimum size (as specified by min-width/min-height)
 >     of the grid items occupying the grid track.

In this case, the largest min-width of the items is the min-width of
the div, which has `min-width: auto`. This specifies an automatic
minimum size, defined in 6.6..

https://www.w3.org/TR/css-grid-1/#min-size-auto
 > The automatic minimum size for a grid item in a given dimension is
 > its specified size if it exists [...]

So we start with an automatic minimum of 20px...
https://bugzilla.mozilla.org/show_bug.cgi?id=1427608

 > However, if the grid item spans only grid tracks that have a fixed
 > max track sizing function, its specified size and content size in
 > that dimension (and the input to the transferred size in the other
 > dimension) are further clamped to less than or equal to the stretch
 > fit the grid area’s size (so as to prevent the automatic minimum
 > size from forcing overflow of its fixed-size grid area).

But it gets clamped to 0px. So the used min-width of the item is 0px,
and thus the track's sizing function becomes minmax(0px, 0px), resulting
in a track size of zero.

Now here's where judgement comes in: the goal of the spec in this last
clamping operation is to prevent the automatic minimum size from forcing
overflow. But in this case, because the min of the minmax() function would
widen the track to fit the automatic minimum, there would be no overflow.

So now we have a spec issue: should we adjust the cases in which we are
clamping the automatic minimum so that this case--where the min track
sizing function would be larger than the fixed maximum--does not clamp?
That is, should we say that the max track sizing function only clamps
the automatic minimum size if it would actually clamp the track at that
size?

 > (I'm working on https://bugzilla.mozilla.org/show_bug.cgi?id=1427608
 > and I find that Chrome also has bugs in this area.)

~fantasai

Received on Monday, 26 March 2018 19:46:27 UTC