3 ms·

> these arrow buttons A spinner control, that is. Spinners always puzzled me, to be honest. There is obviously a need for a compact numeric input control that

> these arrow buttons A spinner control, that is. Spinners always puzzled me, to be honest. There is obviously a need for a compact numeric input control that both displays the exact value and allows rough changes using the mouse. Witness knobs in DAWs—which don’t actually work the way you’d expect from their appearance, you’re supposed to grab and then drag in a linear fashion, possibly ending outside the knob’s screen bounds. Or consider the weird input thing Darktable uses—which at least doesn’t mislead you with false skeuomorphism, but takes a bit to figure out. Then there are the inputs used for color grading in DaVinci Resolve. And so on. And all of them are nonobvious. Spinners are obvious, but they are also needlessly fiddly to use with the mouse, and neither do they provide the at-a-glance readability of knobs et al. I feel like humanity just hasn’t solved compact numeric inputs yet.

lelanthran 2y ago
> Spinners are obvious, but they are also needlessly fiddly to use with the mouse I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused. An even better improvement would be having the `<input type='range'>` element actually display the value as it changed, and allow the user to set that value directly (say, by typing it in). Right now, range is useless because the user cannot tell what is selected. The developer has to add in extra JS magic to let the user set range to an exact value, or to show the user the value they have chosen. If `range` is improved in this way, then spinners are redundant and can be ignored.
- LegionMammal978 2y ago
  > I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused. Firefox did that for number inputs for a long time, until very recently. They switched it off in Firefox 130 because people kept inadvertently changing values in forms while scrolling through them [0]. Personally, I've set the about:config option to reenable it since I've found it useful in certain interfaces, though I can't imagine it's much longer for this world. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1741469 https://bugzilla.mozilla.org/show_bug.cgi?id=1741469
  - account42 2y ago
    Isn't this same issue already solved for other scrollable elements? Scroll should only affect the individual element if the mouse was over that element when you started scrolling. I guess the room for unwanted consequences is a bit bigger when the scrolling controlls the value instead of just the viewport.
    - LegionMammal978 2y ago
      That is how it worked, but people still found it problematic. E.g., from one of the comments on the issue: > In step (3) here, if you do several mousewheel-spins while also subtly moving the mouse (just from placing your hand on it), it's quite easy/possible for the first spin to inadvertently change the value that you just entered (since step 1 had left the cursor hovering the input field, so that's where it starts), and then for the subsequent mousewheel-spins to successfully scroll the page. This can mean you change the number you just entered without noticing (and also without it being "in the middle of an existing scroll action", hence my note that this suggested mitigation wouldn't necessarily help). The cause being that people don't look at where their cursor is before they start scrolling, and don't look at the value since they've finished entering it.
    - mjevans 2y ago
      That's almost correct. I generally agree with hover == focus as a Window Manager level thing, but for document inputs within an application I still prefer required user interaction to set the focus location. E.G. a click, a tab, just move the line forward. The correct context model is to not select an element for scrolling until it has been made the active element, and that UI element SHOULD have some sort of embellishment to make it obvious that's the focus.

lelanthran 2y ago

> Spinners are obvious, but they are also needlessly fiddly to use with the mouse I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused. An even better improvement would be having the `<input type='range'>` element actually display the value as it changed, and allow the user to set that value directly (say, by typing it in). Right now, range is useless because the user cannot tell what is selected. The developer has to add in extra JS magic to let the user set range to an exact value, or to show the user the value they have chosen. If `range` is improved in this way, then spinners are redundant and can be ignored.

LegionMammal978 2y ago
> I think that a quick improvement would be to let the mouse wheel "spin" the number up/down when the input element is focused. Firefox did that for number inputs for a long time, until very recently. They switched it off in Firefox 130 because people kept inadvertently changing values in forms while scrolling through them [0]. Personally, I've set the about:config option to reenable it since I've found it useful in certain interfaces, though I can't imagine it's much longer for this world. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1741469 https://bugzilla.mozilla.org/show_bug.cgi?id=1741469
- account42 2y ago
  Isn't this same issue already solved for other scrollable elements? Scroll should only affect the individual element if the mouse was over that element when you started scrolling. I guess the room for unwanted consequences is a bit bigger when the scrolling controlls the value instead of just the viewport.
  - LegionMammal978 2y ago
    That is how it worked, but people still found it problematic. E.g., from one of the comments on the issue: > In step (3) here, if you do several mousewheel-spins while also subtly moving the mouse (just from placing your hand on it), it's quite easy/possible for the first spin to inadvertently change the value that you just entered (since step 1 had left the cursor hovering the input field, so that's where it starts), and then for the subsequent mousewheel-spins to successfully scroll the page. This can mean you change the number you just entered without noticing (and also without it being "in the middle of an existing scroll action", hence my note that this suggested mitigation wouldn't necessarily help). The cause being that people don't look at where their cursor is before they start scrolling, and don't look at the value since they've finished entering it.
  - mjevans 2y ago
    That's almost correct. I generally agree with hover == focus as a Window Manager level thing, but for document inputs within an application I still prefer required user interaction to set the focus location. E.G. a click, a tab, just move the line forward. The correct context model is to not select an element for scrolling until it has been made the active element, and that UI element SHOULD have some sort of embellishment to make it obvious that's the focus.