7 ms·

I've tried similar libraries and they all suffer the same general "I don't know what the backspace key just did" sorta issues... Just look at the top features

I've tried similar libraries and they all suffer the same general "I don't know what the backspace key just did" sorta issues... Just look at the top features listed on their Github: * CC number - doesn't actually support all PAN formats - 19 digits exist although extraordinary rare. NEVER try to do anything fancy with your CC details field because if people try to pay you and can't you've lost a customer. * Phone number formatting - doesn't support all phone # formats. Leave this as flat text (non-numeric) or numeric for base telephone # and a text field for extension. * Date formatting - use type="date" so you get native mobile support for date entry. * Numeral formatting - use type="number" so you get native mobile support for numeric entry.

pmarreck 8y ago
Your response is assholish. Try being more compassionate next time, some dude probably worked on this on his own time, and these issues you’ve noted can be fixed.
- folkhack 8y ago
  Sure but look at the top-level comments on here and there are words like: * "anti-pattern" * "overzealous autocorrect" * "this is everything I hate about 'modern' UI" * "I hate this idea" * "This is a weird API for what it’s trying to achieve" * "...THEN select the country..my number gets deleted... I hate you now" * "Cute, but it looks like it's trying too hard to be clever." * "Couldn't find my country for the phone number (UK). Looked for EN and UK, eventually discovered it was GB. Hard!" * "hot garbage trash" - wait whoops ... that's mine - seems to fit right in though! It actually took me a few consecutive quotes before I even found a neutral sounding "should simply be solved by browsers imho" comment. "Your response is assholish" is correct, and I will agree. However I have a visceral reaction against these anti-patterns. The web is suppose to be open, and the web is suppose to be usable by a diverse group of people (including those with disabilities). I don't care if someone built this in their "free-time", this is NOT a responsible front-end lib to use.
  - rob 8y ago
    Dude, just stop. We're trying to read the thread and you keep coming in with novel-sized replies about nothing!
    - TeMPOraL 8y ago
      Check your address bar. This is HN, not Twitter. Longer-form comments here are welcome. (And it's not about nothing, it's a perfectly valid, if strong worded, criticism about a library promoting bad UX, which is unfortunately popular, and thus inflicting UX suffering on many users on the Internet.)
  - ratsmack 8y ago
    This is why I very rarely comment... people on this site are far too sensitive.
  - pmarreck 8y ago
    Your logical fallacy (which encompasses your entire comment here) is: https://en.wikipedia.org/wiki/Whataboutism https://en.wikipedia.org/wiki/Whataboutism
robin_reala 8y ago
An interesting thing I’ve seen in user research is deaf people writing “Please do not call me, I’m deaf” in telephone fields. If your masking blocks this functionality you’re working against your users.
- folkhack 8y ago
  I've never seen that but it's a super interesting case. Reading this makes me start brainstorming ways I can be more accommodating for that situation - that wouldn't fly with certain sites I run due to US-based NPA-NXX validation on the back-end. Hmm.
dang 8y ago
This comment breaks the site guidelines. Can you please make your substantive points without being gratuitously negative or disrespectful? That's always possible and always better, and it's what users here are asked to do. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- folkhack 8y ago
  My apologies - can you give me the edit capability to go in and tone that down then? Or maybe the ability to delete a comment that turned out to be controversial? If you are a mod - feel free to delete this thread as many people in other parts of the post are echoing my sentiments, some with equally as harsh language (which you are not singling out). That lib is technologically irresponsible to use and breaks user experience for a lot of people - I was trying to put a very clear warning out there and decided to be honest in my choice of words which many people have actually defended in this conversation.
  - dang 8y ago
    Sure, I've marked your GP comment editable. If you could let us know at hn@ycombinator.com when you've finished editing it, that would be helpful. We can't come close to reading all the comments on HN, so inevitably we miss ones that are as bad or worse as the ones we reply to. If you notice bad comments that haven't been moderated, the likeliest explanation is that we didn't see it. Please flag them (as described in https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html), since that helps bring them to our attention. You can also email links to hn@ycombinator.com in egregious cases.
amluto 8y ago
I haven’t looked at this particular project, but the common “wow form JS!!!” feature that annoys me the most is when the script automatically advances to the next field when it thinks I finished the current field. Not only does this break when users finish typing and hit tab by reflex, but it makes it extremely difficult to go back and correct error. Just use normal HTML text entry. Showing validation errors is fine. Actually interfering with input is a huge UX mistake.
elizabeth_olu 8y ago
https://www.elizabethblog.com.ng/2019/02/ten-thugs-were-caught-and-arrested-in.html https://www.elizabethblog.com.ng/2019/02/ten-thugs-were-caug...
leeoniya 8y ago
personally, i don't like how this particular lib does masking. however... > 19 digits exist although extraordinary rare. this is an understatement. in 15 years and hundreds of thousands of transactions, i've never seen one. > Phone number formatting - doesn't support all phone # formats. depends on your customers. 99.99% of ours are US and CA. i would argue that a very large swath of businesses do not have wildly varied customers. we very rarely encounter anything other than 555-555-5555. but very frequently encounter 555555555 (one digit too short), cause customer wasnt required to add delimiters. yes, you can validate this post-entry, but still. post-entry errors are annoying, too. > Date formatting - use type="date" so you get native mobile support for date entry. unless you need MM/YY, right? [type=month] also sucks, btw. > Numeral formatting - use type="number" this allows symbols that aren't actually numeric to be entered in many cases. i use a fork i made based on this: https://codepen.io/lagden/pen/XzLYJE https://codepen.io/lagden/pen/XzLYJE - it handles deleting from end in chrome and safari (i had to add a bit to make it work in Firefox, Edge, IE since they dont support [1]). - it inserts a valid symbol even if you mistype a symbol instead of preventing entry. - it's not perfect, and doesnt quite handle editing in the middle since it just assigns the input value. it also cannot do more complex stuff like optional chars. but it's good enough to be helpful 99% of the time and not horribly intrusive. [1] e.inputType === 'deleteContentBackward'
- tokyodude 8y ago
  type="number" gives a numeric input keyboard on mobile instead of a full keyboard
- folkhack 8y ago
  Perfect example of "post your professional experiences on HN and get it ripped apart immediately." On PANs - sure. However, I (personally) have seen odd-digit PANs but also deal with an industry that sees literally EVERY type of CC number you can imagine from all different areas of the world. Your experience (like mine) is anecdotal. But, here's the kicker - I HAVE to go with what VISA tells me to do because of their individual PCN integration requirements. If VISA is telling me "hey - it's a best practice to support all of our potential PAN formats even though 99% are going to be 16 digit" then I have to support that =) On phone # formatting - sure. If your use case is the US and Canada things become MUCH more standardized for everything from banking data, to addresses, to (of course) phone numbers. However - I see foreign/odd phone # formats from the Americas constantly as not all the people who are here at this time have a local phone provider. (ie: travel). I concede on number formatting - but I still use it because (IMO) it has the best/most-consistent mobile experience vs. custom libraries. On date formatting - sure. "also sucks, btw" let's tell the users WHY it sucks because otherwise it's just trusting some random guy on the internet. But yea - cool fork on codepen.
mathieuh 8y ago
> Date formatting - use type="date" so you get native mobile support for date entry. I do work for GDS and while we offer a date picker for date fields in the app I work on, we also have three day/month/year fields, because date pickers are terrible for accessibility and we would fail assessment. So is having one field that tries to magically parse what you mean into a date. Just let the user enter the numbers they want, and return a 400 when they post the form if the numbers don't make sense. Imagine if you're blind and you try and enter a date into those `dd/mm/yyyy/` magic fields
- folkhack 8y ago
  > we also have three day/month/year fields Yep - I actually use strategy this and type="date" both depending on what the precision requirements are =) I've always seen the "three-field" old-school method as the most bullet-proof approach for this. Plus, validation becomes super easy since you're just doing simple integers w/ranges. > Imagine if you're blind and you try and enter a date into those `dd/mm/yyyy/` magic fields 100% - those things absolutely break down for screen reading tech/etc. That's also why I hate these sort of "input masking" libs... accessibility is a huge concern of mine.
rplnt 8y ago
> screws up your conversion rates Well, it is called cLEAVE.
root_axis 8y ago
> that one fact alone makes this trash. Like - hot garbage "screws up your conversion rates" trash. That's a pretty hostile and condescending way to talk about someone else's work. Your statement is also incorrect if applied as a general rule. I have personally administered A/B tests for this type of masking behavior on a sales funnel and observed an increase in conversation rates (specifically for credit card number masking) on our site.
- folkhack 8y ago
  > Your statement is also incorrect if applied as a general rule. I would absolutely disagree with you here. It is a generally accepted "case" that additional validation barriers on conversion experiences cause users to drop off. I have seen this scientifically proven by hard numbers time and time again over my ecommerce career. > That's a pretty hostile and condescending way to talk about someone else's work. Sure, I'll take that criticism. I still think it's a horrible practice and would professionally advise anyone against implementing this. I do love how we like to rip on the JS community when it's convenient for us (npm, every new framework ever, etc) but when I say a front-end lib is "hot-garbage trash" because it breaks something as simple as backspace it's over the line...
  - fnordsensei 8y ago
    > It is a generally accepted "case" that additional validation barriers on conversion experiences cause users to drop off. Presumably the introduction of validation barriers that don't guide the input to the intended form, then. How would the ability to type an arbitrary amount of numbers, or letters, in a credit card number field lead to higher conversion?
    - folkhack 8y ago
      > How would the ability to type an arbitrary amount of numbers, or letters, in a credit card number field lead to higher conversion? Sure - I'll bite. But I'm also going to point out that you're swinging to the other end of the extreme. Obviously no one in their right mind would just allow arbitrary input... Clearly every CC number can be represented by numbers alone (by omitting the slashes). People are absolutely familiar with this and often will omit the dashes in their fields all together without any filtering of characters. Personally I key off of the "keydown" event on that field and e.preventDefault/return false on anything non-numeric. In the future, I hope the "inputmode" HTML attribute catches on with non-Chromium browsers - that would eliminate my need to do this. After the number is entered, or (personal preference) before the form is posted, you do a simple Luhn check and show a dynamic error message RIGHT ABOVE the field saying "hey invalid CC num yo" - ideally you keep the "process" button and CC num field close to each other so this happens within the same document view without having to auto-scroll/anchor to the invalidated field. Then, as always - ensure you have the capability to validate that data using the same rules on the back-end before it's allowed to be sent to your processor, or w/e. There ya go - there's the "everyman's" approach to CC validation on the front-end.

pmarreck 8y ago

Your response is assholish. Try being more compassionate next time, some dude probably worked on this on his own time, and these issues you’ve noted can be fixed.

folkhack 8y ago
Sure but look at the top-level comments on here and there are words like: * "anti-pattern" * "overzealous autocorrect" * "this is everything I hate about 'modern' UI" * "I hate this idea" * "This is a weird API for what it’s trying to achieve" * "...THEN select the country..my number gets deleted... I hate you now" * "Cute, but it looks like it's trying too hard to be clever." * "Couldn't find my country for the phone number (UK). Looked for EN and UK, eventually discovered it was GB. Hard!" * "hot garbage trash" - wait whoops ... that's mine - seems to fit right in though! It actually took me a few consecutive quotes before I even found a neutral sounding "should simply be solved by browsers imho" comment. "Your response is assholish" is correct, and I will agree. However I have a visceral reaction against these anti-patterns. The web is suppose to be open, and the web is suppose to be usable by a diverse group of people (including those with disabilities). I don't care if someone built this in their "free-time", this is NOT a responsible front-end lib to use.
- rob 8y ago
  Dude, just stop. We're trying to read the thread and you keep coming in with novel-sized replies about nothing!
  - TeMPOraL 8y ago
    Check your address bar. This is HN, not Twitter. Longer-form comments here are welcome. (And it's not about nothing, it's a perfectly valid, if strong worded, criticism about a library promoting bad UX, which is unfortunately popular, and thus inflicting UX suffering on many users on the Internet.)
- ratsmack 8y ago
  This is why I very rarely comment... people on this site are far too sensitive.
- pmarreck 8y ago
  Your logical fallacy (which encompasses your entire comment here) is: https://en.wikipedia.org/wiki/Whataboutism https://en.wikipedia.org/wiki/Whataboutism

robin_reala 8y ago

An interesting thing I’ve seen in user research is deaf people writing “Please do not call me, I’m deaf” in telephone fields. If your masking blocks this functionality you’re working against your users.

folkhack 8y ago
I've never seen that but it's a super interesting case. Reading this makes me start brainstorming ways I can be more accommodating for that situation - that wouldn't fly with certain sites I run due to US-based NPA-NXX validation on the back-end. Hmm.

dang 8y ago

This comment breaks the site guidelines. Can you please make your substantive points without being gratuitously negative or disrespectful? That's always possible and always better, and it's what users here are asked to do. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

folkhack 8y ago
My apologies - can you give me the edit capability to go in and tone that down then? Or maybe the ability to delete a comment that turned out to be controversial? If you are a mod - feel free to delete this thread as many people in other parts of the post are echoing my sentiments, some with equally as harsh language (which you are not singling out). That lib is technologically irresponsible to use and breaks user experience for a lot of people - I was trying to put a very clear warning out there and decided to be honest in my choice of words which many people have actually defended in this conversation.
- dang 8y ago
  Sure, I've marked your GP comment editable. If you could let us know at hn@ycombinator.com when you've finished editing it, that would be helpful. We can't come close to reading all the comments on HN, so inevitably we miss ones that are as bad or worse as the ones we reply to. If you notice bad comments that haven't been moderated, the likeliest explanation is that we didn't see it. Please flag them (as described in https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html), since that helps bring them to our attention. You can also email links to hn@ycombinator.com in egregious cases.

amluto 8y ago

I haven’t looked at this particular project, but the common “wow form JS!!!” feature that annoys me the most is when the script automatically advances to the next field when it thinks I finished the current field. Not only does this break when users finish typing and hit tab by reflex, but it makes it extremely difficult to go back and correct error. Just use normal HTML text entry. Showing validation errors is fine. Actually interfering with input is a huge UX mistake.

elizabeth_olu 8y ago

https://www.elizabethblog.com.ng/2019/02/ten-thugs-were-caught-and-arrested-in.html https://www.elizabethblog.com.ng/2019/02/ten-thugs-were-caug...

leeoniya 8y ago

personally, i don't like how this particular lib does masking. however... > 19 digits exist although extraordinary rare. this is an understatement. in 15 years and hundreds of thousands of transactions, i've never seen one. > Phone number formatting - doesn't support all phone # formats. depends on your customers. 99.99% of ours are US and CA. i would argue that a very large swath of businesses do not have wildly varied customers. we very rarely encounter anything other than 555-555-5555. but very frequently encounter 555555555 (one digit too short), cause customer wasnt required to add delimiters. yes, you can validate this post-entry, but still. post-entry errors are annoying, too. > Date formatting - use type="date" so you get native mobile support for date entry. unless you need MM/YY, right? [type=month] also sucks, btw. > Numeral formatting - use type="number" this allows symbols that aren't actually numeric to be entered in many cases. i use a fork i made based on this: https://codepen.io/lagden/pen/XzLYJE https://codepen.io/lagden/pen/XzLYJE - it handles deleting from end in chrome and safari (i had to add a bit to make it work in Firefox, Edge, IE since they dont support [1]). - it inserts a valid symbol even if you mistype a symbol instead of preventing entry. - it's not perfect, and doesnt quite handle editing in the middle since it just assigns the input value. it also cannot do more complex stuff like optional chars. but it's good enough to be helpful 99% of the time and not horribly intrusive. [1] e.inputType === 'deleteContentBackward'

tokyodude 8y ago
type="number" gives a numeric input keyboard on mobile instead of a full keyboard
folkhack 8y ago
Perfect example of "post your professional experiences on HN and get it ripped apart immediately." On PANs - sure. However, I (personally) have seen odd-digit PANs but also deal with an industry that sees literally EVERY type of CC number you can imagine from all different areas of the world. Your experience (like mine) is anecdotal. But, here's the kicker - I HAVE to go with what VISA tells me to do because of their individual PCN integration requirements. If VISA is telling me "hey - it's a best practice to support all of our potential PAN formats even though 99% are going to be 16 digit" then I have to support that =) On phone # formatting - sure. If your use case is the US and Canada things become MUCH more standardized for everything from banking data, to addresses, to (of course) phone numbers. However - I see foreign/odd phone # formats from the Americas constantly as not all the people who are here at this time have a local phone provider. (ie: travel). I concede on number formatting - but I still use it because (IMO) it has the best/most-consistent mobile experience vs. custom libraries. On date formatting - sure. "also sucks, btw" let's tell the users WHY it sucks because otherwise it's just trusting some random guy on the internet. But yea - cool fork on codepen.

mathieuh 8y ago

> Date formatting - use type="date" so you get native mobile support for date entry. I do work for GDS and while we offer a date picker for date fields in the app I work on, we also have three day/month/year fields, because date pickers are terrible for accessibility and we would fail assessment. So is having one field that tries to magically parse what you mean into a date. Just let the user enter the numbers they want, and return a 400 when they post the form if the numbers don't make sense. Imagine if you're blind and you try and enter a date into those `dd/mm/yyyy/` magic fields

folkhack 8y ago
> we also have three day/month/year fields Yep - I actually use strategy this and type="date" both depending on what the precision requirements are =) I've always seen the "three-field" old-school method as the most bullet-proof approach for this. Plus, validation becomes super easy since you're just doing simple integers w/ranges. > Imagine if you're blind and you try and enter a date into those `dd/mm/yyyy/` magic fields 100% - those things absolutely break down for screen reading tech/etc. That's also why I hate these sort of "input masking" libs... accessibility is a huge concern of mine.

rplnt 8y ago

> screws up your conversion rates Well, it is called cLEAVE.

root_axis 8y ago

> that one fact alone makes this trash. Like - hot garbage "screws up your conversion rates" trash. That's a pretty hostile and condescending way to talk about someone else's work. Your statement is also incorrect if applied as a general rule. I have personally administered A/B tests for this type of masking behavior on a sales funnel and observed an increase in conversation rates (specifically for credit card number masking) on our site.

folkhack 8y ago
> Your statement is also incorrect if applied as a general rule. I would absolutely disagree with you here. It is a generally accepted "case" that additional validation barriers on conversion experiences cause users to drop off. I have seen this scientifically proven by hard numbers time and time again over my ecommerce career. > That's a pretty hostile and condescending way to talk about someone else's work. Sure, I'll take that criticism. I still think it's a horrible practice and would professionally advise anyone against implementing this. I do love how we like to rip on the JS community when it's convenient for us (npm, every new framework ever, etc) but when I say a front-end lib is "hot-garbage trash" because it breaks something as simple as backspace it's over the line...
- fnordsensei 8y ago
  > It is a generally accepted "case" that additional validation barriers on conversion experiences cause users to drop off. Presumably the introduction of validation barriers that don't guide the input to the intended form, then. How would the ability to type an arbitrary amount of numbers, or letters, in a credit card number field lead to higher conversion?
  - folkhack 8y ago
    > How would the ability to type an arbitrary amount of numbers, or letters, in a credit card number field lead to higher conversion? Sure - I'll bite. But I'm also going to point out that you're swinging to the other end of the extreme. Obviously no one in their right mind would just allow arbitrary input... Clearly every CC number can be represented by numbers alone (by omitting the slashes). People are absolutely familiar with this and often will omit the dashes in their fields all together without any filtering of characters. Personally I key off of the "keydown" event on that field and e.preventDefault/return false on anything non-numeric. In the future, I hope the "inputmode" HTML attribute catches on with non-Chromium browsers - that would eliminate my need to do this. After the number is entered, or (personal preference) before the form is posted, you do a simple Luhn check and show a dynamic error message RIGHT ABOVE the field saying "hey invalid CC num yo" - ideally you keep the "process" button and CC num field close to each other so this happens within the same document view without having to auto-scroll/anchor to the invalidated field. Then, as always - ensure you have the capability to validate that data using the same rules on the back-end before it's allowed to be sent to your processor, or w/e. There ya go - there's the "everyman's" approach to CC validation on the front-end.