bramus
commented
10 months ago 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 https://github.com/w3c/csswg-drafts/issues/8099 and this won’t work as it is right now:
- In Firefox things can get positioned in the left gutter when using
both-edgesbut 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.
In #6026, we just resolved to remove the width of root scrollbars from the size of viewport units when
overflow: scroll(or similar things, likescrollbar-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.