[css-sizing-4] Scrollbars when intrinsic-width is > width?

[tabatkins]

What should happen with scrollbars in overflow:auto; intrinsic-width: 200px; width: 100px;?

If the element was filled with 200px worth of child content, it would definitely create scrollbars. I believe intrinsic-width should do the same.

As an added bonus, this helps with some infinite-scroller cases that currently use a tall dummy element to make the scrollbar look right.

[tabatkins]

@frivoal Does anything need to be done in Overflow to make this happen? I'm unclear if overflowing happens automatically as a result of intrinsic sizes, or from something more explicit that's essentially the same thing.

[AmeliaBR]

If the intrinsic-* properties are intended to replace the intrinsic size from the child content in the layout calculations, then yes, it should definitely trigger scrollbars if it is larger than the box size for the parent.

But that brings up the question: Do we, in general, have a good definition of how intrinsic/extrinsic sizing, the box model, and scroll overflow work? Because if not, this would be a good time to define it.

[frivoal]

TL;DR: If you want to cause/avoid scrollbars, you need to change the actual size of then content so that it does/doesn't stick out, not the size of the (potentially) scrolling element.

---

If you have an image with 200px intrinsic width, and you set its width to 100px, then it doesn't overflow 100px anymore. By that logic, intrinsic-width: 200px on something that has width: 100px wouldn't cause overflow either: intrinsic size is what you use when you need a size but don't have a [specified/computed] one (yet). If you are given an explicit size, the intrinsic one doesn't matter, and if nothing actually sticks out, then you don't overflow.

That's consistent with the point of view of the css-overflow spec (emphasis mine):

CSS uses the term overflow to describe the contents of a box that extend outside one of that box’s edges (i.e., its content edge, padding edge, border edge, or margin edge).

However, it gets more interesting/complicated when you consider the min-content size. In most layout modes, the initial value of min-width resolves to 0, but if you're in flexbox or grid, or if you manually set it to min-width: min-content, then we would force the content to adopt its assigned intrinsic width, (which is possibly larger than its natural one).

If a parent/container has overflow:auto and is limited to 100px, then we'll overflow an show scrollbars.

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.

A while back, @Loirooriol proposed a ::contents pseudo element (#2406). If we had that, you could opt into the behavior you seem to want. Instead of:

div {
   intrinsic-width: 200px;
   /* and maybe "min-width: min-content;" */
   width: 100px;
   overflow:auto;
}

you'd do

div::contents {
   display: block; /*the default is display: contents; */
   intrinsic-width: 200px;
   min-width: min-content;
}
div {
   width: 100px;
   overflow:auto;
}

I suppose we could define something analogous to that to happen automatically for non replaced elements when you assign an intrinsic-width, but I think I the behavior I've described above falls out more naturally of what we already have, and that to enable the scrollbar-is-desired case, we should give @Loirooriol 's proposal serious thoughts, because there are quite a few situations, like this one, where having this sort of general purpose magic would save us from inventing lots of special purpose magic.

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.

<div>123456789</div>

div {
    font-family: monospace;
    intrinsic-width: 2ch;
   /* and maybe "max-width: max-content;" */
    width: 4ch;
    overflow: auto;
}

I don't really see what logic would cause the content to honor the intrinsic size and by fitting, causing the absence of scrollbar in that case. However, you could do something like that:

div {
    font-family: monospace;
    width: 4ch;
    overflow: auto;
}
div::contents {
    display: block;
    intrinsic-width: 2ch;
    max-width: max-content;
    overflow: hidden; /* or ''overflow-wrap: break-words'',
                         or " contain: strict",
                         or some other thing to force the content
                         to actually stay within the requested max-size. */
}  

[tabatkins]

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.

[frivoal]

is to at least partially replace the calculations of "how big is my content".

Is it? It feels to me that it is to replace the calculations of "how big am I", which typically depends on content, but isn't the same.

Anyway, leaving the possibility of ::contents aside, I still don't see why triggering scrollbars would be useful here. Again, and image can have a big intrinsic size, but if you size it to something smaller than that, it doesn't cause scrollbars, it just resizes to the size you asked. I think it should be the same with non replaced elements, and you'd only get scrollbars if the content of the element sticks out, which is a separate question.

Asking differently, especially given that it doesn't obviously fall out of how things work, I'd like to see a use-case for wanting scrollbars based on the intrinsic size when there's not actual content to scroll to.

[vmpstr]

Asking differently, especially given that it doesn't obviously fall out of how things work, I'd like to see a use-case for wanting scrollbars based on the intrinsic size when there's not actual content to scroll to.

As anecdotal evidence, and not at all first hand experience, it is common for developers implementing virtual scrollers to have spacer divs placed inside scrollers in order to size the scrollbar to give the impression of long content. When the user scrolls close to the region without "real" content, script would shrink the spacer and replace it with "real" content instead.

If intrinsic-height is considered during overflow calculation (ie for overflow purposes, it would the max of intrinsic-height and the height of real contents), then this pattern is much easier achieved by simply specifying the intrinsic-height of the scroller. There would be no need to fiddle with or recalculate the size of the spacer, which wouldn't be required at all.

[bfgeek]

Asking differently, especially given that it doesn't obviously fall out of how things work, I'd like to see a use-case for wanting scrollbars based on the intrinsic size when there's not actual content to scroll to.

This is a common request of web-developers which is (as Vlad said) - done with placeholder elements today. For an example see:
https://googlechromelabs.github.io/ui-element-samples/infinite-scroller/
(this is just one approach w/ transform, but there are others).

From personal experience (when I was a front-end engineer) I used a dummy element to crate scrollable overflow whenever I built scrollers which loaded additional content.

cc/ @surma who might be able to provide additional context.

[tabatkins]

Is it? It feels to me that it is to replace the calculations of "how big am I", which typically depends on content, but isn't the same.

No, "how big am I" is already handled by 'width' and 'height'. This is definitely replacing "how big are my contents", specifically for the purpose of working with the async-rendering stuff that delays laying out/rendering a container's contents until needed.

And that's precisely what the "intrinsic size" concept covers - what's the minimum and maximum size that my content can make me.

Further, as Ian and Vlad said in their comments, people are already commonly using hacks to create scrollbars that look approximately right when doing virtual rendering on their own, and having this property provide that functionality intrinsically seems like a nice accidental win.

Whether or not to generate scrollbars should, of course, be determined by the larger of the intrinsic-size value and the actual size of the contents, so we don't hide content by accidentally making it unscrollable; this is particularly important for the case where "intrinsic-size: 0;" is used to override the bad intrinsic sizing behavior of scrollable elements in grid/flexbox!

[fantasai]

Questions:

• Does contain-intrinsic-size affect the scrollable overflow area?
• If so... does contain-intrinsic-size affect the scrollable overflow area of the contained element only, or also its ancestors?

@tabatkins and I are leaning towards it only affects the scrollable overflow area of the contained element itself, if it happens to be a scroll container.

[fantasai]

Proposed wording (appended sentence marked with INS):

This property allows elements with [=size containment=] to specify an explicit intrinsic inner size, causing the box to size as if its in-flow content totals to a width and height matching the specified [=explicit intrinsic inner size=] (rather than sizing as if it were empty). If the box is a [=scroll container=], its [=scrollable overflow area=] must also be inflated as necessary to (independently) fit both this phantom “content” as well as its actual content.

[cbiesinger]

So the other question is how the scrollbar size should affect the intrinsic size. I guess what happens is, if one axis is specified and contain-intrinsic-size causes overflow in that direction, the scrollbar size is added to the intrinsic size in the other direction...?