Hacker News new | past | comments | ask | show | jobs | submit login

Because if you have touchscreens you can use two-finger gestures, and if you're on a mouse you'll have no issue targeting a thin widget. It makes a lot of sense from that POV.



If the thin widget is directly against the edge of the viewport, maybe.

If it's literally anywhere else on the screen, then no, Fitts's Law applies, and it's a bad target. It has height but no width.

This is especially true for those with motor or visual handicaps, or both.

It's damned near unusable even with very modest levels of distraction or other factors, e.g., using a device as a passenger on a moving vehicle, as with a boat, train, or airplane.


> If the thin widget is directly against the edge of the viewport, maybe.

It is. Visually there's space between the scroll handle and the window edge, but if you actually point the cursor in that space it'll highlight the handle.


This feels pretty weird on macOS in a way I never realized, because I thought you were wrong but you're actually right -- you can slam the cursor right against the right edge of the screen and the scroll handle lights up and you can click and drag it if you start an up/down mouse motion -- but the cursor changes to the left-right resize one and if you start by moving left/right it resizes the window instead and the scrolling motion is cancelled.

I guess thinking about it this is a very reasonable compromise, but it feels weird to start scrolling up and down with a cursor that shows a left-right arrow and that is technically pointing outside of the scroll bar.


That may work on MacOS.

It ... doesn't work for any Linux desktop, most especially those using Focus Follows Mouse (certainly for strict, often for lazy) policy.

Though that's useful to know.


On KDE the cursor shape aspect doesn't match macOS (in the sense that if it's showing a resize cursor, it'll resize the window, no matter what), but per my comment further up the chain it'll absolutely work if it's just a normal cursor but between the handle and the edge of the window. Tried it on both Firefox and Konsole (which are subtly different due to Gtk v. Qt quirkiness but have the same behavior).

Though I'm using click-to-focus, not focus-follows-mouse, so YMMV.


NB: Trying on MacOS now, if I'm on a browser page in Firefox positioned within the display (other than at the right edge) and hit the right edge of the screen, the scrollbar does NOT in fact light up or activate.

If I have a window positioned to the right edge of the screen ... the scrollbar is draggable only when my mouse pointer is positioned directly over the scroll grabber. Not when pushed to the edge of the screen.

This seems to apply generally for windows best I can tell.

TL;DR: The behaviour you describe is not at all what I see.


This is a Firefox bug which has been open for years and years with no fix. Try it with native apps like Finder or Terminal. Absolutely works for me on Big Sur.


I'm pretty sure boats trains and airplanes are all vehicles.


It would -- but it's set so thin by default that I have trouble targeting it with my mouse!


For a fullscreen window it would be nice if moving the mouse all the way to the right edge was sufficient to target the scrollbar, but that doesn't work in Chrome on my mac


My browser is rarely against the RH side of my display, or even on the RH sie of my screen.

My preferred informational / programming layout is browser on left, terminal on right.

And in any multi-window layout, any window not aligned with the right-hand display border remains difficult to target.


You can also use the scroll wheel of the mouse just fine, or the TouchPad scroll gesture. I don't even remember that the scrollbars are invisible anymore


Some touchpads also support gesture scrolling.




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

Search: