Viewport Units vs. Scrollbars

[bramus]

Viewport Units are based on the size of the ICB

The viewport-percentage lengths are relative to the size of the initial containing block

We can summarise those specific types of viewports as follows:

• Small Viewport = Size of the ICB
• Large Viewport = Size of the ICB + Size difference of Dynamic Toolbars before/after retracting

In its turn the ICB size is based on that of the Viewport (for continuous media)

For continuous media, it [the ICB] has the dimensions of the viewport and is anchored at the canvas origin

When Classic Scrollbars are present, the Layout Viewport gets resized.

As a result, the ICB will resize as well

And as a result of that, the Viewport Units should also resize, as the spec reads

When the height or width of the initial containing block is changed, they are scaled accordingly.

The latter is not the case however. The Viewport Units do not resize. Instead, they retain their size from before the ICB was resized.

This behavior is covered by the spec through this footnote:

In all cases, scrollbars are assumed not to exist.

The spec seems to be contradicting itself here. Additionally, this “scrollbars are assumed not to exist”-behavior also frustrates a lot of authors.

It would be nice if we could discuss the behavior here, and eventually make a proposal at the CSSWG.

Relevant Issues in other repositories:

• [css-values-4] Large, small and dynamic viewport units (lvh, svh & dvh) don't solve top level horizontal scrolling use cases w3c/csswg-drafts#6551
• [css-values] Use of 100vw is causing pointless horizontal scrollbars on some websites w3c/csswg-drafts#6026
• [css-values-4] The Large, Small, and Dynamic Viewport Sizes w3ctag/design-reviews#706

[jensimmons]

It would be nice if we could discuss the behavior here, and eventually make a proposal at the CSSWG.

It would be better to open issues at the CSSWG now — with the questions.
https://github.com/w3c/csswg-drafts/issues

Not having discussions here and proposing solutions at CSSWG.

Everyone involved with Interop works for companies that are members of the W3C. Everyone involved can join the CSSWG through your AB rep. And have the discussion there. It's very important to follow the proper process.

[fantasai]

@bramus If you can convince implementers to implement it, flag w3c/csswg-drafts#6026 as Agenda+. Fundamentally the reason the spec ignores scrollbars for viewport units is that it's difficult to implement. Even compromising and treating overflow: auto as a stable state in one direction or the other, and having at least 'overflow: scroll` account for the scrollbar width wasn't acceptable.

Also +1 to @jensimmons ; if there's something that needs changing in the CSS specs, flag it there. You can track things here, to make sure the spec and implementations and tests all match, but this effort isn't an actual standardization forum.

[karlcow]

There's already a lot of work for the interop effort to be done in just selecting the existing tests/specs to make sure we can improve interop.

The current fact findings effort really starts to look like a regular fact finding standard work, which indeed should happen on the CSS WG directly for many reasons: exposure, working group policies, etc.

• Finding if current WPT tests are failing is definitely ok,
• Finding if they are missing tests for a specific technology area is probably ok, though starting to be borderline in between interop and specific group.
• Investigating how the technology is working, should work or not is probably out of scope

All of that not to say, that this is wonderful work which I wanted to see happening for a long time, but it should happen at the right place.

[bramus]

• svw/dvw
• @emilio Beware of cycles
• @skobes We already have cycles
• @emilio viewport units resolve at the style stage, so we can’t do this
• @emilio not easy to change
• @dcrousso Env vars for the scrollbars seems more reasonable
• @dcrousso Only makes sense for the top level, not nested scrollers
• @emilio Same issue as before, you need layout
• @dcrousso Yeah
• @emilio You can have the default scrollbar size, but not a dynamic value
• @emilio Also beware about authors setting the scrollbar size
• @emilio Also see [css-values] Should viewport units still depend on scrollbar width for overflow:scroll? w3c/csswg-drafts#1766
• @emilio Only reasonable thing to expose is the default size
• @bramus Also see [css-env-2] env(scrollbar-inline-size) w3c/csswg-drafts#4691
• @emilio There is also an issue somewhere for exposing overlay vs classic scrollbars
• @bramus Combining that with the env would allow authors to manually calculate things
• @emilio Minimal thing indeed, but does need to expose also the thing size or when authors have changed the value
• @dcrousso Very complex, as the scrollbar size can also change on hover
• @skobes but that’s only for overlay scrollbars, not classic ones where this is not an issue
• @dcrousso true
• @emilio Let’s bring up at the WG: Media Query for the scrollbar size + env variables to get classic scrollbar sizes (vertical, horizontal)
• @bramus SGTM
• @emilio Back in the day we had something for this: overflow scroll reducing the width of viewport units. It was terrible, not recommended.

[bramus]

CSSWG issue for MQ as proposed in notes: w3c/csswg-drafts#7697 (comment)