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.

Sign up for GitHub

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

Jump to bottom

[css-overflow] Top layer containing block and scrollbar-gutter #9904

Open
emilio opened this issue Feb 3, 2024 · 7 comments
Open

[css-overflow] Top layer containing block and scrollbar-gutter #9904

emilio opened this issue Feb 3, 2024 · 7 comments
Labels
css-overflow-3 Current Work Needs Edits

Comments

@emilio
Copy link
Collaborator

emilio commented Feb 3, 2024

It seems a bit weird to me that a test-case like this live:

<!doctype html>
<html style="scrollbar-gutter: stable both-edges;">
<div style="width: 80ch; outline: auto;">
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</div>
<dialog id="dialog">
  Woo
</dialog>
<button onclick="this.requestFullscreen()">Go fullscreen</div>
<button onclick="dialog.showModal()">Show modal dialog</div>

Makes the fullscreen element not cover the whole screen / its containing block origin not start at zero, due to the scrollbar gutters.

Maybe the top layer fixed-pos containing block should actually start at zero / ignore scrollbars on the root?

It's a bit weird for regular fixed-pos elements too, for what is worth, but that behavior is consistent with overflow: scroll at least.

cc: @fantasai @tabatkins @aethanyc @dholbert @smfr @nt1m @mfreed7
@css-meeting-bot css-meeting-bot mentioned this issue Feb 13, 2024
Open
@kizu
Copy link
Member

kizu commented Apr 10, 2024

Being able to position stuff above the root scrollbar would be great, as otherwise we have to do the following:

  1. Read the width of the scrollbar.
  2. Apply overflow: hidden to the root alongside adding it back via a padding, so the elements below don't shift (potentially reading the existing padding value to restore it later).
  3. Now we can position something above everything.

So having some way to make an element in the top layer go beyond the default scrollbar will be great, and doing this for fixed position makes sense (as abspos we'd want to be under the default scrollbar).

@astearns astearns moved this to Unsorted in CSSWG June 2024 meeting Jun 3, 2024
@astearns astearns moved this from Unsorted to Wednesday morning in CSSWG June 2024 meeting Jun 3, 2024
@astearns astearns closed this as completed by moving to Wednesday morning in CSSWG June 2024 meeting Jun 3, 2024
@emilio
Copy link
Collaborator Author

emilio commented Jun 3, 2024

@astearns was this closed on purpose?

@astearns
Copy link
Member

astearns commented Jun 3, 2024

No, this is the “helpful” new projects interface doing things I didn’t ask it to do. Thanks for notifying me.

@astearns astearns reopened this Jun 3, 2024
@astearns astearns moved this from Wednesday morning to Wed morning in CSSWG June 2024 meeting Jun 3, 2024
@css-meeting-bot
Copy link
Member

css-meeting-bot commented Jun 11, 2024 •
edited by astearns
Loading

The CSS Working Group just discussed [css-overflow] Top layer containing block and scrollbar-gutter, and agreed to the following:

  • RESOLVED: (top layer or fullscreen) elements with 'position: fixed' cover the scrollbars/gutters
The full IRC log of that discussion <jarhar> emilio: the thing i noticed is that were doing some fixes with how we deal with scrol.bar gutter. it seems very weird that the contiang block for top layer elements and for fixedpos at least, but it does account for scrollbar gutten and that a fullscreen element wouldnt cover the whole screen
<jarhar> emilio: i wonder if someone has context on why we shouldnt do that
<miriam> ack fantasai
<bkardell_> q+
<jarhar> fantasai: i think the main reason why you whouldnt do that is because then you cant scroll. that why it doesnt do that for fixed elements. if you have a top layer thats abspos, you want to scroll to see whats below the fold. if you cover the scrollbar then you have a problem
<jarhar> emilio: the main issue is that fullscreen would usually - why does - i need to test this more
<bkardell_> q-
<bramus> q+
<jarhar> emilio: what youre saying makes sense
<miriam> ack bramus
<jarhar> bramus: i see both things here and what elika said, you dont want to cover up the scrollbar so that people can scroll, but i think thats fine - you make an element fullscren and that element can be scrollable but only if that thing is overflowing and has scrollbar
<jarhar> fantasai: what if its too big? if i make an element fullscreen and give it 150vh
<kizu> q+
<jarhar> bramus: then that element itself will take up the whole screen
<jarhar> bramus: same as if you have a posfixed 500vh you cant reach the bottom contents
<jarhar> iank_: yeah this isnt a new problem people already do this ?? scorllable overflow
<jarhar> fantasai: if the fullscreen element is fixed then arent fullscreen elemtns always fixed
<fantasai> s/then/sure, but/
<jarhar> kizu: i think i wanted to mention a use cases usually involving overlays which look rather weird when you show some modal with an overlay and it doesnt cover the parent scrollbar on the root scroller
<jarhar> kizu: right now fixed element and top layers do not do anything with the root scroller, so yeah i think there are use cases for both
<jarhar> kizu: would be nice to have some way to handle this
<bramus> Also see https://github.com//issues/8099 with a bunch of screenshots.
<jarhar> fantasai: im not sure what the right answer is but i dont want to get into a situation where different sized phones work or dont work
<jarhar> bramus: i think we can make a distinction between posfixed and fullscreen
<jarhar> bramus: its fine if you wrote somethint to become fullscreen but if it should be scorllable and you make a fullscreen element scrollable and then for regular posfixed thats a separate issue
<miriam> q?
<jarhar> TabAtkins: i agree, we should probably ? both cases
<miriam> ack kizu
<jarhar> emilio: we dont suppress scrollbar gutters which is weird
<jarhar> fantasai: the gutter should be whatever the scrollbar is doing, thats for sure
<jarhar> bramus: example, on youtube if you fullscreen you can only scroll down to the comemtns, would be weird if you fulllscreen a video and then in the overlay you need to scroll the video and the coments underneath
<jarhar> bramus: distinguish regular posfixed and fullscreen
<jarhar> fantasai: that makes sense for posfixed but for absolutely positioned not sure
<jarhar> bramus: for posfixed specifically, you coudl also say ok if you have a footer ?? if you have a scrollbar but for that i filed issue 8099 which goes over that and some other issues, so we could discuss there or in another issue
<jarhar> fantasai: we at least have conasensus that fullscreen otp layer fixposed elements should cover all the gutters and scrollbar because we wouldnt be able to scroll them anyway
<fantasai> PROPOSED: top layer / fullscreen elements with 'position: fixed' cover the scrollbars/gutters
<jarhar> miriam: any objections?
<jarhar> RESOLVED: top layer / fullscreen elements with 'position: fixed' cover the scrollbars/gutters
<jarhar> emilio: ??? fullscreen element not fixed
<jarhar> fantasai: its clarified in the resolution. if its position fixed ? top layer fullscreen, if its abspos either one of these, we dont know what hpapens yet
<emilio> https://fullscreen.spec.whatwg.org/#user-agent-level-style-sheet-defaults
<jarhar> emilio: i think we can simplify the resolution and say top layer fixpos because i dont think you can make a fulscreen not fixpos
<jarhar> fantasai: if we change that later, i dont know how
<jarhar> emilio: ok sure
<fantasai> s|top layer / fullscreen|(top layer or fullscreen)|

@chromium-helper chromium-helper mentioned this issue Jun 11, 2024
Closed
@mozilla-apprentice mozilla-apprentice mentioned this issue Jun 11, 2024
Closed
@yisibl
Copy link
Contributor

yisibl commented Jun 12, 2024

RESOLVED: (top layer or fullscreen) elements with 'position: fixed' cover the scrollbars/gutters

I'm confused by the resolution here, which doesn't solve the problem with the position: fixed element.

The <dialog> element doesn't create the top layer when .show() is called, and when the author can set it to position: fixed, the page is offset.

See demo https://codepen.io/yisi/pen/ExzwMgP?editors=0010

scrollbar-gutter-bug.mp4

Firefox implements it well and doesn't have problems with offsets.

This has been a long-standing user request, with 21 votes in Chrome's bug.

@mozilla-apprentice mozilla-apprentice mentioned this issue Jun 12, 2024
Closed
@kizu
Copy link
Member

kizu commented Jun 12, 2024

@yisibl Doing this for any fixed element can result in a loss of the scrollbar functionality, where some pre-existing fixed element could go over the scrollbar, making it inaccessible.

Dialog case looks like close to what we want to achieve with the issue: I agree that we'd want it to be over the scrollbars, but we probably need to handle this specific case separately, as we can't make every fixed element go over the root scrollbar-gutter.

@bramus bramus mentioned this issue Jun 12, 2024
Open
@jantimon
Copy link

Here is a Chrome bug which tries to describe exactly what @kizu said

Adding scrollbar-gutter: stable; breaks the scroll-bars:

ScrollGutterStable.2.mp4

@github-project-automation github-project-automation bot moved this to unsorted FTF in Feb 2024 Agenda Aug 26, 2024
@yisibl yisibl mentioned this issue Aug 30, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-overflow-3 Current Work Needs Edits
Projects
CSSWG June 2024 meeting
Status: Tuesday afternoon
Feb 2024 Agenda
Status: unsorted FTF
Milestone
No milestone
Development

No branches or pull requests
7 participants
@kizu @fantasai @emilio @astearns @yisibl @jantimon @css-meeting-bot