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

-------- Forwarded Message --------
Date: Wed, 14 Feb 2018 19:45:19 +0100
From: Mats Palmgren
To: fantasai

On 2/13/18 1:52 AM, fantasai wrote:
 > If the width of the item is 'auto' and it has 'justify-self: start'
 > (shrinkwraps), then its min-width is zero but its specified width is
 > fit-content(track-size); with a track-size of zero (minmax(0px, 0px))
 > this yields a grid track of zero, a grid container of zero, and an
 > item just large enough for its min-content width, i.e. the width of
 > “foobar”.

No, I think you're mistaken, the track sizing is minmax(auto, 0px),
not minmax(0px, 0px).

For clarity, the testcase is:
<style type="text/css">
.grid {
   display: inline-grid;
   grid-template-columns: minmax(auto, 0px);
}
</style>
<div class="grid">
   <div style="justify-self: start">foobar</div>
</div>

First we determine the shrinkwrap size of the grid container.
We'll assume <body> is wide enough for its max-content size, so its
shrinkwrap size is its max-content size, which per Grid §5.2 is:
"The max-content size (min-content size) of a grid container is
the sum of the grid container’s track sizes (including gutters) in
the appropriate axis, when the grid is sized under a max-content
constraint (min-content constraint)."

and then §11.5.2 "For auto minimums" says:
"If the track has an auto min track sizing function and the grid
container is being sized under a min/max-content constraint, set
the track’s base size to the maximum of its items’ min/max-content
contributions, respectively."

So we set the column size to the width of the text "foobar" here.
The sum of the track sizes is then also that size, so that's
the intrinsic width of the container, not zero.

(If you still remember Gecko code, the above is the result of
GetMinISize()/GetPrefISize() results fed into the CSS2 shrinkwrap algo)

Now we layout (Reflow) the grid container using its intrinsic size as
its definite size.  We're *not* under a max-content constraint now,
so §11.5.2 now says:  "Otherwise, set its base size to the maximum
of its items’ min-size contributions."
which in this case is the item's AMS, which we clamp to zero due
to the 0px track max-sizing.  So in layout the column size is zero.

We then layout the grid item in a containing block with that size.
I agree with you that the item's size is its fit-content(track-size),
but with track-size = 0 we get:
"min(max-content size, max(min-content size, stretch-fit size))"
https://drafts.csswg.org/css-sizing-3/#fit-content-inline-size
"stretch-fit size" the CB size, which is zero
"min-content size" is the item's AMS clamped to zero
"max-content size" is the size of "foobar"
So the item's size in layout is min("foobar", max(0, 0)) = 0.

So, the final results in layout is:
container size = width of "foobar"
columnn size = 0
grid item size = 0

Since you disagree, please point out where I'm wrong above.

====

So, the thing that I think you're missing is that there are three steps
for sizing a shrinkwrap Grid container:

Determining its min-content size, which runs the Track Sizing Algo
under a min-content constraint. (item/column size = 0)

Determining its max-content size, which runs the Track Sizing Algo
under a max-content constraint. (item/column size = "foobar")

Layout, using the shrinkwrap size from the above steps as its definite
size, running the TSA under no constraint. (item/column size = 0)

Also, there's no difference for the 20px case really.
Let's say we replace the item in the example above with:
   <div style="justify-self: start; width:20px"></div>

In this case the item's AMS is 20px, but there's nothing in §6.6 that
prevents clamping the AMS just because it came from its specified size.
So its min size is 0px and its max size is 20px, which makes it no
different from the case above.
So, the final results in layout for this case should be:
container size = 20px
columnn size = 0
grid item size = 0 (min(20px, max(0px, 0px))

To be clear, I'm not claiming that any of this is the desirable layout.
I'm claiming that this is the correct results per the current CSS specs.


/Mats

Received on Monday, 26 March 2018 19:52:53 UTC