Great! Very helpful. How about reversing its behaviour: start out at fine sliding (1/32) and make it courser (up to 1) when increasing the vertical distance. Also, moving vertical downward keeps it at 1. Would expect it to behave similar to moving upward. Handy when slider is at top of page.

Great suggestions. I like it. I thInk I’ll apply both. Thanks!

When there are multiple inputs on the page (e.g., your Zooming Gray–Scott notebook), on Safari, it seems that the first FineRange you drag “captures” the input, such that you can’t interact with other sliders. All the dragging gets redirected to the first FineRange, instead of dragging the slider you clicked on.

Thanks for pointing this out. I rewrote it using pointerup/down/move and setPointerCapture, and it exhibits the same issue in which it won't release control of the slider. After some work, my plan, I think, is to user-agent detect desktop safari and simply return early with a call to Range. This seems like a bug to me, but it's not unlikely that I'm simply using it incorrectly: https://observablehq.com/d/2cc20afae81903cc

Wait, I maybe got it… you also have to preventdefault where you don't in Chrome… now just a couple more browsers to debug once more… 😩

Okay, I think it's now fixed in Safari. Pointer capture works differently with respect to whether it captures in the whole window or not, but I'm willing to accept it.

@martien It seems like perhaps the problem you're getting at is that it's hard to start dragging the slider without making accidental large changes. Instead of reversing it so that it starts small and moves toward larger changes, I've added a feature so that you can use the shift key to divide the increment by 32. This way, if you don't want to perturb it, you can hold the shift key when you start interacting so that accidental changes will be smaller.

Works great! Thanks for fixing. 👍

The papers from that twitter comment are dgp.toronto.edu/~ravin/papers/uist2005_zliding.pdf and insitu.lri.fr/~appert/website/papers/OrthoZoom.pdf