[Webkit-unassigned] [Bug 254724] Safari 16.4 Regression: Keyboard-based scrolling behavior is nonsensical and un-mac-like

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=254724

Quasar Nebula <qznebula at protonmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qznebula at protonmail.com

--- Comment #2 from Quasar Nebula <qznebula at protonmail.com> ---
I disagree. At slightly incendiary risk, I think you're taking the way you use Mac for granted, and assuming little thought was put into the major rework of such an essential control as keyboard scrolling.

Some counter-arguments:

- The previous keyboard scrolling feels arbitrary. The only way for me to understand how far I'm going to scroll when I press up or down is to memorize it. If I don't like how far one tap scrolls, well, tough luck! I also don't know where that distance comes from. In text- or row-based environments (such as Terminal or Finder), it's obvious: one key press is one line or row. But on the web, line height is totally arbitrary and generally customized for each website. It doesn't seem to reflect any inherent unit besides, you know, this is how far it goes, and you'd better ingrain that into your silly noggin. That's OK if you spend the vast majority of your scrolling time using the keyboard, but most people don't, and scrolling by one "line" (however long that is) can just feel unintuitive and arbitrary.

- The previous keyboard scrolling is slow. There's a delay before I start scrolling multiple lines, so either I sluggishly wait, one "line" happens to be enough, or I spam the down or up arrow key. That's not good UX. Moreover, once the wait is done, it's *still* arbitrary how quickly I'm scrolling (possibly based on the key repeat speed but I don't recall 100%, and it seems odd to tie two largely unrelated actions - inputting the same key multiple times vs. scrolling a view - together...).

- The previous keyboard scrolling is janky. Because I don't have control over the speed, and it generally scrolls in arbitrary increments, I don't have a good sense of where I'm going to end up when I let go of the scroll key (besides "stop after the current scroll increment finishes about, like, roughly here"). No velocity means I better like one of the points where it's going to stop scrolling, because finer adjustments can only be made with mouse or trackpad.

- The previous keyboard scrolling is jarring. Ramped scrolling means I'm eased into the scroll and don't suddenly see the whole page shift up, again, an arbitrary amount outside of my control. I basically have to reassess my gatherings because I don't know where I just ended up, and because I either get a sharp one-tap scroll or incremental step-wise scrolling which may reveal more or less than I'm looking for at the bottom/top of the view, without an intuitive way to make adjustments. Ease in/out smooths the motion and lets me quickly adjust by pressing the key a little longer.

- Rubber banding is good. It's jarring to hit the bottom and feel like you're slamming the page into a wall. Yes, it's the end of the scroll range, but rubber banding is just as intuitive a way as representing that as suddenly stopping the entire scroll.

I do feel scrolling should be customizable - yes! including an option to revert to the long-standing previous behavior! (I agree with your accessibility concerns.) - but I strongly disagree that it's an outright "regression" and that there is no merit to the new scrolling method.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230330/28ed7d31/attachment.htm>