Re: [csswg-drafts] [css-sizing-4] Scrollbars when intrinsic-width is > width? (#4415)

> But you were asking about the element itself having scrollbars or not, not a container. I think if we don't do/say anything special, the above logic says that it would not. It would just be the size you gave it, and the overflowing or not would depend on the actual size of the element's content. And since fiddling with the element's intrinsic size doesn't do anything to the element's content, I think that behavior is reasonable.

Cool, so that confirms that the spec needs a fix, then. ^_^

The *point* of `intrinsic-size` (for non-replaced elements, at least) is to at least partially replace the calculations of "how big is my content". Since it's the "how big is my content" calculations that drive scrollbars, intrinsic-size should also drive scrollbars.

`::contents` shouldn't be required here; if we were able to use it, we wouldn't even need `intrinsic-width` to trigger the behavior; a plain `width` would do the same thing. Note, tho, that it only does "the same thing" in simple contexts like block layout; a grid container would instead auto-place the `::contents` pseudo-element into the grid, and then continue to do its normal intrinsic sizing calculations!

> I think this way of looking at it works even better if consider the other direction: assigning a smaller than natural intrinsic width a non replaced element.

In this case we should still pop scrollbars; the contents will still project layout overflow, just not affect intrinsic size itself.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4415#issuecomment-541964374 using your GitHub account

Received on Monday, 14 October 2019 22:50:30 UTC