- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Nov 2023 18:03:49 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <chrishtr> ah fixed<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/5254<br> <dholbert> TabAtkins (IRC): this is an issue that crosses a few related issues<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/1766<br> <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<br> <dholbert> TabAtkins (IRC): Obviously overflow:auto is cyclic and not usable<br> <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<br> <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<br> <dholbert> TabAtkins (IRC): But we need to be consistent. Want scrollbar-gutter and forced scrollbars to behave the same<br> <dholbert> TabAtkins (IRC): Can we revert the old issue? and have forced scrollbars on the root scroller subtracted when resolving 100vw,<br> <emilio> q+<br> <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<br> <dholbert> TabAtkins (IRC): we'd subtract the default width of scrollbars<br> <florian> q+<br> <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<br> <Rossen_> ack emilio<br> <dholbert> emilio (IRC): two thigns. first: do you recall what's the status of propagation of scrollbar-gutter to the root<br> <dholbert> TabAtkins (IRC): not sure. I suspect we don't do additional propagation. try not to do propagation on new things<br> <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<br> <dholbert> emilio (IRC): in general seems like it'd be nice to fix this. I agree it's unfortunate that it doesn't work<br> <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"<br> <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<br> <chrishtr> https://drafts.csswg.org/css-overflow/#scrollbar-gutter-property<br> <dholbert> emilio (IRC): style container queries, etc. stuff gets messy real fast<br> <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<br> <Rossen_> ack florian<br> <dholbert> TabAtkins (IRC): agreed. It'd work the same as font-size where it takes some initial value that disregards styles on the page<br> <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?<br> <dholbert> emilio (IRC): main difference between scrollbar-gutter and overflow is the propagation stuff, impl-complexity wise<br> <dholbert> emilio (IRC): it was messy when gecko was trying to account for this with overflow propagation from body<br> <TabAtkins> "However, unlike the overflow property, the user agent must not propagate scrollbar-gutter from the HTML body element."<br> <TabAtkins> So yeah, overflow-gutter doesn't propagate<br> <emilio> great<br> <bramus> q+<br> <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<br> <fantasai> +1 bramus<br> <dholbert> bramus (IRC): I want to underline what tab said; authors are really bitten by this. Longstanding problem, would be so helpful for authors<br> <Rossen_> ack bramus<br> <Rossen_> ack fantasai<br> <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?<br> <dholbert> fantasai (IRC): i.e. we don't account for scrollbars propagated from body to root<br> <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.<br> <chrishtr> q+<br> <dholbert> emilio (IRC): and should this account for scrollbar-width on the root (not the webkit scrollbar pseudos)<br> <Rossen_> ack chrishtr<br> <dholbert> TabAtkins (IRC): my proposed rsln agrees with that, yeah<br> <dholbert> chrishtr (IRC): (talks through resolution)<br> <dholbert> chrishtr (IRC): this would apply to iframes?<br> <dholbert> TabAtkins (IRC): correct<br> <emilio> q+<br> <dholbert> bramus (IRC): not sure about scrollbar-gutter:stable scenario; then you reserve space on left edge as well<br> <dholbert> bramus (IRC): then you might get an overlay that doesn't paint on the left side despite 100vw<br> <dholbert> TabAtkins (IRC): that's what you're asking for if you use that value<br> <dholbert> florian (IRC): yup, that's what it does<br> <bramus> Screenshot: https://user-images.githubusercontent.com/213073/202724538-b20f14bd-489e-4e6f-a9df-519d4a11e617.png<br> <dholbert> florian (IRC): if you use "stable both", that is<br> <dholbert> chrishtr (IRC): but if you don't use "both", it just goes on the side where it normally appears<br> <dholbert> bramus (IRC): see screenshot. Then you can't paint something in the left there? your overlay won't be entirely overaying<br> <dholbert> TabAtkins (IRC): That's because you're explicitly asking for that space. width:100% won't fill that space either<br> <dholbert> TabAtkins (IRC): there are other ways to handle this.<br> <dholbert> emilio (IRC): fixed-pos would handle this too<br> <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<br> <dholbert> fantasai (IRC): you might need to set scrollbar-gutter on a more inner element to get that behavior<br> <chrishtr> or we could add another unit in the future if this situation is common<br> <TabAtkins> seriously, this is an explicit request from the author to not let them use that space<br> <miriam> q+<br> <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<br> <emilio> +1 TabAtkins<br> <dholbert> bramus (IRC): maybe this is an edge case. I'm fine if we couldn't draw in that area<br> <emilio> q?<br> <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<br> <Rossen_> ack emilio<br> <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<br> <dholbert> emilio (IRC): do we need viewport units, when used on the root, not to account for the scrollbars?<br> <dholbert> emilio (IRC): generally we wouldn't need this restriction, with new fancy calc and stuff, it seems like it might not be needed?<br> <dholbert> emilio (IRC): similar to root em units and root line height; we avoid them introducing a dependency...<br> <Rossen_> q?<br> <dholbert> TabAtkins (IRC): giving access to full viewport width, ignoring scrollbars<br> <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<br> <Rossen_> ack miriam<br> <dholbert> miriam (IRC): some truth to if you set 'stable' you're asking not to use that space<br> <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<br> <dholbert> florian (IRC): so the variable would be the gutter size? right<br> <dholbert> bramus (IRC): you could use it to see if the scrollbar is there... an automatic solution here is way better<br> <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'<br> <bramus> +1 to what tab just said.<br> <miriam> +1<br> <dholbert> TabAtkins (IRC): can we resolve here and handle this corner case in another issue<br> <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.<br> <dholbert> fantasai (IRC): as an issue in the scrollbar spec maybe<br> <dholbert> Rossen_ (IRC): and the 'both always' issue will be an open issue<br> <TabAtkins> s/in MQs/in MQs, and maybe also on the root element (we'll see)/<br> <dholbert> emilio (IRC): can we include "...and also ignore all of these when using vw units on the root element, if necessary"<br> <dholbert> Rossen_ (IRC): objections?<br> <chrishtr> great! developers will be thrilled<br> <TabAtkins> And note: explicitly reversing the resolution from 1766<br> <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<br> <dholbert> Rossen_ (IRC): look for topics for long call please<br> <dholbert> TabAtkins (IRC): meeting: Feb 12-14, in MV, on Google Campus<br> <Rossen_> Zakim, end meeting<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-1832443514 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 November 2023 18:03:52 UTC