10 ms·

I avoid the use of `type=number` and use `type=text inputmode=numeric` instead. It doesn't come with these arrow buttons which most users don't need anyway for

by nikeee 2y ago

I avoid the use of `type=number` and use `type=text inputmode=numeric` instead. It doesn't come with these arrow buttons which most users don't need anyway for entering numbers. Also the keyboard is better on iOS.

ryncewynd 2y ago
Thanks for the tip wasn't aware of that. I rarely want those arrow buttons for numbers
mananaysiempre 2y ago
> 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.
francislavoie 2y ago
But what's crazy is both of those still don't disallow non-numeric input unless you use JS to reject keystrokes and intercept paste. HTML form validation is so incomplete and limited, every time I look at it I want to scream cause wtf there's so many just totally obvious things we need that don't exist by default and we need to reinvent the wheel. Native date and time inputs are still garbage so every UI framework has to build their own solution.
- Dwedit 2y ago
  I used to write those fancy textboxes that reformatted your input as a phone number as you type, and intercept paste, and all that. But then it turns out that you really do want a free-form text input. Let people paste text in, edit their text freely, then let it validate afterwards. When it validates, then reformat it. For example, text boxes with length limits. These are awful. It messes with your ability to paste something in, then edit it down to the correct length.
  - francislavoie 2y ago
    Nah. Users are too stupid to fix their own inputs in many cases. Seen inputs with zero-width spaces that are invisible which fail validation. User doesn't understand why, complains. Enforcing a character set for certain kinds of inputs is a very good thing.
    - onion2k 2y ago
      In 26 years of web dev, mostly as a frontend person, I've only seen zero width spaces in three situations - pasting from Word - QA testers being through - devs pranking each other The third one is by far the most common. Word is much better these days and I've not seen that happen in a long time. I wish I saw QA test this stuff more often. The idea that it's common enough that you'd break your UX to handle it baffling to me.
      - francislavoie 2y ago
user3939382 2y ago
And yet in both cases the browser insanely casts the data type to string when reading the value.
silvestrov 2y ago
I think type=number is a mistake as it is too generic. It is difficult to get proper validation, UI and error messages. It should be split into: type=integer so the keyboard does not allow anything besides 0-9 type=decimal so the keyboard also allows decimal dot/comma and a fixed number of decimals! type=float which allows for scientific notation, e.g. 1.2e42

by nikeee 2y ago

ryncewynd 2y ago

Thanks for the tip wasn't aware of that. I rarely want those arrow buttons for numbers

mananaysiempre 2y ago

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

francislavoie 2y ago

But what's crazy is both of those still don't disallow non-numeric input unless you use JS to reject keystrokes and intercept paste. HTML form validation is so incomplete and limited, every time I look at it I want to scream cause wtf there's so many just totally obvious things we need that don't exist by default and we need to reinvent the wheel. Native date and time inputs are still garbage so every UI framework has to build their own solution.

Dwedit 2y ago
I used to write those fancy textboxes that reformatted your input as a phone number as you type, and intercept paste, and all that. But then it turns out that you really do want a free-form text input. Let people paste text in, edit their text freely, then let it validate afterwards. When it validates, then reformat it. For example, text boxes with length limits. These are awful. It messes with your ability to paste something in, then edit it down to the correct length.
- francislavoie 2y ago
  Nah. Users are too stupid to fix their own inputs in many cases. Seen inputs with zero-width spaces that are invisible which fail validation. User doesn't understand why, complains. Enforcing a character set for certain kinds of inputs is a very good thing.
  - onion2k 2y ago
    In 26 years of web dev, mostly as a frontend person, I've only seen zero width spaces in three situations - pasting from Word - QA testers being through - devs pranking each other The third one is by far the most common. Word is much better these days and I've not seen that happen in a long time. I wish I saw QA test this stuff more often. The idea that it's common enough that you'd break your UX to handle it baffling to me.
    - francislavoie 2y ago

user3939382 2y ago

And yet in both cases the browser insanely casts the data type to string when reading the value.

silvestrov 2y ago

I think type=number is a mistake as it is too generic. It is difficult to get proper validation, UI and error messages. It should be split into: type=integer so the keyboard does not allow anything besides 0-9 type=decimal so the keyboard also allows decimal dot/comma and a fixed number of decimals! type=float which allows for scientific notation, e.g. 1.2e42