A couple points about why rubber banding is bad with the keyboard: - it doesn't happen if you are just one key stroke away from the bottom, so it is inconsistent - it is disrespectful of my time to show your animation unnecessarily - it is very large so the eye has to do a lot to try to track it and then adjust Key strokes don't have momentum like overshoot from two-finger scrolling.

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.

> - 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.

<rdar://problem/107538186>