- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Tue, 28 Nov 2017 19:13:00 +0000
- To: public-css-archive@w3.org
Proposal in two parts: 1. Grid items and Flex items with `oveflow` != `visible` ignore their content when calculating their min-content contribution (unless opted into that behavior explicitly by setting their `width` or `min-width`--a specified width (such as width:100px or width:min-content) always takes precedence over one implied by the content when calculating the min-content contribution). - Currently we have a rule that zeroes out the value of `min-width`/`min-height` on such boxes, but the min size is just a floor on the min-content size: e.g. if a block has a `min-width` of zero (the default) its min-content size is still based on the content. This proposal address the *min-content contribution*. 2. Block boxes with `overflow-inline` != `visible` and `overflow-inline` != `hidden` ignore their content when calculating their min-content contribution (〃). - Block boxes don't have special behavior for `overflow: hidden` because that is frequently used to mean `display: flow-root`. (Flex and Grid items don't need this exception because they're flow-roots by default.) - Block boxes don't have special behavior for the block axis because a) it requires multiple layout passes through the BFC in which the block participates if we need to propagate this up, due to floats and margin collapsing and other fun b) it's not required by the use case for addressing this issue on blocks, which are only about their inline min-content contributions. The proposal directly address the expectation that authors have that an element with scrollbars is “squishy” because its overflow is already being handled by the choice to scroll. It solves the problem of arbitrary descendants of a grid or flex item unexpectedly expanding its minimum size: this action-at-a-distance is the source of all the confusion and frustration around this issue. (For example, an `overflow:visible` flex item, which resolves the default `min-width:auto` to its min-content width, can accidentally get super-wide because of a scrollable `pre` nested somewhere deep in its descendants, and there's no obvious way to track down that the `pre` is the element causing the problem.) In cases where the scrollable box is squished too far, the solution is to add an explicit `min-width` or `min-height` at the point where there's a problem, which is an understandable and intuitive fix. Downsides: Potential web-compat where an author set `overflow` to a scrollable value expecting that the box would set the size of its container such that this scrollable box has no overflow and doesn't scroll. (Why are you doing this.) Scrollable flex/grid items may shrink down to zero, which isn't very usable, if the author didn't think about handling narrow screens. (E.g. `grid-template-columns: auto 1fr` with scrollable grid items; or equivalent layout in Flex.) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1865#issuecomment-347631894 using your GitHub account
Received on Tuesday, 28 November 2017 19:13:04 UTC