W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2017

Re: [csswg-drafts] [css-sizing][css-grid][css-flexbox] Intrinsic Sizes, Scroll Containers, and Grid/Flex Sizing

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 08 Nov 2017 01:51:57 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-342684092-1510105916-sysbot+gh@w3.org>
The Working Group just discussed `Intrinsic sizing and containers for grid/flex sizing`.

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen> Topic: Intrinsic sizing and containers for grid/flex sizing<br>
&lt;Rossen> github: https://github.com/w3c/csswg-drafts/issues/1865<br>
&lt;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<br>
&lt;TabAtkins> fantasai: Don't know how to fix it, because it's a deep descendant<br>
&lt;TabAtkins> fantasai: We opened an issue to find better ways here<br>
&lt;TabAtkins> fantasai: Proposal is that grid/flex items that have non-visible overflow ignore their content for the purpose of calculating min-content contribution<br>
&lt;TabAtkins> fantasai: In both axises<br>
&lt;TabAtkins> fantasai: And block boxes do the same thing in the inline axis<br>
&lt;TabAtkins> fantasai: Excluding the block axis because it's awkward and idfficult to compute<br>
&lt;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.<br>
&lt;TabAtkins> fantasai: For authors that want the min-content size to handle the sizing, they can explicitly use "min-height: min-content"<br>
&lt;TabAtkins> fantasai: I think this will give more intuitive behavior; people wont' be as confused when their items get much wider than expected<br>
&lt;TabAtkins> fantasai: And for hte people who do need to have this old behavior, they can just use min-content keyword<br>
&lt;TabAtkins> TabAtkins: I'm confused - I thought this was about *descendants* of flex/grid items<br>
&lt;TabAtkins> fantasai: Right, but those descendants might be flex/grids again<br>
&lt;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<br>
&lt;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.<br>
&lt;fantasai> s/auto-size/auto-size and scroller/<br>
&lt;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.<br>
&lt;fantasai> (and if you don't want to, you can set min-width: min-content)<br>
&lt;TabAtkins> dbaron: Trying to see how specific it is to grid/flex<br>
&lt;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<br>
&lt;TabAtkins> dbaron: I suspect we can't change the float/table behavior, we're probably stuck with this.<br>
&lt;TabAtkins> TabAtkins: So just min-width/height:auto, then<br>
&lt;TabAtkins> gregwhitworth: We resolved about something similar on tables yesterday<br>
&lt;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.<br>
&lt;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.<br>
&lt;TabAtkins> fantasai: Usually when you ask for overflow, your size is dictated by something else, such that you might have overflow.<br>
&lt;TabAtkins> TabAtkins: I think this needs more thought and compat analysis before I"m comfortable with this.<br>
&lt;TabAtkins> fantasai: Should be able to do it for flexbox and grid, at least, which would solve a lot.<br>
&lt;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.<br>
&lt;TabAtkins> fantasai: So I think it's safe to say your min-content contribution is also 0.<br>
&lt;TabAtkins> TabAtkins: I'd still want some thinking time about this, even for the limited case.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1865#issuecomment-342684092 using your GitHub account
Received on Wednesday, 8 November 2017 01:52:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 November 2017 01:52:02 UTC