[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

--- Comment #3 from Jonathan Deutsch <jonathan at tumult.com> ---

> - The previous keyboard scrolling feels arbitrary.

On macOS, arrow keys most typically correspond to a line scroll:
https://developer.apple.com/documentation/appkit/nsscrollview/1403490-verticallinescroll?language=objc

What represents a line is clearly a bit up for grabs in different views since this is a settable property, but from all my research Safari always scrolled by 40 pixels.  This is anything but arbitrary.

By changing the behavior of the arrow key from scrolling a line to be based on the duration of a key press mapped to an easing function, this has become significantly more arbitrary as human control isn't perfect.  The amount scrolled is dependent on contact time; users can no longer just tap an arrow key to get a fixed amount of scroll.

While I do agree that sometimes the static 40px is too much or too little for a given page that may vary in line height, this change does not really fix that problem anyways, because scroll speed is still independent of any units of content on the page.

> - The previous keyboard scrolling is slow.

As you suspected, the key repeat rate and delay until repeat settings in the System Preferences Keyboard Pref Pane actually would control both the speed and the time before repeat gets enacted.  Now there's no customizability.

It is opinionated (and page-dependent) to say that scrolling is fast or slow.  The new change is fixed, so it is a regression on the axis of at least being able to set the speed that you want.

(IIRC Windows also has an autoscroll feature from pressing the scroll wheel button that allowed for controlling scroll speed as an example of a high-level solution to constant smooth scrolling)


> - The previous keyboard scrolling is janky.
> - The previous keyboard scrolling is jarring.

This change is not the only viable solution. See that Chrome still respects fixed line scroll on arrow taps but it uses a fast animation to make the transition a bit jarring.

Further, a solution could be that one the "key repeat" timing kicks in, the scroll could be continuous but linear to stop immediately when the arrow key is released. (Only a viable solution if all of macOS adopted such a behavior)

> - Rubber banding is good.

I recommend playing with page-up/page-down a bit if you haven't, as even if rubber banding to indicate the end of a document is reasonable, the current behavior is definitely problematic. Page-up/page-down doesn't always rubber band, and when it does it transfers excessive momentum. See my notes above.

=======

> you're taking the way you use Mac for granted

The Mac has been around for 39 years... so yes? What makes macOS special compared to other OSes is that its UI is consistent which means usage is intuitive across a wide range of apps. So when there's inconsistency, it should be treated like a bug.  Exceptions should be exceptional.

> assuming little thought was put into the major rework

I never said this. Of course, even if a lot of thought is put into something doesn't mean it is the optimal solution, or immune to feedback about it. In my career I've been responsible for pulling plenty of features that didn't hold up to real world usage (and yes, in the same org as WebKit :)).

> I strongly disagree that it's an outright "regression" and that there is no merit

I never said there was no merit, but I did outline problems with the new method. I said it was a consistency and accessibility regression.  The linear parts of the smoothness look nice.

=======

Time-based manipulation is common in video games where reflex is often part of the game, but does not make for great UI in the most popular application on macOS.  "Humane" UI is based on providing precision control which amplifies human strengths and diminishes human weaknesses across a broad spectrum of the population. This is why direct manipulation (via trackpad scrolling) works so well, and also why keyboard button presses corresponding to a specific action (line or page scroll) historically work great.

-- 
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/20230401/58a0411b/attachment-0001.htm>