[css-grid] Implied Minimum Size of Grid Items #283

Closed
mrego opened this Issue Jul 7, 2016 · 41 comments

Projects

Needs Discussion in css-grid-1

7 participants

@mrego
Contributor
mrego commented Jul 7, 2016 edited

As we're approaching the CR stage I was checking again the "Implied Minimum Size of Grid Items" section of the spec.

It's kind of weird that the spec points now again to the text in Flexbox. It was like that originally then it had its own Grid text and now it points again to Flexbox. The problem I found with this is that I'm not 100% sure about some stuff, e.g. the Flexbox spec talks about main-axis, I'm assuming it applies in both axis on grid items. Also when I try to compare with Flexbox, I usually forget about flex-shrink: 1; which is the default in Flebox and creates different results that what I see on Grid.

After trying to understand it properly I was reviewing the W3C tests I created some time ago and updated them. It'd be really nice if someone could verify that my tests are right as some fail on Chromium and another on Firefox.

Please @fantasai and/or @tabatkins could you review the tests (they're just 9 simple tests where the expected result is just a 100x100 green box). Probably @MatsPalmgren would be interested in taking a look too.

Test Chromium Firefox
css-grid-1/grid-items/grid-minimum-size-grid-items-001.xht 👍
css-grid-1/grid-items/grid-minimum-size-grid-items-002.xht 👍
css-grid-1/grid-items/grid-minimum-size-grid-items-003.xht 👍 👍
css-grid-1/grid-items/grid-minimum-size-grid-items-004.xht 👍 👍
css-grid-1/grid-items/grid-minimum-size-grid-items-005.xht 👍
css-grid-1/grid-items/grid-minimum-size-grid-items-006.xht
css-grid-1/grid-items/grid-minimum-size-grid-items-007.xht 👍
css-grid-1/grid-items/grid-minimum-size-grid-items-008.xht 👍 👍
css-grid-1/grid-items/grid-minimum-size-grid-items-009.xht

The status on Chormium and Firefox right now is not really important, as I'm not 100% sure if the tests are right. Thanks! 😉

@fantasai fantasai added Agenda+ and removed ready labels Jul 13, 2016
@fantasai
Contributor

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?

@mrego
Contributor
mrego commented Jul 14, 2016

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

@fantasai
Contributor

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.

@fantasai
Contributor

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.

@mrego
Contributor
mrego commented Jul 18, 2016

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.

min-size: auto applying in 1 (flexbox) or both axis (grid)

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)?

@fantasai
Contributor

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

@fantasai
Contributor

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

@mrego
Contributor
mrego commented Jul 18, 2016

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.

@fantasai
Contributor
fantasai commented Jul 18, 2016 edited

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

@tabatkins
Member

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

@fantasai
Contributor

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

@mrego
Contributor
mrego commented Jul 19, 2016

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.

@astearns astearns removed the Agenda+ label Jul 26, 2016
@fantasai
Contributor
fantasai commented Aug 9, 2016

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.

@fantasai
Contributor
fantasai commented Aug 9, 2016

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

@fantasai
Contributor
fantasai commented Aug 9, 2016

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

@fantasai
Contributor

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.

@mrego
Contributor
mrego commented Sep 8, 2016

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:
Expected output for previous example: a 20x20 magenta block with a black border

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:
Expected output with align|justify-items: a magenta block filling the whole text (bigger than 20x20)

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?

@fantasai
Contributor

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

@mrego
Contributor
mrego commented Sep 16, 2016

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:
screenshot from 2016-09-16 10-02-20

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

@fantasai
Contributor

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? :)

@cbiesinger

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?

@dstockwell dstockwell pushed a commit to dstockwell/chromium that referenced this issue Oct 7, 2016
@mrego mrego + Commit bot [css-grid] Stretch should grow and shrink items to fit its grid area
After some discussions the CSS WG agreed that stretch should not only
grow items, but also stretch them to fit its grid area.
That way the "min-width|height: auto" is somehow ignored for grid items.
More info at: w3c/csswg-drafts#283

The good part is that this allows us to remove some ugly code we've
in LayoutBox that was only used by Grid Layout.

The tests have been updated according to the new expected behavior.

For images, we'll be stretching on both axis right nos, so the aspect
ratio won't be preserved. The default behavior might change in those
cases, but that should be implemented in a different patch.

BUG=653433

Review-Url: https://codereview.chromium.org/2398043002
Cr-Commit-Position: refs/heads/master@{#423839}
da34024
@mrego
Contributor
mrego commented Oct 10, 2016

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:
Expected result with a fixed track size

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.
Expected result with the current text in the spec

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:
Possible expected result in this situation

What do you think?

@mrego
Contributor
mrego commented Nov 21, 2016

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

@MatsPalmgren

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.

@rachelandrew
Contributor

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.

@mrego
Contributor
mrego commented Nov 23, 2016

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>

Item is stretched to fit in the 40x40 cell

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

Item is not stretched and it overflows the 40x40 cell

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:
Item is not stretched and it overflows the grid container

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.

@fantasai
Contributor

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.

@MatsPalmgren

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.

@MatsPalmgren
MatsPalmgren commented Nov 23, 2016 edited

@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

@MatsPalmgren

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

@fantasai
Contributor

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

@mrego
Contributor
mrego commented Nov 24, 2016

@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?

@mrego
Contributor
mrego commented Nov 24, 2016

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?

@mrego
Contributor
mrego commented Nov 24, 2016

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:
40x40 item

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.

Bigger item

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

@fantasai
Contributor
fantasai commented Nov 25, 2016 edited

“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).”

Note the use of “max” here. It means that the auto keyword and minmax(foo,auto) are treated the same in the application of this sentence. I think doing otherwise would be confusing. Authors can always set the min-width of the item itself to zero if that's what they want.

@MatsPalmgren
MatsPalmgren commented Nov 27, 2016 edited

I do think that the stretching effectively overrides the automatic minimum.

OK, fair enough -- I think you are saying that it's desirable if it does that.

However, I think your statement is a bit too general - it's only the min-content size part of the automatic minimum size it should override. If we should shrink below a "transferred size" can be discussed, but let's resolve that bit in #767
(The "specified size" part of automatic minimum size never applies together with stretching because stretching doesn't occur when there is a definite specified size.)

So, here's what I propose to resolve this issue:

Firefox changes its stretching to shrink items below their min-content size.
Chrome implements Grid §6.6 clamping (https://bugs.chromium.org/p/chromium/issues/detail?id=666940)

Then I think we would have identical layout for these tests.

I think that requires minimal spec changes: no Grid spec changes at all. A minor amendment to CSS Align to say that stretching may shrink the alignment subject so that its content size is below its min-content size (still not below any non-auto min-width/height of course).

How does that sound?

@fantasai
Contributor
fantasai commented Nov 27, 2016 edited

I think my statement was indeed too general, and is only correct in the case of an auto-sized or fixed-size track. It's not true in flex-sized tracks, or those with a minmax() function and insufficient grid container space to reach the max.

I don't think we should have stretching override the minimum specified by min-width or min-height, as it never does that. That should remain true whether min-width is set to a fixed size, a keyword like min-content, or auto: the specified minimum is always honored. We can modify what auto means to the extent that it improves outcomes, but stretch shouldn't be special in its ability to override the minimum.

Currently the spec modifies the automatic minimum to accommodate fixed track sizes. It does this by reducing the automatic minimum size--regardless of the item's sizing or alignment properties--to fit within the fixed limits of the grid area. It might be nice to do this for e.g. flex tracks as well, but I fear this will complicate the sizing algorithm, as the result of flexing already depends on content sizes. I'm open to suggestions on how to make the automatic minimum as helpful and unsurprising as possible, but I also don't want to come up with some weird loopback algorithm in our attempt to do so!

@mrego
Contributor
mrego commented Nov 29, 2016

Note the use of “max” here. It means that the auto keyword and minmax(foo,auto) are treated the same in the application of this sentence. I think doing otherwise would be confusing. Authors can always set the min-width of the item itself to zero if that's what they want.

Yes sorry I was thinking about the track sizes on that moment. I was mixing things. :-(

Coming back to the 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>

A) With minmax(0px, 500px) the item should be 40px (minimum size is clamped) and the track 40px too.
B) With minmax(0px, auto) (where auto is for example 250px) the item should be 250px but the track should be 40px.
C) With auto both the item and the track should be 250px.

@fantasai
Contributor
fantasai commented Dec 20, 2016 edited

Ok, so Tab and I reviewed this issue and decided to re-evaluate from first principles.

Goals:

  1. Prevent images/small items from shrinking to nothing in the presence of longer content (e.g. paragraphs). This is the original goal of automatic minimum sizes in Flexbox (and now Grid).
  2. Clamp the implied minimum so that we don't overflow the track due to the minimum: the goal is really to influence auto tracks, because overlapping content is worse than overflowing content. (Also this is how flex lines behave.)
  3. Avoid cyclic dependencies.

Notes on premises:

  • Potential for cyclic dependency only exists if min track size is auto, because otherwise the automatic minimum has no influence on the track size.

Proposed changes:

  1. Clarify that the fixed track size clamping is based on the max track size, not on the final size of the track. (As far as we can tell this was our original intention, just not clearly communicated in the latest spec text.)
  2. Specify that min-width: auto only resolves to the automatic minimum size if the item spans at least one track whose min track size is auto. It is otherwise zero.

Notes on proposal:

  • Flex tracks in general will honor the automatic minimum because flex sizes outside a minmax() function imply an auto min track size.
  • If the author specified an explicit minimum track size, we always honor that, and if the track is too small for its content, a stretched item shrinks to match and its content overflows.
  • The item sizes in rego's latest example would therefore be a) 40px b) 40x c) 250px.

Let us know if that seems to make sense. Thanks~

@fantasai fantasai added the Agenda+ label Dec 20, 2016
@fantasai fantasai added Agenda+ F2F and removed Agenda+ labels Jan 4, 2017
@mrego
Contributor
mrego commented Jan 10, 2017

It makes sense to me and it seems it matches current Chromium behavior.

I guess that the track sizes for the example are also A) 40px, B) 40px and C) 250px.

And if we add one more case to the example:
D) With minmax(auto, 0px) or minmax(auto, 500px) (it doesn't matter the number of pixels we set as maximum) the size of the item and the track will be 250px too.

@astearns astearns removed the Agenda+ F2F label Jan 11, 2017
@mrego mrego referenced this issue in w3c/csswg-test Jan 31, 2017
Merged

[css-grid] Update Grid Layout test suite #1194

@MXEBot MXEBot pushed a commit to mirror/chromium that referenced this issue Feb 2, 2017
@mrego mrego + Commit bot [css-grid] Import W3C Test Suite
This patch imports the CSS Grid Layout test suite from csswg-test repository.

Currently we're passing most of the but:
* grid-layout-properties.html: An old known bug (crbug.com/511177).
* grid-support-grid-template-areas-001.xht &
  grid-inline-support-grid-template-areas-001.xht: Because of an issue
  with testharness.js (crbug.com/687492).

Additionally I'm skipping the tests related to "Implied Minimum Size
of Grid Items" (https://drafts.csswg.org/css-grid/#min-size-auto),
because the test suite needs to be updated after the CSS WG resolves
the following issue: w3c/csswg-drafts#283
See crbug.com/666940 for more details.

BUG=687494

Review-Url: https://codereview.chromium.org/2670473003
Cr-Commit-Position: refs/heads/master@{#447562}
91d2f36
@tabatkins tabatkins added a commit that closed this issue Feb 2, 2017
@tabatkins tabatkins Fixes #283 - edit in the second part of the proposal, that auto-min-s…
…ize only kicks in if you span an auto track.
7445032
@tabatkins tabatkins closed this in 7445032 Feb 2, 2017
@mrego mrego added a commit to mrego/csswg-test that referenced this issue Feb 14, 2017
@mrego mrego [css-grid] Update implied minimum size of grid items tests
Once that issue w3c/csswg-drafts#283 has been solved, this patch
is updating the current tests related to "Implied Minimum Size
of Grid Items" section:
https://drafts.csswg.org/css-grid/#min-size-auto
9ec6c7a
@mrego mrego added a commit to mrego/csswg-test that referenced this issue Feb 14, 2017
@mrego mrego [css-grid] Add more tests for Implied Minimum Size of Grid Items section
This adds more coverage for that spec section:
https://drafts.csswg.org/css-grid/#min-size-auto

The examples in the tests were discussed in w3c/csswg-drafts#283.
283588f
@mrego
Contributor
mrego commented Feb 15, 2017

Thanks for resolving this issue, we've been working on adding tests for this feature to the csswg-test repository (18 tests total):

It'd be nice if you could take a look to them and verify that they're right or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment