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

Sidebar double scrollbar #1899

Closed
afercia opened this issue Jul 14, 2017 · 4 comments · Fixed by #2868
Closed

Sidebar double scrollbar #1899

afercia opened this issue Jul 14, 2017 · 4 comments · Fixed by #2868
Assignees
Labels
Browser Issues Issues or PRs that are related to browser specific problems General Interface Parts of the UI which don't fall neatly under other labels. [Type] Bug An existing feature does not function as intended
Milestone

Comments

@afercia
Copy link
Contributor

afercia commented Jul 14, 2017

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.

scrollbars

Maybe worth considering alternative solutions to overflow: auto;.

@afercia afercia added General Interface Parts of the UI which don't fall neatly under other labels. [Type] Bug An existing feature does not function as intended labels Jul 27, 2017
@jasmussen
Copy link
Contributor

Also this:

screen shot 2017-07-28 at 09 15 29

Another solution is to double down on overflow: auto;, so that the html element doesn't scroll, but indeed the main editable field scrolls instead. This could also help solve issues with position: fixed;, as well as scroll bleed (see #656), which is extra annoying on mobile.

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?

jasmussen added a commit that referenced this issue Jul 28, 2017
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.
@aduth aduth marked this as a duplicate of #2059 Jul 28, 2017
@afercia
Copy link
Contributor Author

afercia commented Aug 3, 2017

Update: in Firefox and Edge on Windows, 1366x768 display I can see now 3 scrollbars:

screenshot 27

@jasmussen
Copy link
Contributor

I've occasionally seen a double scrollbar even in Safari. That is, it feels like some of the negative margin on the component-panel combined with an overflow somewhere might cause an extra scrollbar that shouldn't be there. So I think if we fix that one, we should be back down to two.

@karmatosed
Copy link
Member

This seems to relate to #2723. Closing that one so we have everything in one place.

@karmatosed karmatosed added the Browser Issues Issues or PRs that are related to browser specific problems label Sep 25, 2017
@karmatosed karmatosed added this to the Beta 1.4 milestone Sep 25, 2017
@karmatosed karmatosed modified the milestones: Beta 1.4, Beta 1.3 Oct 3, 2017
@aduth aduth self-assigned this Oct 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Browser Issues Issues or PRs that are related to browser specific problems General Interface Parts of the UI which don't fall neatly under other labels. [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants