[dougk16]

Thanks for the tips. I opted for that .content_scroller because when the whole body was scrollable the side menu was really jumpy and glitchy on the Android phones I tested on. It also was doing weird things with the address bar, hiding and showing it in a seemingly random way.

I think you mean `position: fixed` rather than `display: fix` right? In which case the side bar class .side_bar_column already has that. Unless you mean a different class/element?

Anyway looks like I'll have to attack this scroll issue a little more systematically. People usually complain about scrolljacking. I'm doing the absolute opposite, trying to let browsers do their thing themselves, but apparently that's bad too lol. Can't win.

[frosted-flakes]

Yeah, I meant `position: fixed` (brainfart—I knew it didn't sound quite right). But it shouldn't have any issues at all on Android. It's how most websites do sticky headers, and I've never seen any glitching.

In any case, there are a lot of reasons for scrolling the main document rather than having a subscroller, including:

1. Auto-hiding the address bar when scrolling down on mobile (it's not weird—all browsers do it) and pull-to-refresh in browsers that have it

2. Better accessibility because it doesn't break the PageUp/PageDown keys

3. Momentum scrolling

4. Better scrolling performance (higher framerate) because browsers optimise main document scrolling over subscrolling

5. Support for #fragment linking

6. etc.[0]

[0] https://nolanlawson.com/2018/11/18/scrolling-the-main-docume...

[dougk16]

The auto-hiding address bar on my 2 Android phones was straight-up glitchy with document scrolling, not the "convenience" behavior. Even other sites on my phone were fine. It was just my site, and I believe I tracked it down the the fixed side bar. When I get rid of that the scrolling was fine.

All your points have really convinced me to give document scrolling another go though. Thanks for the list and the link.