-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Sidebar double scrollbar #1899
Comments
Also this: Another solution is to double down on The reason we didn't approach it this way from the start, is that in past versions of iOS, scrolling anything but the HTML element had really weird quirks. But this seems to have been fixed in recent versions of mobile Safari. CC: @mtias — what do you think? |
This is an experiment. Instead of scrolling the `body` element, it scrolls the editor and sidebar individually. This has a number of benefits: 1. It fixes scroll bleed entirely (see #656) Scroll bleed is when you scroll to the end of an individually scrolling container, and start scrolling the content below it. Scroll bleed is particularly a problem on mobile, and if we can refactor to use this type of layout, we can have a vastly improved mobile experience in one fell swoop. 2. It drastically simplifies fixed position elements. The header, for example, no longer has to be fixed position at all. It can just sit there. This also has benefits on the responsive stuff, since we now get this for free, as opposed to have to make advanced edgecases for every `left` and `right` value. 3. It fixes the issue of "double scrollbars" (see ##1899) Because the scrollbar is now contextual to the element being scrolled, everything visually works as expected. There are downsides too. We initially avoided this approach because scrolling on mobile just couldn't be made to behave in a good way. For example, on an iPhone you could "drag down" (to scroll) on the fixed top bar, and scroll the _page itself_, and invoke that overflow bounce that iOS is famous for, looking jarring. The expected behavior here would be that dragging on the fixed top bar wouldn't do anything at all, since it's not part of a scrollable element. However recent changes in mobile safari appear to have fixed this, that's why it's seems worth revisiting. I'm also unsure of what possible accesibility implications are of this, so @afercia please chime in if you have thoughts here. One final downside is that if you are viewing the editor in an iPad in landscape mode, and expect to be able to scroll the page by dragging on the left hand navigation menu (the one with Dashboard, Posts, Media, Pages, etc.) you won't be scrolling the page. Because again, this is not a scrollable element anymore. It feels like there are a ton of upsides to this approach, but it needs a _lot_ of testing, so don't anyone celebrate. But it seems really really worth trying.
I've occasionally seen a double scrollbar even in Safari. That is, it feels like some of the negative margin on the |
This seems to relate to #2723. Closing that one so we have everything in one place. |
In some operating systems, scrollbars aren't "overlaid" on the screen but they do take space. This happens also on Windows 10, where all browsers display a double scrollbar when the scrollbar height exceed the viewport height. That's likely going to happen when opening the categories panel for example (since there are usually lots of categories) and also on small screens.
Worth noting the double scrollbar is there also on macOS, you just can't see it most of the times. Just resize your browser window to make it smaller and open some panels in the sidebar.
Maybe worth considering alternative solutions to
overflow: auto;
.The text was updated successfully, but these errors were encountered: