So... as I was editing this to clarify that it applies to both axes (as you mention), I realized that the reason it applies to one axis and not the other in Flexbox is because of the flexibility of the items. I'm wondering if that's something we need to take into account here?

I don't know what's the goal in Grid Layout, but it's supposed that both directions on the grid are symmetric (at least in most situations if not all).
However it's true that Flexbox only do that in one axis (quick example comparing flexbox and grid).

I think one of the goals is "do the most expected thing, given Flexbox and author expectations", and of course "be symmetric across axes". The min-width/height: auto behavior was added in part for handling auto-minimum-sized tracks--to make their content-based minimum more configurable. We could, as an alternative to having it always apply, only apply the automatic minimum on items in such tracks.

Thinking about this some more, at the very least, the grid's maximum track-sizing function should clamp the implied minimum the same way a specified size on the item would. I'm pretty sure that's what authors would expect.

About author expectations I don't really know what they would be expecting in this situation. Just to make it clear, I'm attaching an example of a 20px x 20px Flexbox and Grid to show the difference between both. Flexbox applies min-size: auto; only in 1 axis and Grid where it applies in both axis.

About your comment:

The min-width/height: auto behavior was added in part for handling auto-minimum-sized tracks--to make their content-based minimum more configurable.

I'm not sure if I'm getting it or not. Do you mean that when you use min-content for a track size, it doesn't use the min-size but it uses the content; and if you use auto for the track size, it checks the min-size and uses it (and when min-size is auto the behavior is equivalent to min-content)?

Yes, that's exactly what I meant. That is the reason we changed 'auto' to be something distinct from minmax(min-content, max-content).

Proposed wording (append to first paragraph of Implied Minimum Size of Grid Items):

If the grid item is placed in a grid track with a fixed maximum sizing function
(and does not otherwise span a track with a non-fixed maximum sizing function),
its automatic minimum size in that dimension
is further clamped to less than or equal to the size necessary
to fit its margin box within the track (flooring at zero).

Thinking about this some more, at the very least, the grid's maximum track-sizing function should clamp the implied minimum the same way a specified size on the item would. I'm pretty sure that's what authors would expect.

I always thought that the idea of min-size: auto was to avoid shrink-to-fit by default.
At least in Flexbox it avoids that the item shrink-to-fit in the flex container, when the flex container has a fixed width (like in the previous example). Maybe there were other reasons to add it in Flexbox that I'm missing.
Are we sure we want something different in Grid Layout? So the items will shrink-to-fit in their grid area.

Hm, I think “shrink-to-fit” as it's traditionally used is not what you meant. :) But yes, the purpose of min-size: auto was to prevent flex items from shrinking below their min-content size when flexing into a small flex container. We are preserving this behavior for flexible things, i.e. those with a flexible max-track-size.

The track sizing functions are at a sort of intermediary phase between the grid container and the grid item; the flex layout analogy would be flex lines, which don't have any sizing associated with them. Explicitly specifying a fixed size on the tracks is in some way similar to specifying that size on the grid container and in some ways similar to specifying that size on the grid item. But for the purpose of safety -- the reason we have min-size: auto -- it is more similar to specifying that size on the grid item. Because in flex container, we invoke this safety when you have multiple items that, added up up, may or may not overflow the container. But in grid layout, you are fairly sure to target just the one item (in that axis): the author is not going to get any unexpected stacking effects.

(I don't know if that made much sense as an explanation. I'll try again if it didn't.)

In

If the grid item is placed in a grid track with a fixed maximum sizing function
(and does not otherwise span a track with a non-fixed maximum sizing function),
its automatic minimum size in that dimension
is further clamped to less than or equal to the size necessary
to fit its margin box within the track (flooring at zero).

I think the first part is a little awkward. Maybe

If the grid item spans only tracks with fixed maximum sizing functions in a given axis,
...

However, if the grid item spans only grid tracks
that have a fixed maximum sizing function,
its automatic minimum size in that dimension
is further clamped to less than or equal to the size necessary
to fit its margin box within the track (flooring at zero).

Mmmm, I'm still not convinced about this. Probably, we should ask for authors feedback on the topic.

Note that the example when you have a fixed track size was discussed before on www-style (Nov 2014) and the implementations got updated accordingly.

I... am having a hard time following that thread. There seems to be vast amounts of confusion over z-index, some additional arguments over TR vs ED, and then some discussion about stretch with the key text

Ah, yes, indeed. 'stretch' will not shrink it below its 'auto' width.
The 10px column merely provides the containing block width, and layout then ends up making it min-content.
(That is, min-content doesn't come automatically; it's just that the rendering which falls out should be the same as if you'd explicitly requesting min-content width.)

The first statement is true: whatever width auto decides, stretch can only increase it. But we are here discussing auto for min-width, which is not the same as auto for width.

The second clause “The 10px column merely provides the containing block width” is also true.

Then we have “and layout then ends up making it min-content” ... at that point the spec put min-content minimums on all auto-sized tracks, but this track is not auto-sized. And there was no implied minimum size on items themselves; min-width: auto still computed to zero. (Auto minimums were added to Grid in https://lists.w3.org/Archives/Public/www-style/2015Jan/0166.html which was January 2015.) So I am not sure where this assertion is coming from.

Agree it would be good to have author feedback; my feeling though is that fixed track sizes are thought of similarly to fixed sizes on the item itself, and it's good for the automatic minimum to not overrule that. (Auto minimums are supposed to be minimally invasive. ;)

The interesting question then becomes, what does auto mean for width/height themselves on a grid item? It Doesn't appear that this is defined. The only definition I'm seeing is https://drafts.csswg.org/css-align/#justify-self-property which only defines it for stretch.

Nevermind, found it in https://www.w3.org/TR/css-grid-1/#grid-items That section needs more subheadings, I think. >_<

Filed #394 on sizing grid items. There's still some spec issues there afaict.

Ok, I went over this issue with the Microsoft folks, and my conclusion is that we need to make sure grid items are sized the same (in both axes) as flex items are in the cross axis. See #394 for further discussion.

Concretely, this means applying the CSS2.1 non-replaced block width formula to items when they are stretched, and fit-content sizing for other alignment values, and it means that the implied minimum can't take effect on fixed tracks. Note that on auto-sized tracks, whether the implied minimum is used solely for track sizing or also for sizing the item itself is indistinguishable.

Additionally, the major consideration for adding implied minimum sizes to the main axis of flex items was for the viewer's benefit when the screen was made too small. Flex items do not shrink past their minimum main size--but importantly, they also do not overlap each other within a line, because their positions are determined by previous content, not by the position/size of their container (the line). Grid items, if they were floored at their content-size, do not shift in such a manner, and they would overlap each other within the row/column. Forcing a minimum on the item doesn't really help the user so much in this case.

Let's see if I'm understanding the last comment. 😄

Coming back to one of the examples discussed, a grid with a fixed track of 20x20:

  <div style="display: grid; grid: 20px / 20px; width: 20px; height: 20px; border: thick solid; font: 50px/1 Monospace;">
    <div style="background: magenta;">item</div>
  </div>

It seems to me that the behavior we're looking for is that the item is sized to 20x20, and the rest of the text overflows. So it could be something like in the following picture:

And that's the default behavior as align|justify-items is stretch by default.

However, if align|justify-items is start the expected behavior would be like the next picture:

If I'm getting it right then we might need to update the spec in a few places:

• 6.2. Grid Item Sizing

  Note: The auto value of min-width and min-height affects track sizing
  in the relevant axis similar to the flexbox behavior on flex items in the main axis.

  Shouldn't say in the "cross axis"?

• 6.6. Implied Minimum Size of Grid Items

  (The effect is analogous to the automatic minimum size imposed on flex items in their main axis.)

  Again "cross axis"?

  However, if the grid item spans only grid tracks that have a fixed max track sizing function,
  its automatic minimum size in that dimension is further clamped to less than or equal to
  the size necessary to fit its margin box within the resulting grid area (flooring at zero).

  Does this apply in both stretch and start case?

It seems to me that the behavior we're looking for is that the item is sized to 20x20, and the rest of the text overflows.
And that's the default behavior as align|justify-items is stretch by default.
However, if align|justify-items is start the expected behavior would be like the next picture

Yes, exactly.

Shouldn't say in the "cross axis"?

The implied minimum doesn't take effect in the cross axis at all for flex items. This is because flex lines are always auto-sized anyway. (Except for single-line flex containers... but in that case the items would overflow the flex container in more or less the same way.)

Does this apply in both stretch and start case?

Definitely applies for stretch. For the start case, afaict it makes no difference. Let me know if that assumption is incorrect. :)

The implied minimum doesn't take effect in the cross axis at all for flex items. This is because flex lines are always auto-sized anyway. (Except for single-line flex containers... but in that case the items would overflow the flex container in more or less the same way.)

Mmmm, but in a previous comment #283 (comment) you said:

my conclusion is that we need to make sure grid items are sized the same (in both axes) as flex items are in the cross axis

So using a flexbox as example:

  <div style="display: flex; width: 20px; height: 20px; border: thick solid; font: 50px/1 Monospace;">
    <div style="background: magenta;">item</div>
  </div>

The output is the following:

• In the main axis (width), the "min-width: auto" applies, so the size of the item is bigger than the 20px of the flex container.
• In the cross axis (height), the implied minimum size doesn't have any effect, so the height of the item is reduced to 20px.

In the previous comment you confimred that the behavior for grids in the similar example should be a 20x20 item. That's why I was understanding it was behaving the same than in the cross axis of flexboxes.

Also note than if in the flexbox we use align-items: flex-start;, the height of the item will be bigger than the 20px. Again behaving exactly the same than the expected behavior we've just discussed for grid.

So probably I'm missing something but I'm not understanding the whole thing yet, sorry. 😔

OK, here's the current state of the text:

To provide a more reasonable default minimum size for grid items, this specification defines that the auto value of min-width/min-height also applies an automatic minimum size in the specified axis to grid items whose overflow is visible. (The effect is analogous to the automatic minimum size imposed on flex items in their main axis.) [CSS-FLEXBOX-1] However, if the grid item spans only grid tracks that have a fixed max track sizing function, its automatic minimum size in that dimension is further clamped to less than or equal to the size necessary to fit its margin box within the resulting grid area (flooring at zero).

Let me know if this is clear, or if there's something confusing, what's confusing? :)

Forcing a minimum on the item doesn't really help the user so much in this case

@fantasai -- So, what are the use cases where implied minimums do help the user? If you have fixed tracks, per the current spec the min size is ~ignored. If you have auto-sized tracks, the items are already content sized. Does grid need an implied minimum size?

So the new text on the spec says:

if the grid item spans only grid tracks that have a fixed max track sizing function

I'm wondering if that's really what we want or not.

Let's come back to the simple example and see what we want

  <div style="display: grid; grid: 20px / 20px; width: 40px; height: 40px; border: thick solid; font: 100px/1 Monospace;">
    <div style="background: magenta;">item</div>
  </div>

In this case the expected result would be an item of 20x20 pixels:

Then if we change it and we use grid: minmax(20px, auto) / minmax(20px, auto);. According to the text on the spec, as the max track sizing function is not fixed, we shouldn't clamp the minimum size.
So the expected behavior would be a item bigger than the size of the track and the grid container.
The tracks in this case will be both 40px. However the item will be bigger and will be overflowing its grid area.

However, it seems to me that in this case it'd be also nice if we clamp the size of the item to 40x40. So the result would be something like this:

What do you think?

It seems we should clarify this issue ASAP.

CSS Grid Layout is going to be shipped in both Firefox and Chromium and we've different implementations for this: https://bugs.chromium.org/p/chromium/issues/detail?id=666940

I definitely don't think we should make the grid container's width/height
affect the clamping as was suggested above. The containing block (CB) for
a grid item is its grid area. I think we should keep it that way for simplicity.
The motivating example seems like an edge case anyway (a single grid area
that coincides with the container's content-box). I suspect that the suggested
clamping would make less sense in a more realistic grid with multiple tracks.

As an author I don't have a strong preference on this, other than I'd like everyone to do the same thing. Thinking it through I would lean slightly towards what Mats is saying, it seems clearer that the grid area is what affects the clamping, rather than the container.

Just to wrap-up, as this issue has a lot of comments, I believe we have to agree on 2 things here:

1) The different behavior between normal|stretch and any other alignment value (e.g. start):

• stretch:

  <div style="display: inline-grid; grid: 40px / 40px; border: thick solid; font: 100px/1 Monospace;">
    <div style="background: magenta;">item</div>
  </div>

• start:

  <div style="display: inline-grid; grid: 40px / 40px; border: thick solid; font: 100px/1 Monospace;">
    <div style="background: magenta; justify-self: start; align-self: start;">item</div>
  </div>

Right now Chromium has a different behavior for stretch vs start (which is similar to what happens on Flexbox) but Firefox doesn't.

2) If we should clamp the size for tracks with intrinsic max sizing function:

Example:

  <div style="display: inline-grid; width: 40px; height: 40px; grid: minmax(0px, auto) / minmax(0px, auto); border: thick solid; font: 100px/1 Monospace;">
    <div style="background: magenta;">item</div>
  </div>

After thinking about this for a while, I agree with @MatsPalmgren and @rachelandrew, that the grid area should be the one affecting the clamping, so in this case the item will overflow the grid container. So the expected result would be:

Right now Firefox does it and Chromium doesn't.

The same that would happen if you use grid: auto / auto, in this case both browsers behave the same way. Which leans me towards thinking this is a Chromium bug.

Other

Then once we got an agreement about the expected behavior I believe the text on the spec still needs some tweaks and clarifications. We need to be more explicit about this to avoid confusions in the future.

And hopefully we should be able to add examples on the spec about this too.

I agree with the conclusions in this thread, and they seem to reflect my understanding of how Grid should work. If it's not clear in the spec, I will clarify it.

I don't think it's appropriate to compare Grid layout with Flexbox
layout in these cases. Flexbox applies the 'automatic minimum size'
only in the main axis, and applies stretching only in the cross-axis,
so they never coincide, unlike for the Grid examples discussed here.
So let's not compare with Flexbox layout here, it will just confuse
the matter further.

@mrego , I think you're conflating two separate concepts -
clamping and stretching.
The first one is the clamping of the 'automatic minimum size' to
the grid area size, as specified in:
https://www.w3.org/TR/css-grid-1/#min-size-auto

... its automatic minimum size in that dimension is further clamped
to less than or equal to the size necessary to fit its margin box
within the resulting grid area (flooring at zero).

This applies universally, not just when stretching the items.
We have implemented this in Firefox and I think it works well.
(I think this is just a bug in Chrome that you should fix:
https://bugs.chromium.org/p/chromium/issues/detail?id=666940 )

The second issue is about whether stretch/normal items should
shrink below their min-content size in general if they don't fit within their
grid area. I believe the CSS Align spec says that they shouldn't:
https://drafts.csswg.org/css-align-3/#valdef-justify-self-stretch

... make its outer size as close to filling the alignment container
as possible while still respecting the constraints imposed by
min-height/min-width/max-height/max-width.

(of course, the grid area clamping rule trumps this when it applies)

I believe the "Implied Minimum Size" in Grid is a "constraint imposed by
min-width/height", it just so happens that Grid items have a min-size for
min-width/height:auto.

So, I believe the rendering in Firefox for these examples are correct
per the CSS Grid and Alignment specs.

Regarding the clamping rule in CSS Grid:
I am strongly opposed to any normative change to Grid Level 1 at this point.
The Grid spec is in CR and we have already sent our intent-to-ship.
Also, this rule makes sense and works well IMHO.

Regarding the definition of stretch in CSS Align:
I'm willing to discuss tweaking that if you want, i.e. amending
that spec to say that the min-content size should be ignored
when stretching (shrinking), or something. We should check
carefully if that works for Block/Table/Multicol too before
making changes though. (I don't think it affects Flexbox per my
last comment.)

CC @jetvillegas

Here's a better testcase that illustrates the different clamping/stretching cases:
https://people-mozilla.org/~mpalmgren/tests/grid/issue-283.html
and how it renders in Firefox / Chrome respectively:
https://people-mozilla.org/~mpalmgren/tests/grid/issue-283-firefox.png
https://people-mozilla.org/~mpalmgren/tests/grid/issue-283-chrome.png

To follow up on what Mats is saying (though I'm not 100% sure if the concepts are all connected up correctly), I do think that the stretching effectively overrides the automatic minimum. If the track is auto-sized, then stretching would not decrease below the automatic minimum. If the track is not auto-sized, then the automatic minimum is clamped to the size of the grid area; and that clamping should be limiting any transferred size affecting the other axis as well.

Let me know if that made sense or if I should try logicking again when it's not 3am. :)

@MatsPalmgren I'm sorry but I don't understand the results from Firefox on the 2) case in your example, why one axis is different than the other?

Regarding the difference between stretch vs start, there's already some text in the spec

However, the box alignment properties have special effects: when align-self/justify-self is neither normal nor stretch, an auto size for the grid item in that axis is treated as fit-content instead of as the fill-available size.

@fantasai what do you think should be the expected behavior for 1) in my previous comment?

And now thinking again about 2) from my previous comment.

  <div style="display: inline-grid; width: 40px; height: 40px; grid: minmax(0px, auto) / minmax(0px, auto); border: thick solid; font: 100px/1 Monospace;">
    <div style="background: magenta;">item</div>
  </div>

A) If instead of minmax(0px, auto) we use minmax(0px, 500px), both browsers agree that the item should be 40x40:

B) So, if we use minmax(0px, auto) and auto is bigger than 40px (let's say 250px), I believe we should still behave the same and the item should still be 40x40.

C) However if the track is only auto, then is when the minimum size plays its role and causes it to be bigger (250px) and overflow the grid container.

This is related to the step of the alogrithm in which we maximize the track sizes, as the free space would be only the 40px of the grid container.

Note that in these examples Firefox and Chromium have the same behavior for A) and C) but not for B).