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

simevidas commented 3 years ago

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?

emilio commented 3 years ago

See https://github.com/w3c/csswg-drafts/issues/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...

simevidas commented 3 years ago

@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?

emilio commented 3 years ago

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.

felipeerias commented 3 years ago

coreyworrell commented 3 years ago

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?

emilio commented 3 years ago

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.

coreyworrell commented 3 years ago

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

emilio commented 3 years ago

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.

bramus commented 3 years ago

coreyworrell commented 3 years ago

@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.

johannesodland commented 3 years ago

simevidas commented 3 years ago

frivoal commented 3 years ago

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...

I'm thinking we should go back to making them work with overflow: scroll and also with scrollbar-gutter:stable and scrollbar-gutter:alwaysset on the root.

hyperfekt commented 3 years ago

Is my understanding correct that there is currently no way to size elements to the viewport minus the scrollbar while also having non-floating elements outside the viewport, since using 100% to size them would give them a size larger than the viewport, and using 100vh/100vw to size them will have part of them obscured by the scrollbar?

EDIT: Apparently it is not. The root element's width can be inherited to any place in the document by having anything outside the viewport overflow it.

um83 commented 3 years ago

I suppose, that a new unit should be implemented, which determine viewport width and height without scrollbars. Without that it's not possible to make some cool stuff like horizontal document scrolling with sticky headers. Here's what I'm talking about: https://codepen.io/um83/pen/LYWBEmY

brunoais commented 3 years ago

I suppose, that a new unit should be implemented, which determine viewport width and height without scrollbars. Without that it's not possible to make some cool stuff like horizontal document scrolling with sticky headers. Here's what I'm talking about: https://codepen.io/um83/pen/LYWBEmY

this? https://github.com/w3c/csswg-drafts/issues/6113

um83 commented 3 years ago

this? #6113

yep! exactly!

jonjohnjohnson commented 3 years ago

I'm thinking we should go back to making them work with overflow: scroll and also with scrollbar-gutter:stable and scrollbar-gutter:alwaysset on the root.

@frivoal Do you think you'd still rather go this way instead of having non-overlay scrollbars (both inline and block) affect the new sv* and/or dv* units? See https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-863677668

mor10 commented 3 years ago

To approach this from a "how does someone without in-depth knowledge of the functionings of the browser understand the concept of the viewport" perspective, I've talked to developers frustrated by this issue. The mental model boils down to this:

When a scrollbar is fixed (as on Windows), the expectation is for the viewport width to be the width of the active canvas (so viewport minus scrollbar) because the scrollbar is understood as part of the chrome, not the viewport.
When a scrollbar is dynamic (as on MacOS), the expectation is for the viewport width to be the width of the full viewport, and the dynamic scrollbar is seen as an overlay on top of the active canvas, so no change should happen to the width value when the scrollbar appears/disappears.

From this perspective, which is the user perspective in this context, the implementation of any new units like dv* should be as close to the visually understood behavior as possible, ie if something looks to be part of the chrome, it is treated as part of the chrome, and if something looks to be an overlay, it is treated as an overlay.

brunoais commented 3 years ago

Maybe the distinguishing factor is whether the thing (scroll bar, in your example) is visible when the user is idling (I.e. not interacting with the page). As a preliminary condition: If it disappears when interaction stops, it's non-counted overlay. If it stays (such as the browser toolbar in mobile browsers), it's counted overlay and taken into account with the dv* units.

What do you think?

mor10 commented 3 years ago

@brunoais Yes, that's a different (and possibly clearer) way of saying the same thing.

mirisuzanne commented 2 years ago

Whatever we're able to do here should likely also apply to container (cq*) units. I like @mor10's summary of expected behavior here. It would also potentially be useful to have the ability to do something like calc(100vw - scrollgutter).

brunoais commented 2 years ago

Whatever we're able to do here should likely also apply to container (cq*) units. I like @mor10's summary of expected behavior here. It would also potentially be useful to have the ability to do something like calc(100vw - scrollgutter).

100dvw 😉 ?

ahmadalfy commented 2 years ago

Whatever we're able to do here should likely also apply to container (cq*) units. I like @mor10's summary of expected behavior here. It would also potentially be useful to have the ability to do something like calc(100vw - scrollgutter).

100dvw 😉 ?

It is still behaving the same. on Chrome (108) and Safari, 100vw is still the same as 100dvw when scrollbars exist.

brunoais commented 2 years ago

Whatever we're able to do here should likely also apply to container (cq*) units. I like @mor10's summary of expected behavior here. It would also potentially be useful to have the ability to do something like calc(100vw - scrollgutter).

100dvw 😉 ?

It is still behaving the same. on Chrome (108) and Safari, 100vw is still the same as 100dvw when scrollbars exist.

Then it's a browser bug. Complain to its maker

bramus commented 2 years ago

It is still behaving the same. on Chrome (108) and Safari, 100vw is still the same as 100dvw when scrollbars exist.

Then it's a browser bug. Complain to its maker

It’s not a browser bug. All browsers are doing what the spec says here (“any scrollbars are assumed not to exist”), hence this issue.

fantasai commented 1 year ago

To be clear, the spec says this because the browser vendors asked for it to match their implementations. It didn't originally say this.

brunoais commented 1 year ago

I specifically specified to consider the scrollbars in my proposal so this wouldn't happen!

gilmoreorless commented 1 year ago

So just to make sure I've understood this correctly...

Developers have been continually frustrated that there's no viewport unit that maps to the space remaining after scrollbars are added. This is because of the mental model summarised by @mor10 in an earlier comment.
@brunoais puts together a well thought-out proposal in #6113 for dynamic viewport units. It includes an algorithm for resolving potential infinite layout cycles regarding scrollbars, specifically to address the problem in point 1.
The proposal is added to the CSS Values 4 spec. But browser vendors asked for the spec to keep the text "any scrollbars are assumed not to exist", so that it matched their implementations. Even though that line of text *completely defeats the purpose of the `dv` units in the first place!**
~A representative from a browser vendor effectively tells the original author of the proposal that the author doesn't know how the units are meant to work~: https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-1305449868 (Edit: Not the case, just my misinterpretation.)
We all end up with yet another set of viewport units that don't solve this scrollbar problem, even though that's what they were meant to do.

I can't speak for @brunoais, but I know that if I was in their position I'd be bloody furious about this process. To this outsider it's really not a good look for the treatment of external contributions.

I come across sites and apps with unintended horizontal scrollbars like this almost daily. (Edit: I even saw it on just the second link I opened after originally posting this comment.) The most frustrating thing for me is that some browser vendors have previously said taking the scrollbars into account is close to impossible. Except Firefox has previously implemented that behaviour, so it's clearly possible to some extent. And as noted above, the original proposal outlined what to do to avoid infinite cycles.

brunoais commented 1 year ago

Thank you. That was very well picked up and explained. Thankfully, due to how I am, I'm not furious. However, I'm seriously disappointed. Feels like right to repair in USA's NY state.

Edit:

tells the original author of the proposal that the author doesn't know how the units are meant to work

BTW, that's not how I interpreted it. I interpreted it as "The spec states this ``, so there's no browser bug"

(Now bramus answered... It's what he wrote. So I assume I interpreted it correctly)

bramus commented 1 year ago

4. A representative from a browser vendor effectively tells the original author of the proposal that the author doesn't know how the units are meant to work: [css-values] Use of 100vw is causing pointless horizontal scrollbars on some websites #6026 (comment)

FWIW, I was trying to point out that – at this moment – it is not considered a browser bug, as the browsers follow what the spec says. You could say it’s a spec issue, though. Apologies if this came across differently.

gilmoreorless commented 1 year ago

You could say it’s a spec issue, though. Apologies if this came across differently.

Fair enough, seems like it was my misinterpretation, apologies in return. I think it was the "hence this issue" that twisted my interpretation of the comment, as it seemed (to me) to be a circular argument regarding dv* units. I've edited my comment accordingly.

simevidas commented 1 year ago

Has anyone ever suggested a dynamic environment variable that would return the current viewport size reduction caused by a classic scrollbar on the page? Would that be possible? Would that make sense?

.full-width {
  width: calc(100vw - env(viewport-reduction-inline));
}

So if the page does not have a vertical classic scrollbar, env(viewport-reduction-inline) returns 0px, and the element is 100vw wide, but if the page does have such a scrollbar, the environment variable returns how much inline space this scrollbar consumes in the inline direction (usually 15 to 17 pixels), and the page can subtract that length from 100vw to get the actual viewport width and then set the element to that width.

This does not seem like a good solution to me, but I wanted to put it out there, since I haven’t seen this suggested yet.

bramus commented 1 year ago

Has anyone ever suggested a dynamic environment variable that would return the current viewport size reduction caused by a classic scrollbar on the page? Would that be possible? Would that make sense?

In https://github.com/web-platform-tests/interop-2022-viewport/issues/15#issuecomment-1268596477 this was discussed, and @emilio noted that you can’t have a dynamic value because it depends on layout and can cause layout cycles: “Only reasonable thing to expose is the default size” … which brings us back to env(scrollbar-inline-size).

brunoais commented 1 year ago

@simevidas https://github.com/w3c/csswg-drafts/issues/6113

emilio commented 1 year ago

I think exposing scrollbar-inline-size plus a media query for overlay scrollbars is the most straight-forward solution. Those are things you can trivially determine via script anyways.

brunoais commented 1 year ago

Those are things you can trivially determine via script anyways.

The idea is to solve layout problems with CSS, not with js. Js is for interactivity. Layout with Js is and will always be a hack

kizu commented 1 year ago

In our product we're currently essentially calculating the scrollbar-inline-size via JS, creating an invisible block with an overflow, and retrieving its width if it has one, then storing it as a custom property on root, to be used in calculations.

Being able to use a keyword for this, alongside a query to detect if scrollbars are present on a container would be very helpful.

Why I'm mentioning “keyword” and “container” rather than an “environment variable” and “media query”: we have scrollbar-width which can control if we have the scrollbar, and we can have a container that can be scrolled programmatically when it has overflow: hidden. That means that authors could want to a) detect if a certain scrollport has a visible scrollbar, and b) get the width of a scrollbar in that case, which can be different for different containers (scrollbar-width and also current webkit scrollbar pseudo-elements).

simevidas commented 1 year ago

@emilio I don’t think scrollbar-inline-size is a solution to the 100vw problem that’s being discussed in this issue. See my comment in https://github.com/w3c/csswg-drafts/issues/4691#issuecomment-1715038961 for why I think that is.

If CSS won’t answer the question “Is a vertical classic scrollbar currently present on the page?”, then I think the best way to deal with the 100vw problem would be to reduce the size of 100vw when scrollbar-gutter: stable or overflow-y: scroll is set on <html>, as proposed in https://github.com/w3c/csswg-drafts/issues/5254. With that change, width: 100vw would no longer cause horizontal overflow on pages with stable gutters. That seems to be the best we can do.

simevidas commented 1 year ago

As @kizu’s pointed out in https://github.com/w3c/csswg-drafts/issues/4691#issuecomment-1715388016, container query units can help with this problem. After turning <body>* into a query container, 100cqw can be used as a substitute for 100vw to get the desired behavior. Unlike 100vw, 100cqw becomes smaller when a classic scrollbar appears on the page.

(*I use <body> because it didn’t work on <html> in Safari. I filed a WebKit issue.)

For example:

body {
  margin: 0;
  container-type: inline-size;
}

.full-width {
  position: relative;
  left: calc(50% - 50cqw);
  width: 100cqw;
}

Demo 1: https://codepen.io/simevidas/pen/LYMrPZo?editors=0100

As far as I can see, 100cqw behaves the way developers wanted 100vw to behave with regards to classic scrollbars. In that case, I guess this issue can be closed. Developers can use 100cqw instead of 100vw for the “full-width” use-case, and in other situations where they need the actual viewport width in CSS.

One limitation of 100cqw is that it represents the width of the closest ancestor query container, which may not necessarily be <body> if the page contains other, nested query containers. In that case, developers can store the “page width” value in a registered custom property, and then use that property instead of 100cqw.

@property --page-width {
  syntax: "<length>";
  initial-value: 0px;
  inherits: true;
}

body {
  margin: 0;
  container-type: inline-size;
}

article {
  /* store <body> width in registered custom property */
  --page-width: 100cqw;

  /* <article> is nested query container for demo purposes */
  container-type: inline-size;
}

.full-width {
  position: relative;
  left: calc(50% - var(--page-width) / 2);
  width: var(--page-width);
}

Demo 2: https://codepen.io/simevidas/pen/KKbJgBR?editors=0100

yuito-git commented 1 year ago

Why can a custom property registered with @property save "page width"? When I tried with "100%", it did not work.


<style>
 @property --page-width {
   syntax: '<length-percentage>';
   inherits: true;
   initial-value: 0%;
 }

 body {
   --page-width:100%;
 }

 .child {
   width: var(--page-width); /*Width of parent element(1000px), not page width*/
 }
</style>

<div class="parent" style="max-width:1000px;">
 <p class="child">Hello</p>
</div>

Demo: https://codepen.io/mikiprogram/pen/QWzzvMR

Is there a statement on this in the following W3C page? URL: https://www.w3.org/TR/css-properties-values-api-1/ I would be glad to know!

simevidas commented 1 year ago

@yuito-git Sorry, there was a mistake in my code. The --page-width: 100cqw declaration needs to be in a child of <body>. It doesn’t work if the declaration is in <body> itself. I’ve corrected my code and provided a second demo that shows that this solution works in browsers (Chrome and Safari, for now).

yuito-git commented 1 year ago

@simevidas Thank you very much! I found that the fix works for "100cqw". However, if I change the value of the CSS variable "page-width" from "100cqw" to "100%", I get the width of the parent element, not the page width. Do you know anything about this behavior?

simevidas commented 1 year ago

@yuito-git In my demo 2, if you just replace --page-width: 100cqw; with --page-width: 100%;, the value of --page-width will be 0px because that custom property is registered as a <length>, so trying to assign a percentage results in the declaration being ignored by the browser. You can change the custom property’s type to <length-percentage>.

yuito-git commented 1 year ago

@simevidas In my demo, I have specified <length-percentage> for syntax, but it is not the page width. Why is this? Is the unit "cqw" special?

css-meeting-bot commented 11 months ago

The CSS Working Group just discussed [css-values] Use of 100vw is causing pointless horizontal scrollbars on some websites, and agreed to the following:

RESOLVED: if overflow:scroll is set on the root element (not propagated from body), account for the default scrollbar width in the size of vw. Also take scrollbar-gutter (and scrollbar-width, the property with "normal" and "thin"?) into account on the root. Ignore all of these in MQs. and also ignore all of these when using vw/vh units on the root element, if necessary

The full IRC log of that discussion

<chrishtr> ah fixed
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/5254
<dholbert> TabAtkins (IRC): this is an issue that crosses a few related issues
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/1766
<dholbert> TabAtkins (IRC): several years ago, we resolved that viewport units would not subtract the size of root scrollers' scrollbars, even when the page is explicitly overflow:scroll
<dholbert> TabAtkins (IRC): Obviously overflow:auto is cyclic and not usable
<dholbert> TabAtkins (IRC): But for overflow:scroll, due to impl complexity and various issues, we decided to not subtract that. That means width:100vw will overflow with overflow:scroll; you'll get horizontal scrollbars
<dholbert> TabAtkins (IRC): This makes authors confused and annoyed. Florian suggests we might want scrollbar-gutter to impact resolution of viewport units. If you know you're going to be reserving space so that a screen-filling element won't fill in that spot, presumably you want a 100vw element to fit in that width and not overflow
<dholbert> TabAtkins (IRC): But we need to be consistent. Want scrollbar-gutter and forced scrollbars to behave the same
<dholbert> TabAtkins (IRC): Can we revert the old issue? and have forced scrollbars on the root scroller subtracted when resolving 100vw,
<emilio> q+
<dholbert> TabAtkins (IRC): In webkit and chrome, the width of scrollbars is controllable via scrollbar pseudos. We'd ignore that since that produces another cyclic issue
<dholbert> TabAtkins (IRC): we'd subtract the default width of scrollbars
<florian> q+
<dholbert> TabAtkins (IRC): authors continue to complain about useless horizontal scrollbars with 100vw or 99vw etc. Browser is refusing to subtract space that it knows something will never fill. Creates a problem for authors
<Rossen_> ack emilio
<dholbert> emilio (IRC): two thigns. first: do you recall what's the status of propagation of scrollbar-gutter to the root
<dholbert> TabAtkins (IRC): not sure. I suspect we don't do additional propagation. try not to do propagation on new things
<dholbert> emilio (IRC): my gut feeling, as long as we make this dependent only on style of :root, not accounting for overflow propagation of the body, it's workable. not pretty, but workable
<dholbert> emilio (IRC): in general seems like it'd be nice to fix this. I agree it's unfortunate that it doesn't work
<chrishtr> "As for the overflow property, when scrollbar-gutter is set on the root element, the user agent must apply it to the viewport instead, and the used value on the root element itself is scrollbar-gutter: auto"
<dholbert> emilio (IRC): I'm skeptical of making it implicitly depend on the body's computed style, because then you end up with funny cycles
<chrishtr> https://drafts.csswg.org/css-overflow/#scrollbar-gutter-property
<dholbert> emilio (IRC): style container queries, etc. stuff gets messy real fast
<dholbert> emilio (IRC): the other thing: media queries right now resolve viewport units. We'd need to make sure we don't account for scrollbars in that case, or else it's trivially cyclic
<Rossen_> ack florian
<dholbert> TabAtkins (IRC): agreed. It'd work the same as font-size where it takes some initial value that disregards styles on the page
<dholbert> florian (IRC): not sure I understand impl complexity problems that came up last time. If those were in the way, are they in the way of scrollbar-gutter too?
<dholbert> emilio (IRC): main difference between scrollbar-gutter and overflow is the propagation stuff, impl-complexity wise
<dholbert> emilio (IRC): it was messy when gecko was trying to account for this with overflow propagation from body
<TabAtkins> "However, unlike the overflow property, the user agent must not propagate scrollbar-gutter from the HTML body element."
<TabAtkins> So yeah, overflow-gutter doesn't propagate
<emilio> great
<bramus> q+
<dholbert> florian (IRC): authors commonly depend on this. We can just tell them put it on the root directly, and I suppose that's a thing people can learn
<fantasai> +1 bramus
<dholbert> bramus (IRC): I want to underline what tab said; authors are really bitten by this. Longstanding problem, would be so helpful for authors
<Rossen_> ack bramus
<Rossen_> ack fantasai
<dholbert> fantasai (IRC): proposed resolution is that we account for scrollbars when overflow is scroll on the root element directly, or when scrollbar-gutter is on the root element directly, and we don't handle propagation?
<dholbert> fantasai (IRC): i.e. we don't account for scrollbars propagated from body to root
<TabAtkins> proposed resolution: if overflow:scroll is set *on the root element* (not propagated from body), account for the default scrollbar width in the size of vw. Also take scrollbar-gutter (and scrollbar-width, the property with "normal" and "thin"?) into account on the root. Ignore all of these in MQs.
<chrishtr> q+
<dholbert> emilio (IRC): and should this account for scrollbar-width on the root (not the webkit scrollbar pseudos)
<Rossen_> ack chrishtr
<dholbert> TabAtkins (IRC): my proposed rsln agrees with that, yeah
<dholbert> chrishtr (IRC): (talks through resolution)
<dholbert> chrishtr (IRC): this would apply to iframes?
<dholbert> TabAtkins (IRC): correct
<emilio> q+
<dholbert> bramus (IRC): not sure about scrollbar-gutter:stable scenario; then you reserve space on left edge as well
<dholbert> bramus (IRC): then you might get an overlay that doesn't paint on the left side despite 100vw
<dholbert> TabAtkins (IRC): that's what you're asking for if you use that value
<dholbert> florian (IRC): yup, that's what it does
<bramus> Screenshot: https://user-images.githubusercontent.com/213073/202724538-b20f14bd-489e-4e6f-a9df-519d4a11e617.png
<dholbert> florian (IRC): if you use "stable both", that is
<dholbert> chrishtr (IRC): but if you don't use "both", it just goes on the side where it normally appears
<dholbert> bramus (IRC): see screenshot. Then you can't paint something in the left there? your overlay won't be entirely overaying
<dholbert> TabAtkins (IRC): That's because you're explicitly asking for that space. width:100% won't fill that space either
<dholbert> TabAtkins (IRC): there are other ways to handle this.
<dholbert> emilio (IRC): fixed-pos would handle this too
<dholbert> fantasai (IRC): I see bramus's concern; you want your content to be inset away from the scrollers, but if you have an article with images every so often that should stretch the width of the screen, maybe you want them to cover the gutters
<dholbert> fantasai (IRC): you might need to set scrollbar-gutter on a more inner element to get that behavior
<chrishtr> or we could add another unit in the future if this situation is common
<TabAtkins> seriously, this is an explicit request from the author to not let them use that space
<miriam> q+
<dholbert> florian (IRC): auto scrollbars are weird. the traditional tradeoff is you get to use all the space, but layout is unstable. This gets you the reverse; stable layout, but you can't use all the space. Not amazing, but you have to pick
<emilio> +1 TabAtkins
<dholbert> bramus (IRC): maybe this is an edge case. I'm fine if we couldn't draw in that area
<emilio> q?
<fantasai> I think the issue here is that `scrollbar-gutter` only applies to scroll containers. If it applied to all elements, we could solve bramus's problem cleanly
<Rossen_> ack emilio
<TabAtkins> you can absolutely fill that area with multiple methods, just something placed via normal flow with a 100vw (or 100%) width won't fill it
<dholbert> emilio (IRC): do we need viewport units, when used on the root, not to account for the scrollbars?
<dholbert> emilio (IRC): generally we wouldn't need this restriction, with new fancy calc and stuff, it seems like it might not be needed?
<dholbert> emilio (IRC): similar to root em units and root line height; we avoid them introducing a dependency...
<Rossen_> q?
<dholbert> TabAtkins (IRC): giving access to full viewport width, ignoring scrollbars
<dholbert> emilio (IRC): does that need to be the behavior to avoid cycles? The properties we're depending on are only keywords, which is ~fine, but I'm not sure if you can introduce a weird dependency with calc
<Rossen_> ack miriam
<dholbert> miriam (IRC): some truth to if you set 'stable' you're asking not to use that space
<dholbert> miriam (IRC): this is why people in the threads keep asking for a gutter-end variable, so you can choose which one and use the space if you want
<dholbert> florian (IRC): so the variable would be the gutter size? right
<dholbert> bramus (IRC): you could use it to see if the scrollbar is there... an automatic solution here is way better
<dholbert> TabAtkins (IRC): let's not let the perfect be the enemy of the good. Don't design for the corner case of 'both always'
<bramus> +1 to what tab just said.
<miriam> +1
<dholbert> TabAtkins (IRC): can we resolve here and handle this corner case in another issue
<TabAtkins> proposed resolution: if overflow:scroll is set *on the root element* (not propagated from body), account for the default scrollbar width in the size of vw. Also take scrollbar-gutter (and scrollbar-width, the property with "normal" and "thin"?) into account on the root. Ignore all of these in MQs.
<dholbert> fantasai (IRC): as an issue in the scrollbar spec maybe
<dholbert> Rossen_ (IRC): and the 'both always' issue will be an open issue
<TabAtkins> s/in MQs/in MQs, and maybe also on the root element (we'll see)/
<dholbert> emilio (IRC): can we include "...and also ignore all of these when using vw units on the root element, if necessary"
<dholbert> Rossen_ (IRC): objections?
<chrishtr> great! developers will be thrilled
<TabAtkins> And note: explicitly reversing the resolution from 1766
<dholbert> RESOLVED: if overflow:scroll is set on the root element (not propagated from body), account for the default scrollbar width in the size of vw. Also take scrollbar-gutter (and scrollbar-width, the property with "normal" and "thin"?) into account on the root. Ignore all of these in MQs. and also ignore all of these when using vw/vh units on the root element, if necessary
<dholbert> Rossen_ (IRC): look for topics for long call please
<dholbert> TabAtkins (IRC): meeting: Feb 12-14, in MV, on Google Campus
<Rossen_> Zakim, end meeting

bfgeek commented 11 months ago

This resolution might be a little scary for existing sites who are already working around this problem via something like: width: calc(100vw - var(--scrollbar-width)) was this discussed?

bfgeek commented 11 months ago

E.g. https://github.com/search?q=%22calc%28100vw+-+16px%22&type=code

brunoais commented 11 months ago

Why not move that resolution to 100 dvw & 100 dvh

w3c / csswg-drafts

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