6 ms·

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

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
      "Break your UX" is a vast exaggeration. I'm not talking about phone number fields, to be clear. I'm talking about like numeric amounts, with maybe a negative or decimal point. It's literally just [0-9\.-] but that still requires JS to limit inputs to that.
      - HappMacDonald 2y ago
        What's wrong with <input type="text" pattern="[0-9.-]*"> though?
        francislavoie 2y ago
        It doesn't prevent the bad input, it only validates it on submission. Therefore it's on the user to fix it, and if it's from a zero-width space, it's literally invisible. Non-technical users will have no idea what to look for to fix it (i.e. use your arrow keys cursor to see at which character the arrow key doesn't shift visually, and there's the ZWSP). It happens way too often.
        deleted 2y ago
        [deleted]
    - jcelerier 2y ago
      I see weird spaces every time I copy-paste from some pdf pretty much, especially if it's a digitised or 10+ years one. Hardly an irrelevant use case
    - lomase 2y ago
      Add to that pasting from MS Teams.
    - ragnese 2y ago
      I'll be one of those guys. I see the invisible whitespace from pasting ALL the time. I've literally dealt with user complaints caused by it three times in the last two weeks! (Usually customer issues don't make it to me unless our support team can't figure it out or suspects a bug) To be fair, it's not usually that frequent. Just a funny coincidence that I've JUST dealt with it more recently.
  - pmontra 2y ago
    The problem here is that sometimes users and copy pasting from another document and that comes in arbitrary formatting, not the one enforced by the input element. For example phone numbers can be a string of digits, or multiple strings separated by spaces or hyphens or with parts enclosed by () etc It's a more pleasant UX to let them paste anything, then edit it inside the input, validate and submit.
    - xigoi 2y ago
      > For example phone numbers can be a string of digits, or multiple strings separated by spaces or hyphens or with parts enclosed by () etc > > It's a more pleasant UX to let them paste anything, then edit it inside the input, validate and submit. How is that more pleasant than a textbox which automatically removes the extra characters?
      - djtango 2y ago
        Because you don't know what your user wants to do and eventually you'll annoy someone
      - kevincox 2y ago
        What if I copy something but accidentally get another couple words one of which is a number. For example copying from a chat app and get the date with the message. Then my "Sep 24th 416-555-1234" input which, would have been very easy to fix, becomes 244-165-5512 34. It will take me a few seconds to realize what has happened, identify where the intended phone number starts and remove the accidentally pasted digits. The nice thing about the native input is that it is very simple, predictable and flexible. It may be easier to make a better UX on the happy cases but it is very difficult to not add some suboptimal and confusing UX on the less happy cases. Often times it is best just to keep it simple so that the user can easily complete their task rather than adding some "magic" which may backfire and confuse users. It is surprisingly often that I need to open a text-editor or clipboard-editor to format values before pasting them into apps or websites because they have broken an input field by trying to be magic and failing to consider anything but the happy cases and maybe one or two bad paths.
  - eru 2y ago
    Why blame it on the user, instead of fixing it? You could remove the zero-width spaces in validation (for eg a phone number).
    - francislavoie 2y ago
      Or, you know, prevent invalid characters from the get-go. Same thing as validation, but done up-front. (But as I said elsewhere, I'm not talking about phone numbers, I'm talking about amounts)
      - eru 2y ago
        I would like to allow people to copy-and-paste text in, and then edit it. That could be a longer text that has the amount in it (but also some unrelated numbers).
      - yakshaving_jgt 2y ago
        Because this often makes the input feel broken to the user. Instead of asserting that "users are too stupid" as you have done earlier, perhaps programmers should be less stupid and write more permissive parsers. Accessible design is actually pretty hard, and most designers and programmers get this wrong. If you want some good design advice, you can start here: https://adamsilver.io/blog/the-problem-with-live-validation-and-what-to-do-instead/ https://adamsilver.io/blog/the-problem-with-live-validation-...
        francislavoie 2y ago
        I'm not using "stupid" in the derogatory sense. I'm using it as a recognition of the skill/knowledge gap between technical and non-technical users. To clarify, we get _asked_ by our users to implement fields that limit input to help them avoid mistakes. Our QA and UX teams agree. This isn't a unilateral engineering decision.
        eru 2y ago
        Yes, you want to provide guidance, but without getting in the way. That's why I was suggesting letting the user paste in these 'wrong' characters, but offering help in removing them. Of course, that's a trade-off. And it's more annoying to design and implement than just forbidding those characters from entering the input field in the first place.
  - hluska 2y ago
    I’ve read some very user hostile things in my career, but this one is particularly acerbic. It’s a bad look. If I ever grew to hate users this much, I would find a new career. You should consider that.
    - francislavoie 2y ago
      I'm not being user hostile. I'm being cognizant that the skill levels of users is extremely wide, and to best serve everyone from a UX standpoint, it's best to limit the characters accepted in the input. It protects the user, helps them avoid mistakes.
      - guappa 2y ago
        From reading your comments, you're extremely user hostile and I hope to not come across anything you work on because they are the very definition of antipatterns
        francislavoie 2y ago
        It's a decimal number field. There's no reason to have any other characters than [0-9\.-]* You're overreacting. You're attacking me for no reason.
        guappa 2y ago
        Except if one copied it and it has a space in the beginning and your amazing script won't let one paste it.
      - hluska 2y ago
        [flagged]
        AnimalMuppet 2y ago
        Not everyone who disagrees with you is lying. Accusing people is a bad look here on HN. "Assume good faith" is the standard. You can say "You're wrong". "You're lying", though, is almost never appropriate, and is, in itself, quite hostile.
  - kevincox 2y ago
    In most cases when you are accepting a numeric value it is best to just strip anything that isn't 0-9 then run validation on just the digits. There are some exceptions like phone numbers which may need + prefixes and similar but you can adjust these rules. What I have found to work well is when the user unfocuses the input field or on submit strip everything but expected values then validate. If you want you can format the value at this time too (and the formatting won't interfere with text input). If you want to get really fancy you can strip and format as they type and be careful to keep the formatting "virtual" such that the user is only editing the raw digits but this is very tricky to get right on all platforms and support all expected native editing UX. But even in the best cases this can have bad edge cases. For example the user pastes some text but it happens to have multiple numbers in it, if you eagerly strip and format what is left for the user will be these two numbers mushed together with misplaced separators or similar. If you let them paste, remove the unintended stuff, then format on blur this just works and is understandable.
- Groxx 2y ago
  Very much this. Live re-structuring runs afoul of tons of things you can't predict. You can validate roughly anywhere, but at the absolute earliest, only re-format on blur. Never earlier. You have no idea what the user might be doing in the meantime. And even then, I'd strongly suggest not changing what they entered. Change it to a display-only element with nice formatting if you want, but don't screw with their input.
wodenokoto 2y ago
> what's crazy is both of those still don't disallow non-numeric input Which is really nice for copy pasting. For example, I have a number with spaces in it, and when I paste I get nothing or only until the first space because someone decided I'm not allowed to have non-numericals in the input field at anytime.
account42 2y ago
You shouldn't reject keystrokes as that can lead to silent errors when the user thinks they entered something that was not allowed. And final validation needs to happen on the server side anyway - anything before that is just a usability helper.
- joelanman 2y ago
  exactly. Silently refusing input is an anti-pattern

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
    "Break your UX" is a vast exaggeration. I'm not talking about phone number fields, to be clear. I'm talking about like numeric amounts, with maybe a negative or decimal point. It's literally just [0-9\.-] but that still requires JS to limit inputs to that.
    - HappMacDonald 2y ago
      What's wrong with <input type="text" pattern="[0-9.-]*"> though?
      - francislavoie 2y ago
        It doesn't prevent the bad input, it only validates it on submission. Therefore it's on the user to fix it, and if it's from a zero-width space, it's literally invisible. Non-technical users will have no idea what to look for to fix it (i.e. use your arrow keys cursor to see at which character the arrow key doesn't shift visually, and there's the ZWSP). It happens way too often.
      - deleted 2y ago
        [deleted]
  - jcelerier 2y ago
    I see weird spaces every time I copy-paste from some pdf pretty much, especially if it's a digitised or 10+ years one. Hardly an irrelevant use case
  - lomase 2y ago
    Add to that pasting from MS Teams.
  - ragnese 2y ago
    I'll be one of those guys. I see the invisible whitespace from pasting ALL the time. I've literally dealt with user complaints caused by it three times in the last two weeks! (Usually customer issues don't make it to me unless our support team can't figure it out or suspects a bug) To be fair, it's not usually that frequent. Just a funny coincidence that I've JUST dealt with it more recently.
- pmontra 2y ago
  The problem here is that sometimes users and copy pasting from another document and that comes in arbitrary formatting, not the one enforced by the input element. For example phone numbers can be a string of digits, or multiple strings separated by spaces or hyphens or with parts enclosed by () etc It's a more pleasant UX to let them paste anything, then edit it inside the input, validate and submit.
  - xigoi 2y ago
    > For example phone numbers can be a string of digits, or multiple strings separated by spaces or hyphens or with parts enclosed by () etc > > It's a more pleasant UX to let them paste anything, then edit it inside the input, validate and submit. How is that more pleasant than a textbox which automatically removes the extra characters?
    - djtango 2y ago
      Because you don't know what your user wants to do and eventually you'll annoy someone
    - kevincox 2y ago
      What if I copy something but accidentally get another couple words one of which is a number. For example copying from a chat app and get the date with the message. Then my "Sep 24th 416-555-1234" input which, would have been very easy to fix, becomes 244-165-5512 34. It will take me a few seconds to realize what has happened, identify where the intended phone number starts and remove the accidentally pasted digits. The nice thing about the native input is that it is very simple, predictable and flexible. It may be easier to make a better UX on the happy cases but it is very difficult to not add some suboptimal and confusing UX on the less happy cases. Often times it is best just to keep it simple so that the user can easily complete their task rather than adding some "magic" which may backfire and confuse users. It is surprisingly often that I need to open a text-editor or clipboard-editor to format values before pasting them into apps or websites because they have broken an input field by trying to be magic and failing to consider anything but the happy cases and maybe one or two bad paths.
- eru 2y ago
  Why blame it on the user, instead of fixing it? You could remove the zero-width spaces in validation (for eg a phone number).
  - francislavoie 2y ago
    Or, you know, prevent invalid characters from the get-go. Same thing as validation, but done up-front. (But as I said elsewhere, I'm not talking about phone numbers, I'm talking about amounts)
    - eru 2y ago
      I would like to allow people to copy-and-paste text in, and then edit it. That could be a longer text that has the amount in it (but also some unrelated numbers).
    - yakshaving_jgt 2y ago
      Because this often makes the input feel broken to the user. Instead of asserting that "users are too stupid" as you have done earlier, perhaps programmers should be less stupid and write more permissive parsers. Accessible design is actually pretty hard, and most designers and programmers get this wrong. If you want some good design advice, you can start here: https://adamsilver.io/blog/the-problem-with-live-validation-and-what-to-do-instead/ https://adamsilver.io/blog/the-problem-with-live-validation-...
      - francislavoie 2y ago
        I'm not using "stupid" in the derogatory sense. I'm using it as a recognition of the skill/knowledge gap between technical and non-technical users. To clarify, we get _asked_ by our users to implement fields that limit input to help them avoid mistakes. Our QA and UX teams agree. This isn't a unilateral engineering decision.
        eru 2y ago
        Yes, you want to provide guidance, but without getting in the way. That's why I was suggesting letting the user paste in these 'wrong' characters, but offering help in removing them. Of course, that's a trade-off. And it's more annoying to design and implement than just forbidding those characters from entering the input field in the first place.
- hluska 2y ago
  I’ve read some very user hostile things in my career, but this one is particularly acerbic. It’s a bad look. If I ever grew to hate users this much, I would find a new career. You should consider that.
  - francislavoie 2y ago
    I'm not being user hostile. I'm being cognizant that the skill levels of users is extremely wide, and to best serve everyone from a UX standpoint, it's best to limit the characters accepted in the input. It protects the user, helps them avoid mistakes.
    - guappa 2y ago
      From reading your comments, you're extremely user hostile and I hope to not come across anything you work on because they are the very definition of antipatterns
      - francislavoie 2y ago
        It's a decimal number field. There's no reason to have any other characters than [0-9\.-]* You're overreacting. You're attacking me for no reason.
        guappa 2y ago
        Except if one copied it and it has a space in the beginning and your amazing script won't let one paste it.
    - hluska 2y ago
      [flagged]
      - AnimalMuppet 2y ago
        Not everyone who disagrees with you is lying. Accusing people is a bad look here on HN. "Assume good faith" is the standard. You can say "You're wrong". "You're lying", though, is almost never appropriate, and is, in itself, quite hostile.
- kevincox 2y ago
  In most cases when you are accepting a numeric value it is best to just strip anything that isn't 0-9 then run validation on just the digits. There are some exceptions like phone numbers which may need + prefixes and similar but you can adjust these rules. What I have found to work well is when the user unfocuses the input field or on submit strip everything but expected values then validate. If you want you can format the value at this time too (and the formatting won't interfere with text input). If you want to get really fancy you can strip and format as they type and be careful to keep the formatting "virtual" such that the user is only editing the raw digits but this is very tricky to get right on all platforms and support all expected native editing UX. But even in the best cases this can have bad edge cases. For example the user pastes some text but it happens to have multiple numbers in it, if you eagerly strip and format what is left for the user will be these two numbers mushed together with misplaced separators or similar. If you let them paste, remove the unintended stuff, then format on blur this just works and is understandable.
Groxx 2y ago
Very much this. Live re-structuring runs afoul of tons of things you can't predict. You can validate roughly anywhere, but at the absolute earliest, only re-format on blur. Never earlier. You have no idea what the user might be doing in the meantime. And even then, I'd strongly suggest not changing what they entered. Change it to a display-only element with nice formatting if you want, but don't screw with their input.

wodenokoto 2y ago

> what's crazy is both of those still don't disallow non-numeric input Which is really nice for copy pasting. For example, I have a number with spaces in it, and when I paste I get nothing or only until the first space because someone decided I'm not allowed to have non-numericals in the input field at anytime.

account42 2y ago

You shouldn't reject keystrokes as that can lead to silent errors when the user thinks they entered something that was not allowed. And final validation needs to happen on the server side anyway - anything before that is just a usability helper.

joelanman 2y ago
exactly. Silently refusing input is an anti-pattern