Repository navigation
[css-sizing][css-grid][css-flexbox] Intrinsic Sizes, Scroll Containers, and Grid/Flex Sizing #1865
Description
Grid Layout and Flex Layout use automatic minimum sizes (min-content, by default, but depending on the specified min-width/min-height) to prevent grid items and flex items from shrinking too small to be usable. There's an exception to the use of min-content for grid/flex items which have overflow set on them, since authors expect those to shrink below their min-content size. But this exception doesn't follow through to descendants of the grid/flex item, resulting in confusion and frustration for authors. Issue #1777 was filed as a result of such confusion, and Dave Rupert posted http://daverupert.com/2017/09/breaking-the-grid/ discussing the problem.
This issue is filed to look into ways to ameliorate the problem: if we can make things Just Work as authors expect, that would be better! Of course Flex and Grid should be affected analogously, thus tagging them both in.
Activity
fantasai commentedon Oct 12, 2017
Fwiw, #765 will likely solve the problems with replaced elements in Dave Rupert's post. (Authors will need to use
max-width: 100%to get the right behavior, but this doesn't seem unreasonable.)Solving scrollable
<pre>/<table>/whatever inside the grid item is harder, it would require redefining the min-content size of such items; and afaict that would only help in the inline axis.[-][css-sizing][css-grid][css-flexbox] Intrinsic Sizes and Scroll Containers[/-][+][css-sizing][css-grid][css-flexbox] Intrinsic Sizes, Scroll Containers, and Grid/Flex Sizing[/+]fantasai commentedon Nov 6, 2017
Discussed this with biesi on Saturday... current idea is to solve this in the inline axis for blocks and in both axes for flex and grid items by assuming a min-content size of zero for
overflow!=visible.css-meeting-bot commentedon Nov 6, 2017
The Working Group just discussed
intrinsic size of 'overflow: auto/scroll' and its impact on auto-sized grid/flex item ancestors.The full IRC log of that discussion
<gregwhitworth> Topic: intrinsic size of 'overflow: auto/scroll' and its impact on auto-sized grid/flex item ancestors<astearns> github: https://github.com//issues/1865
<gregwhitworth> fantasai: grid and flexbox show this issue, where people have an element with a scrollbar and they put it among a whole bunch of other content
<gregwhitworth> fantasai: it forces that has a min-content size which defeats the purpose of the scrolling the author defined
<gregwhitworth> fantasai: this leads to a lot of confusion for authors
<gregwhitworth> fantasai: they're already handling their overflow and it would be nice if they just worked
<gregwhitworth> fantasai: this was filed that would allow us to come up with a way for this to work
<dbaron> q+
<gregwhitworth> fantasai: I was talking with cbiesinger on Saturday to try and have the min-content zero'd out
<gregwhitworth> fantasai: the min-content contribution which has overflow be 0, but not the logical height depending on its overflow. If you did this you'd have to relayout in flow content to determine it's min and max
<fremy> q+
<gregwhitworth> fantasai: it's an idea, we're looking for other ideas
<dbaron> q-
<gregwhitworth> dbaron: The thing with overflow that is not visible the size is the content within it, it has to propagate through it if it's the only thing
<gregwhitworth> dbaron: I tend to think, that there is not going to be a thing that we can do to solve this with a property that allows them to choose the thing that they want
<gregwhitworth> dbaron: I think there are two different scopes
<cbiesinger> q+
<Rossen> q?
<gregwhitworth> 1. intrinsic control intrinsic width that has overflow
<gregwhitworth> 2. properties that allow assignment to the intrinsic widths
<gregwhitworth> dbaron: the advantage of the first one is it gives more room for auto behaviors that do the right thing
<gregwhitworth> dbaron: the advantage of the second is it is strictly more powerful
<fantasai> q+
<Rossen> q?
<Rossen> ack fremy
<gregwhitworth> fremy: I wanted to note that we had a similar issue in the table spec
<gregwhitworth> fremy: if you have a % height and you're overflowing in a non visible way we should resolve to 0
<gregwhitworth> fremy: the author intent is pretty clear here
<gregwhitworth> fremy: to me this makes sense and is generalized
<Rossen> q?
<gregwhitworth> fantasai: for grid and flex items specifically the automatic minimum size is not triggered on items that are not with overflow that is not visible but it does impact content contribution
<gregwhitworth> cbiesinger: you said that the single items need the content contribution to propagate through
<gregwhitworth> dbaron: because people will use it to hide things rather than scroll it
<gregwhitworth> fantasai: that's a good point
<fantasai> s/use it/use 'overflow: hidden'/
<gregwhitworth> dbaron: you're talking about zering out the min-content sizes
<gregwhitworth> fantasai: yeah, just the min-content size
<smfr> s/zering/zeroing/
<Rossen> q?
<Rossen> ack cbiesinger
<gregwhitworth> dbaron: presumably the min-content sizes don't matter
<gregwhitworth> cbiesinger: for the min size of flex and grid would make it zero in this cases
<gregwhitworth> dbaron: in many cases you want them to get smaller but not to 0
<gregwhitworth> fantasai: a lot of the cases that are here the minimum would be controlled by other content that happens to be there
<gregwhitworth> fantasai: if they don't want it to get to 0 they can set a min size on the flex or grid item
<fantasai> or on the scroller itself
<gregwhitworth> dbaron: the other thing I worry about here is compat
<gregwhitworth> cbiesinger: that is concerning
<gregwhitworth> dholbert: Chrome already does this correct?
<fantasai> This is more understandable than having a scrollable descendant of a grid or flex item several layers deep in a subsection of a subsection cause the flex/grid item's width to explode out
<gregwhitworth> cbiesinger: I don't think we do that, but we do is for column flex we don't give it a min-height
<gregwhitworth> dholbert: I thought there was something there for overflow: scroll
<gregwhitworth> cbiesinger: I'd need to look at it
<cbiesinger> s/column flex/nested column flexboxes/
<fantasai> Proposal in two parts:
<fantasai> 1 flex/grid items with overflow != visible | hidden have min-content contribution of zero
<gregwhitworth> Rossen: I read through the post about this issue, but I'd want more use cases for this. I am not going to object, but there will be compat issues for this
<gregwhitworth> Rossen: dbaron any objections?
<jensimmons> Rossen: can you speak up? You are very quiet. Or move a mike closer to you.
<fantasai> 2 inline dimension of block with ovefow != visible | hidden has mincontent contribution of zero
<gregwhitworth> dbaron: I wouldn't object, but I'd like to discuss the compat implications
<gregwhitworth> Rossen: we can discuss this on the side - let's not rush the resolution
<gregwhitworth> dbaron: I would be hesitant to come up with something too magical
<gregwhitworth> Rossen: unless there is something else to be discussed
fantasai commentedon Nov 7, 2017
To write out the proposal in more detail:
overflowis non-visibleoroveflowisscroll | auto; this is an open issue, sinceoverflow: hiddenis sometimes just used for creating a BFC, at least for blocks.This should address most of the cases where people are confused by the current behavior. Authors who want such box’s min-content size taken into account can use
min-width: min-contentwhich is a relatively straightforward fix for that issue -- the current behavior has effects that cross through descendants which is what's particularly surprising and problematic about it.css-meeting-bot commentedon Nov 8, 2017
The Working Group just discussed
Intrinsic sizing and containers for grid/flex sizing.The full IRC log of that discussion
<Rossen> Topic: Intrinsic sizing and containers for grid/flex sizing<Rossen> github: https://github.com//issues/1865
<TabAtkins> fantasai: We discussed yesteray this problem of, in flex and grid we have implied minimum size, and people put stuff in there with scrollbars, expecting that to handle overflow, but because we'r elooking for min-content size *including* overflow, stuff gets too big and it's awkward
<TabAtkins> fantasai: Don't know how to fix it, because it's a deep descendant
<TabAtkins> fantasai: We opened an issue to find better ways here
<TabAtkins> fantasai: Proposal is that grid/flex items that have non-visible overflow ignore their content for the purpose of calculating min-content contribution
<TabAtkins> fantasai: In both axises
<TabAtkins> fantasai: And block boxes do the same thing in the inline axis
<TabAtkins> fantasai: Excluding the block axis because it's awkward and idfficult to compute
<TabAtkins> fantasai: dbaron brought up the point that you might want to consider overflow:hidden different from scroll, because it's sometimes used just for bfc, nothing to do with clipping. That's probably only relevant for blocks.
<TabAtkins> fantasai: For authors that want the min-content size to handle the sizing, they can explicitly use "min-height: min-content"
<TabAtkins> fantasai: I think this will give more intuitive behavior; people wont' be as confused when their items get much wider than expected
<TabAtkins> fantasai: And for hte people who do need to have this old behavior, they can just use min-content keyword
<TabAtkins> TabAtkins: I'm confused - I thought this was about *descendants* of flex/grid items
<TabAtkins> fantasai: Right, but those descendants might be flex/grids again
<TabAtkins> fantasai: So a block with auto-size in the inline axis, and the flexbox container says "how much space does my content want?" and the block says "THIIIIIIIIIIIS wide" and the flexbox gets huge
<TabAtkins> fantasai: So if the block reports that it's 2ems wide (just padding), the flex container can say "2ems here for this scroll container, 3ems for that word", and then becomes 3ems wide, and the extra stuff will scroll as intended.
<fantasai> s/auto-size/auto-size and scroller/
<TabAtkins> fantasai: So the intrinsic size of a scroll container is dictated by its contents. The fact that it has a scrollbar is irrelevant to its contribution; but in practice, you put a scrollbar on it, you're *okay with* it shrinking, so it should be able to shrink below the min-content size.
<fantasai> (and if you don't want to, you can set min-width: min-content)
<TabAtkins> dbaron: Trying to see how specific it is to grid/flex
<TabAtkins> fantasai: Currently not specific. it would effect a float or table-cell that contains an element with overflow:scroll, *if* that float's size is dictated by the size of the overflow element
<TabAtkins> dbaron: I suspect we can't change the float/table behavior, we're probably stuck with this.
<TabAtkins> TabAtkins: So just min-width/height:auto, then
<TabAtkins> gregwhitworth: We resolved about something similar on tables yesterday
<TabAtkins> fantasai: The cases effected by this proposal would be where author sets overflow:auto/scroll, but nothing ever scrolls because the box is always big enough to fit its contents. This seems weird.
<TabAtkins> fantasai: Where the overflow-controlled box is the one dictating the size of the container, such that it never ends up needing to overflow. Seems kinda odd.
<TabAtkins> fantasai: Usually when you ask for overflow, your size is dictated by something else, such that you might have overflow.
<TabAtkins> TabAtkins: I think this needs more thought and compat analysis before I"m comfortable with this.
<TabAtkins> fantasai: Should be able to do it for flexbox and grid, at least, which would solve a lot.
<TabAtkins> fantasai: Currently we say if you have overflow:non-visible your automatic min-size is zero, but your min-content contribution is not zero.
<TabAtkins> fantasai: So I think it's safe to say your min-content contribution is also 0.
<TabAtkins> TabAtkins: I'd still want some thinking time about this, even for the limited case.
39 remaining items
Bug 1538376 [wpt PR 15989] - Revert "[css-flexbox] Try changing min-c…
Bug 1538376 [wpt PR 15989] - Revert "[css-flexbox] Try changing min-c…
Bug 1534137 [wpt PR 15708] - [css-flexbox] Try changing min-content c…
Bug 1538376 [wpt PR 15989] - Revert "[css-flexbox] Try changing min-c…
Bug 1538376 [wpt PR 15989] - Revert "[css-flexbox] Try changing min-c…
cbiesinger commentedon Nov 20, 2020
Just realized I never followed up here; that change was reverted quickly because it broke too much:
https://crbug.com/944614
https://crbug.com/941975
https://crbug.com/943496
fantasai commentedon Mar 5, 2021
Retargetting for css-sizing-4: since it looks like we can't change the past, looking into adding a switch (similar concept to box-sizing, except it's a more confusing concept...); see #4585
benface commentedon Apr 11, 2025
I believe I stumbled upon this "problem", but I am not entirely sure, so let me know if I should create a new issue (or if there's already a way to achieve what I'm after and I'm simply missing it).
I want to have a row of tabs that are ideally all the same width (think
display: grid; grid-auto-flow: column; grid-auto-columns: 1fr) and a single line of text as their label (white-space: nowrap). If the container is not wide enough to make all the tab labels fit, they should be truncated (overflow: hidden; text-overflow: ellipsis). But I don't want the truncation to happen until there's no more space on the row, meaning that tabs should not be forced to be equal width if it means truncating a tab that has a long label while there's empty space in other tabs/columns, as shown here:If I replace
grid-auto-columns: 1frbygrid-auto-columns: minmax(min-content, 1fr), I get the exact behavior that I want:...except that now, the tabs overflow when there's no empty space left, instead of getting truncated. 🥲
From what I understand, that's caused by the
min-contentinminmax()being inflexible. But thatmin-contentis also what prevents tabs from being truncated when there's still space on the row. Seems like what I'm after would be something likegrid-auto-columns: minmax(fit-content, 1fr), but that's invalid. I also triedgrid-auto-columns: minmax(auto, 1fr), but that seems to behave exactly likegrid-auto-columns: 1fr.I hope I'm wrong and it's possible to achieve that, but if not, then am I at least correct that this use case falls under the current issue?
Here's the Codepen I made for the above. Thank you!
Loirooriol commentedon Apr 11, 2025
Your problem sounds more like #4147 or something.
benface commentedon Apr 12, 2025
Hmm, maybe, but I think it's worth creating a separate issue then. I've done it here: #12071. Thanks @Loirooriol!
Bug 1534137 [wpt PR 15708] - [css-flexbox] Try changing min-content c…
Bug 1538376 [wpt PR 15989] - Revert "[css-flexbox] Try changing min-c…