[css-values] Use of 100vw is causing pointless horizontal scrollbars on some websites

Windows users and macOS users that have enabled “Show scroll bars: Always” are seeing pointless horizontal scrollbars on some websites that use the 100vw value. One common use-case for 100vw are full-width elements:

.full-width {
    width: 100vw;
    position: relative;
    left: 50%;
    right: 50%;
    margin-left: -50vw;
    margin-right: -50vw;
}

Examples:

If you can’t check for yourself and are not sure what a pointless horizontal scrollbar is, watch this video that I posted on Twitter.

The authors of these websites are most likely not aware of this issue because they developed the website on macOS with default (overlaid) scrollbars, where this issue does not occur.

As a result, many people are experiencing these pointless horizontal scrollbars, and a fair share of these people probably find them annoying (raises hand 🙋‍♂️).

Does the Working Group consider this to be a problem that requires an intervention? Are there any proposed features or changes that could help make this problem go away over time?

See #1766. Not very easy to do them auto-magically work because it'd be cyclic (declarations using vw units could cause scrollbars to appear which would change how vw would resolve).

It'd be feasible to make them work with with overflow: scroll, but only Firefox implemented that and nobody else did so we removed that...

@emilio

@emilio I did not suggest to make changes to viewport units. I asked if the Working Group plans to do something about the problem of pointless horizontal scrollbars that appear on some websites, a problem that I predict will not go away on its own. Does this problem require an intervention or can it be ignored?

I guess we can reopen, but it's hard to say from a web engine when a scrollbar is "useless" if there's content overflowing.

Related: #5254

Also related: #5232

Not very easy to do them auto-magically work because it'd be cyclic (declarations using vw units could cause scrollbars to appear which would change how vw would resolve).

Percentages are not cyclic now, so why couldn't vw (or new unit) be equivalent to "percentage of root element"? Every single time I've used vw units, I don't care one little bit how wide the viewport is if part of it is being covered by a scrollbar. I only care what part of the viewport I can "draw" the element in without causing horizontal scrolling. If my element is direct child of the body, this is super easy, 100% (or just don't specify any width is element is block).

<body>
  <div class="one" style="width: 100%;"></div>
  <div class="two" style="width: 50%;">
    <div class="two-child" style="width: 100vw;"></div>
  </div>
</body>

.one and .two-child should resolve as same exact width regardless of vertical scrollbar being visible or not. Can we make this happen somehow?

Percentages are not cyclic now, so why couldn't vw (or new unit) be equivalent to "percentage of root element"?

Because percentages aren't resolved until layout, while viewport units are. More generally, content inside the viewport can't affect the viewport size, but it can affect whether the root element shows scrollbars or not.

@emilio

@emilio Okay so why not create a new unit (or modify vw) that resolves at layout like percentage?

Well, that is one option. Note that that would behave subtly differently than the current viewport units. Adding layout-time relative units is relatively hard (no pun intended) compared to adding units that resolve at computed-value time like vh / vw. Though definitely not impossible.

Also related: #4329

@emilio

@emilio I don't know too much about the actual rendering processes, but this description makes it seem like it would be easier to calculate as there wouldn't need to be any tree traversal to compute, there would just be the one root node to be concerned with. But I understand there has to be more to it.

Up to this point we've calculated which nodes should be visible and their computed styles, but we have not calculated their exact position and size within the viewport of the device---that's the "layout" stage, also known as "reflow."

To figure out the exact size and position of each object on the page, the browser begins at the root of the render tree and traverses it.

The body of the above page contains two nested div's: the first (parent) div sets the display size of the node to 50% of the viewport width, and the second div---contained by the parent---sets its width to be 50% of its parent; that is, 25% of the viewport width.

Very confusing as their use of "viewport width" isn't the same as the vw unit, which you would reasonably assume.

Also related: #4691

[css-values-4] Make unconditional scrollbars on the root finally affe…

Edits are done for the WG resolution in #6026 (comment) and filed follow-up wrt dv* etc in #10059

[css-values-4] Add viewport unit tests for scrollbars

Bug 1884841 [wpt PR 45036] - [css-values-4] Add viewport unit tests f…

[css-values-4] Add viewport unit tests for scrollbars

Bug 1884841 [wpt PR 45036] - [css-values-4] Add viewport unit tests f…

[viewport units] Enable SmallerViewportUnits by default

Navigation Menu

Repository navigation

[css-values] Use of 100vw is causing pointless horizontal scrollbars on some websites #6026

72 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-values] Use of 100vw is causing pointless horizontal scrollbars on some websites #6026

Description

Activity

emilio commented on Feb 22, 2021

simevidas commented on Feb 22, 2021

emilio commented on Feb 22, 2021

felipeerias commented on Feb 24, 2021

felipeerias commented on Feb 26, 2021

coreyworrell commented on Feb 26, 2021

emilio commented on Feb 26, 2021

coreyworrell commented on Feb 26, 2021

emilio commented on Feb 26, 2021

bramus commented on Feb 26, 2021

coreyworrell commented on Feb 26, 2021

johannesodland commented on Mar 17, 2021

72 remaining items

fantasai commented on Mar 11, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions