Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This can happen in native UIs as well. I've had to add hysteretic behaviours to prevent the appearance of a scroll bar somehow obviating the need for the scroll bar, so it vanishes and now it needs a scroll bar, repeat as fast as the toolkit event loop allows.


This is why everyone switched to overlay scroll bars. It's also better for performance because you don't need to do layout on a screen worth of content only to realize you need to reserve 16px and do layout again.


Yep, another vote for always scroll bar here.

And an additional complaint about those tiny-thin scroll bars that some idiot-designer though were slick because they so minimally interfere with the rest of 1920px-width display, which also makes them a giant pain-in-the-wrist to click on because the width to make it appear is so thin, and then clicking on the scroller is another challenge whereby it's much easier to accidentally make the scroll bar disappear. Rinse and repeat.

I used to be half-decent at railgun in Q3A, but I now struggle to hit scroll bars. That's a fucking design problem.


I think you misread op, they explained why the overlay scrollbars (aka "tiny-thin scroll bars that some idiot-designer though were slick because they so minimally interfere with the rest of 1920px-width display") are used instead of the old ones that cause layout to trigger again.


Haha, that's because I intended to reply to pasc1878 and hit the wrong reply text.

(because I'm an idiot, not because the reply text shifted on the page)


No the solution is to always show the scroll bar.

Then I don't have to guess if there is anything to scroll.


Happens to me quite often with searching for apps on iOS, it almost seems perfectly timed to switch the icon you’re tapping on right as you’re tapping it




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: