Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-values-4]? A way to explicitly account for scrollbar gutters #9654

Open
tabatkins opened this issue Nov 29, 2023 · 1 comment
Open

[css-values-4]? A way to explicitly account for scrollbar gutters #9654

tabatkins opened this issue Nov 29, 2023 · 1 comment
Labels
css-values-4 Current Work

Comments

@tabatkins
Copy link
Member

In #6026, we just resolved to remove the width of root scrollbars from the size of viewport units when overflow: scroll (or similar things, like scrollbar-gutter: always) were specified on the root.

In the discussion, @bramus brought up the issue of scrollbar-gutter: always both-sides;, and whether (1) we should subtract the opposite gutter from the viewport units as well. (2) If we do, is there any way to make something the size of the entire visible viewport, ignoring the gutter?

For (1) I think the answer is yes, we should subtract the size of both gutters there; ignoring the cyclic potential of overflow: auto, the viewport units should basically always be equivalent to %s on the root.

For (2), in most cases you don't need to worry about it. If it's a positioned element, left: 0; right: 0; will already work as desired, filling the whole space without caring about the gutter (but paying attention to the actual scrollbar, if needed). (iirc; the computer I'm typing this on uses overlay scrollbars so I can't check easily)

But if you, say, wanted a full-bleed header where it's an in-flow element that is going to use a negative margin to pull itself into the reserved gutter space, there is indeed currently no way to accurately do this right now; you can guess at the scrollbar size (and be generally correct if you just say 16px), but you might be wrong.

@mirisuzanne (and others, in the past) suggested an env() for the default scrollbar width/gutter size, and that makes sense to me; it can respond to the same inputs that the gutter itself does (taking 'scrollbar-width' into account).

This doesn't quite solve all problems, tho - if you want it to full-bleed into the gutter on the scrollbar side when there isn't a scrollbar, you'd need some way to detect that there's a scrollbar. I think having an env() that responds to this would introduce a cyclic dependency? cq units accomplish this, as seen in several comments on #6026, but they invoke heavier-weight machinery than we probably want to do here. This might be a step too far.

@tabatkins tabatkins added the css-values-4 Current Work label Nov 29, 2023
@bramus
Copy link
Contributor

bramus commented Nov 30, 2023

For (2), in most cases you don't need to worry about it. If it's a positioned element, left: 0; right: 0; will already work as desired, filling the whole space without caring about the gutter (but paying attention to the actual scrollbar, if needed). (iirc; the computer I'm typing this on uses overlay scrollbars so I can't check easily)

I’ve tested this before in #8099 and this won’t work as it is right now:

  • In Firefox things can get positioned in the left gutter when using both-edges but they are not painted
  • In Chrome the 0,0 origin is offset by the left gutter

Those could be implementation bugs, though.


@mirisuzanne (and others, in the past) suggested an env() for the default scrollbar width/gutter size

This would also require being able to detect what type of scrollbars are being used (or when forcing them via ::webkit-scrollbar). Only when classic scrollbars are used along with both-edges would one need to subtract that value.

Also see https://gist.github.com/bramus/bcca5788d8ced82837180b7a15760c84 related to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-values-4 Current Work
Projects
None yet
Development

No branches or pull requests

2 participants