W3C home > Mailing lists > Public > www-archive@w3.org > March 2018

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

From: Mats Palmgren <fantasai.lists@inkedblade.net>
Date: Mon, 26 Mar 2018 12:46:45 -0700
To: "www-archive@w3.org" <www-archive@w3.org>
Message-ID: <736ae99b-19f4-d7a3-085a-6205056eedc3@inkedblade.net>
-------- Forwarded Message --------
Date: Mon, 12 Feb 2018 15:27:42 +0100
From: Mats Palmgren
To: fantasai

Thanks for your answers, I really appreciate it.

On 2/12/18 8:22 AM, fantasai wrote:
 > On 02/11/2018 07:06 PM, Mats Palmgren wrote:
 >> 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 originally read the clamping rule in §6.6 as only applying to
Automatic Minimum Size (AMS), because that's what §6.6 is about.
This misunderstanding is what lead to bug 1427608 - we never apply
any clamping to the grid item's max-content size for example, because
that's not a *minimum* size.

I still think §6.6 is rather misleading in this regard, specifically
the "The automatic minimum size for a grid item [...]. However, [...]"
implies to me that only the AMS should be clamped.

I'd suggest that the clamping text at least needs to point out that it
applies to all grid item size calculations, not only when calculating AMS.
Separating the clamping part to its own section would be even better, so that it doesn't fall under the AMS section title. 
The only thing that
AMS and clamping has in common really are some of the conditions for
them to apply.

(CC Rego and me if you file a spec issue, otherwise one of us surely
will ;-) )

 > 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.

Interesting point.  I hadn't even considered this part of the spec.

 > 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.

I think the spec currently disambiguate that order by saying in
https://drafts.csswg.org/css-grid/#algo-content and
"In all cases, if a track’s growth limit is now less than its base size,
increase the growth limit to match the base size."
because at that point the clamping has already occurred. (I read the above
text as the implementation of the "If max < min, ..." rule.)

(also, please note that your earlier answers said that clamping doesn't
just affect AMS, so by writing "to prevent the automatic minimum size"
here you contradict yourself)

 > 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 suspect I don't understand what you're suggesting.  I think the result
of that would be the same as not clamping anything at all ever[1], which
is probably not what you had in mind.  Could you elaborate with an example
that would clamp with the suggested change?

Thanks again,

Because "for auto minimums" the track base size is the *maximum*
of the items' sizes.
So if we widen the track size to the unclamped item size, and it becomes
larger than the max-sizing function, then we shouldn't clamp it (as you
suggest).  And if the unclamped item size is smaller than the max then
it pointless to clamp it since it's already smaller.  So I don't see any
cases where clamping would have an effect.
Received on Monday, 26 March 2018 19:47:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:35:51 UTC