Closed smfr closed 3 years ago
Safari and Chrome don't allow scrolling. Firefox kinda does on the first scroll, but then it becomes non-scrollable.
In all major browsers (I'm pretty sure) visibility: hidden
makes an element non-focusable. If it isn't focusable, it shouldn't be scrollable. (Or conversely, if it is scrollable, it should be focusable.)
It should still be scrollable via script though, right?
What thoughts do you folks have for how this relates to an overflowing scroll container with pointer-events: none
while a descendant has pointer-events: auto
set? Treated the same as the visibility
example linked above?
Case for pointer-events
version of scenario, currently unique behavior in each blink/webkit/gecko https://output.jsbin.com/talomas/quiet
See also https://bugs.webkit.org/show_bug.cgi?id=183870 (guessing @smfr filed this as a response)
Or conversely, if it is scrollable, it should be focusable.
@AmeliaBR can you elaborate on what you mean here? Kinda confused in a chicken/egg way, but maybe I’ll understand better from how you define “scrollable”?
can you elaborate on what you mean here?
I mean, if mouse-wheel users can scroll it, then keyboard users should be able to scroll it. Which means there must be a keyboard-only way to get focus on the scroll container or its contents. (Now, some browsers aren't very good about making scrollable containers focusable by default even if they are visible, but the standard solution is to give the container tabindex="0"
. In this case, you'd need to make the visible child focusable, but at the same time something non-interactive that will bubble keyboard events up to the container.)
Of course, even that wouldn't guarantee accessibility for all users: some users still rely on grabbing the visible scoller in order to scroll. (I do this all the time myself for small widgets on screen where I can't easily get keyboard focus to the correct place, since touch gesture scrolling on my trackpad is very unreliable.) To make scrolling work for this situation, the scrollbar itself would need to be rendered separate from the rest of the box.
In sum: If the hidden scroll container is "scrollable" it needs to be scrollable with every input method that normally works for visible scroll containers.
It should still be scrollable via script though, right?
Sure…? Do we have any other ways to create a scrollable container with user-scrolling disabled?
Safari and Chrome don't allow scrolling. Firefox kinda does on the first scroll, but then it becomes non-scrollable.
Also, @smfr, this is not entirely true. Webkit does allow scrolling, if it bubbles from nested scroll containers. And gecko behaves the same regarding nested scroll containers. It also always allows gestural scrolling from atop the scrollbar and from grabbing the scrollbar when manipulating pointer-events
. And all browsers allow scrolling when focused and pressing the (shift+)spacebar.
Chrome don't allow scrolling.
@smfr from the demo that I originally filed, https://codepen.io/anon/pen/EBzmWv, I can scroll whether visibility
or pointer-events
manipulation on the scroll container. When my mouse is atop the visibility: visible
white blocks, I can scroll them up into view. When my mouse is in the area atop the scroll container, but not atop the white blocks, I cannot scroll the visibility: hidden
scroll container.
Does this case exhibit different behavior in Chrome 77.0.3847.0 (Official Build) canary (64-bit) on your computer?
Sure…? Do we have any other ways to create a scrollable container with user-scrolling disabled?
overflow:hidden is exactly that :)
I agree that programmatic/bubbled scrolling in such containers should continue to work.
from the demo that I originally filed, https://codepen.io/anon/pen/EBzmWv
That's an overly complicated testcase. Can you simplify it?
@smfr Simplified, but it’s still really the same and it still is scrollable in blink (as well as gecko 70.0a1)
https://codepen.io/anon/pen/NZZvgY
I think it has to do with the fact that there is a scroll container underneath the hidden container.
Can you chime in with your thoughts on pointer-events
though? If you’d want it treated differently? And why or why not?
The CSS Working Group just discussed Should a visibility:hidden overflow:scroll be scrollable?
, and agreed to the following:
RESOLVED: Align behavior of visibility:hidden with visible descendants for overflow:scroll to behave the same as overflow:hidden
Convo was a bit rushed, so I'd like to confirm our resolution.
We want a visibility:hidden element to act like overflow:hidden wrt scrolling, regardless of its overflow value, right? So:
Is this regardless of overflow value, or does it just apply to all the "scrollable" overflow values? (Hidden, auto, scroll) I assume an "overflow:visible" element remains unscrollable, as would the clip values?
Never a scrollbar.
I think there should be a scrollbar, just not visible (this is observable since having a scrollbar on non-Mac platforms changes the available space).
We want a visibility:hidden element to act like overflow:hidden wrt scrolling, regardless of its overflow value, right? So:
- Never a scrollbar.
No visible scrollbar, but layout happens as it would without visibility:hidden (i.e. a present non-overflow scrollbar will take space).
- No scroll bubbling - if you mousewheel on a visible descendant, it doesn't scroll the hidden container.
Agreed.
- Script-based scrolling still works.
Agreed.
Is this regardless of overflow value, or does it just apply to all the "scrollable" overflow values? (Hidden, auto, scroll) I assume an "overflow:visible" element remains unscrollable, as would the clip values?
overflow:visible and clip would remain unscrollable, yes. I don't think there's any behavior change for overflow:hidden. Auto/scroll would behave as above.
Alright. So this is done now, but there's a follow up in #6355.
visibility:visible on a child can make content visible inside a visibility:hidden ancestor. If the ancestor chain to which visibility:hidden applies contains overflow:scroll, and the scrollable content contains a visibility:visible element, should user interaction be able to trigger scrolling, and thus cause the visible element to get scrolled?
https://codepen.io/smfr/pen/orRLqN