[css-overflow-4] effect of gutters on viewport units

[frivoal]

https://drafts.csswg.org/css-values/#viewport-relative-lengths says:

The viewport-percentage lengths are relative to the size of the initial containing block. When the height or width of the initial containing block is changed, they are scaled accordingly. However, when the value of overflow on the root element is auto, any scroll bars are assumed not to exist.

This is fine if we have overlay scrollbars, and scrollbar-gutter is auto or stable, since no space is consumed for the scrollbar anyway.

This seems regrettable, but probably unavoidable, if we have classic scrollbars and scrollbar-gutter is auto, since the presence or absence of scrollbars will depend on layout, and having the viewport units depend on layout is problematic.

However, if we have classic scrollbars and scrollbar-gutter is stable (or always, which does the same thing in the case of classic scrollbars), it would seem much preferable for the viewport percentage units to be relative to the ICB as reduced by the always-present gutter.

For overlay scrollbars with analways scrollbar-gutter, I suspect it should they should also be relative to the ICB as reduced by the always-present gutter, but I am less sure, and the answer might depend on the resolution to #5253.

[frivoal]

cc: @felipeerias

[felipeerias]

@frivoal : would the both value affect this as well?

[frivoal]

Good question. I'd say yes, so that width: 100vw gets you exactly the largest size that fits without overflowing

[Sugarteeth]

I've seen things as outlandish as introducing new units to css just to avoid changing the root problems with the default implementation of vh/vw, both on desktop and mobile. Why don't we implement something like the box-sizing rule, but for scrollbars, to switch whether or not the scrollbar or chrome is considered a part of the viewport or not? There doesn't need to be a debate on how vw/vh should work if the individual user can decide for themselves.

Call it something like "viewport-box" maybe, and have the options be like "chrome-(inside|outside), scroll-(inside|outside)", with chrome-ouside & scroll-inside being the default as it is now. No worrying about backwards compatibility, just make the current implementation the default and put the onus on the user.

[simevidas]

it would seem much preferable for the viewport percentage units to be relative to the ICB as reduced by the always-present gutter

It would definitely be preferable, but I suspect it wouldn’t be good enough. In a browser with classic scrollbars, if the page does not scroll, an element with a width of 100vw would not go all the way to the right edge of the viewport. There would be that gap of 15 to 17 pixels for the gutter. If developers don’t like this gap, they won’t use 100vw, and instead they’ll use whatever solution or hack that gives them the actual viewport width at all times.

In browsers with classic scrollbars, the viewport width is dynamic; it changes when the scrollbar appears or disappears. Developers want to be able to make any element full width so that the element is as wide as the viewport. That’s a widely known use-case.

The CSS Working Group needs to decide if this is a valid use-case. If it is, then they should focus on creating a solution for it.

[bramus]

it would seem much preferable for the viewport percentage units to be relative to the ICB as reduced by the always-present gutter

It would definitely be preferable, but I suspect it wouldn’t be good enough. In a browser with classic scrollbars, if the page does not scroll, an element with a width of 100vw would not go all the way to the right edge of the viewport. There would be that gap of 15 to 17 pixels for the gutter. If developers don’t like this gap, they won’t use 100vw, and instead they’ll use whatever solution or hack that gives them the actual viewport width at all times.

In that case maybe authors should not use a stable gutter to begin with? The idea behind a stable gutter is to prevent layout shifts. If 100vw would change size depending on the scrollbar being there or not, that would defeat the purpose of the gutter.

You could, however, say something for position: fixed elements, as you would typically want those to actually do cover that gap. Think of a backdrop that covers the whole page. The effect of the gutter on the Layout Viewport is being discussed in #8099

[tabatkins]

So, you are absolutely, 100% correct that vw/vh should respond to scrollbar-gutter:always/stable with classic scrollbar. However, it should also be consistent with overflow:scroll, which actually has scrollbars rather than just the space. And, back in #1766, we resolved specifically to not subtract the scrollbars in overflow:scroll from the viewport units.

This was a bad decision, but as long as it stands we should be consistent in this regard, I think. We could reopen #1766, tho.

[tabatkins]

This was resolved by #6026, which did indeed reverse #1766 and resolve in favor of the request here (stable gutters on root are removed from the viewport units).