20 ms·

In summary the main issue is that, according to the spec, `<input type="number">` is only for numbers that are going to be parsed into a Javascript number. It h

In summary the main issue is that, according to the spec, `<input type="number">` is only for numbers that are going to be parsed into a Javascript number. It has to make sense to increment, decrement or do other numerical operations on it. It's not to be used for strings or identifiers that just so happen to be numbers, e.g. credit card numbers. I'll admit this is slightly surprising to me but it does make a certain amount of sense. The solution is to use `<input type=”text” inputmode=”numeric” pattern="[0-9]*">`.

VBprogrammer 7y ago
I've come across this problem a number of times. The same applies in, for example, passing IDs across in JSON where I use strings if at all possible. Even money amount are typically challenging to treat as numeric as often that drops them into a float when you shouldn't be processing money amounts as floats.
downerending 7y ago
One good reason for this is that for things like credit card numbers, a good interface will accept leading, trailing, or interior spaces. Sites that make me type in values in exactly their own weird format are an abomination. Site A: Ah ah ah! You put a slash in your date! No soup for you! Site B: Ah ah ah! You didn't put a slash in your date! No soup for you!
- airstrike 7y ago
  > a good interface will accept leading, trailing, or interior spaces Won't pattern="[0-9]*" do the exact opposite of what you're suggesting?
  - dmix 7y ago
    Yes, you're right, this isn't a great solution for credit card inputs either. They should be able handle dashes and other spacing characters and the site should be able to filter/format it automatically either on the front-end before submission or with some server-side processing. And no we don't need four different input boxes to enter a credit card numbers either. Flexibility is key here and since many websites handle things differently (and since many of the physical cards have literal dashes on them, which they are looking at when inputting the numbers), you should be able to guide your user into the right format without them having to get error messages or other nonsense. Not enough web designers appreciate the anxiety of having to input a credit card number or other format-varied content into input boxes.
    - fallous 7y ago
      Part of the problem is that inputs don't necessarily reflect the specific intent behind the use of certain symbols. For 99% of people using US keyboards when they input a dash in a credit card number they are using the exact same key as one would use for the minus when inputting a negative number. If you asked them to verbalize their inputs they would probably use different words for the same symbol, signifying that the meaning or intent isn't the same but even that isn't entirely reliable. You can attempt to infer intent or meaning based on the context of the input field but often the least-problematic method is to provide instruction/hints with the field, examples of correctness, and real-time validation with specific syntax errors when invalid or unexpected data is provided. I'd argue that it would also be worthwhile to request clarity from the user when an input hits a filtering rule so that they can make clear their intent... e.g. if you assume that they're using "-" as a symbol for separation rather than simply follow that assumption, ask if that's the case and list other optional valid contexts for that symbol so they can be explicit. If they choose None of the Above or a context that is inappropriate for the field, inform them of that. The 4-box credit card form, while pretty terrible in many ways, at least made explicit the expectations. Often we now hide the expectations and either auto-reformat what was put in the field (which can be surprising to the user or worse can modify their input to mean something other than what they intended) or do hidden filtering, which can have the same problems but doesn't even bother to inform the user of the changes.
      - DonHopkins 7y ago
        Not to mention that some countries use . as a decimal point and , as a digit grouping separator, and others do it the other way around.
        bcrosby95 7y ago
        Yes, I'm rather glad I haven't had to deal with localizing decimal inputs, just displaying them. I have had to deal with localizing date inputs though. Ugh.
        7y ago
  - joelanman 7y ago
    Important to note that in the article we mention we only use pattern to trigger the right keyboard in old iOS. We actually turn off HTML validation in favour of doing server side validation, we'll soon be publishing guidance on that too. Disclaimer - I work on the team.
    - OJFord 7y ago
      Disclosure* - you're claiming to be on the team, not disclaiming it.
    - andreareina 7y ago
      Why are you going to server-side only? I've always held that client-side validation is important for UX as it provides instant feedback and doesn't need any extra work to preserve the other data that's already been input. Obviously the inputs still need to be validated on the server e.g. to protect against things that get past (or bypass) the client-side checks, or perform more expensive validation.
      - joelanman 7y ago
        We'll be publishing soon on the GOV.UK Design System, but in summary we can't make browser validation consistent with our Design System, or guarantee it's always accessible. In our research it's commonly most often helpful to validate when the user submits as that's when you can be sure they're 'done'. There are cases when realtime helps so it's fine to add it in those situations.
  - OJFord 7y ago
    It won't accept it.. in exactly the right way. Because you can't enter spaces, they don't get submitted, and validation doesn't fail. As long as they don't also do 'class="nopaste"' or whatever, we're golden!
- dmix 7y ago
  That's one of the reasons I love Stripe's checkout being used everywhere and designers elsewhere basically copying them. The internet is constantly getting better and I don't think we give that progress we've made in web design over the last few decades enough credit. Just imagine how bad it used to be to just purchase a simple thing on an ecommerce site in the mid 2000s. Or remember what car websites used to look like vs what they look like now. Even newspaper websites like NYT are leaders with quality design. It's easy to complain about those who still don't get it, but I feel like we've also made massive progress from the early wild-west days of the internet. Still, I'm all for shaming those sites who still make inserting credit card numbers a pain in the ass.
  - BrianB 7y ago
    > Or remember what car websites used to look like vs what they look like now. lingscars.com ?
    - admax88q 7y ago
      This site is amazing.
    - frob 7y ago
      This might be the best website ever. It is over the top, but the theme is consistent. It reminds me of a myspace page, but if someone just wanted to be ridiculous, not unsightly. Side note: anyone remember "I knows me some ugly myspace" from Ze Frank?
      - aspenmayer 7y ago
        Ze Frank. Now there’s a name I haven’t heard in quite some time. What an early internet vlog pioneer. I wondered what happened to him and looked him up a while back. Turns out he’s some bigwig at BuzzFeed so I guess he made out okay, but part of me misses that early enthusiasm and wonder of early internet 2.0.
        zimpenfish 7y ago
- brlewis 7y ago
  This may not be semantically pure, but I think type="tel" is a simple and ergonomic approach to credit card input. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/tel https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... EDIT: Also more widely supported than https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
  - Wowfunhappy 7y ago
    I'm not against weird hacks where necessary, but how is this better than the GP's non-hacky suggestion? Inputmode isn't supported by most desktop browsers but it doesn't need to be. Every mobile browser save mobile Firefox supports it. ...I wonder what's up with Mobile Firefox?
    - brlewis 7y ago
      Using the same markup for desktop and mobile means less code which usually translates to fewer bugs.
      - Wowfunhappy 7y ago
        It would be the same markup. It just wouldn't do anything on desktop. Which is fine because desktops generally have physical keyboards. I apologize if you already know this, but to make sure we're on the same page: what "inputmode" does is tell phones to display the onscreen keyboard as a numpad, instead of a full set of QWERTY letters and numbers. Outside of a few edge-cases, you don't generally need that on desktop.
        brlewis 7y ago
        TBH I went on autopilot looking at MDN's browser compatibility list. Also as a user of Firefox on Android I was interested in something that works there, but type="tel" doesn't behave any better. The only advantage to not using inputmode is getting rid of an HTML validator warning, so you're right.
- jmiserez 7y ago
  Also sites that accept a 07/21 expiration date but not 7/21. Even worse if they accept it but then say it's an invalid card.
- DonHopkins 7y ago
  I hate it when they have drop-down menu for entering your year of birth, so the older you are, the further you have to scroll, but only infants and toddlers can select the year they were born without scrolling. A non-numeric text field is so much easier, and you should also be able enter your birth year as Roman numerals (which is even easier for millennials).
  - RandallBrown 7y ago
    I think you're joking about Roman numerals, but millennials birth years are anything but easy to type in as a Roman numeral. For example, my birth year of 1987 is MCMLXXXVII.
    - DonHopkins 7y ago
      Oh that's right, I meant post-millennials, who got a fresh start in MM.
      - xboxnolifes 7y ago
        Zoomers
  - numpad0 7y ago
    Can’t you just type “1984” or “Alaska” while focused on the dropdown to select on modern browsers
    - smcl 7y ago
      Not on mobile
  - saagarjha 7y ago
    Trying to change the system because millennials have it slightly easier than you is the most “ok boomer” thing I’ve seen today ;)
  - mc3 7y ago
    Gen Z are the ones born on MM or later.
- anonsivalley652 7y ago
  Exactly. Good control UX should be very liberal in what it accepts and normalize it to whatever form they want. Same goes with editing, it should allow temporary invalidity (extra or fewer digits) turn red/disable submit and then return to green when fixed. Don't make hundreds to millions of users do extra work that could've been automated with a little more care.
- gwillz 7y ago
  Also, the expiry date should never be a date picker. I'm not trying to _choose_ a date, I'm just dumping the exact numbers from my card. I want to type, tab, type, tab, type, enter, and be done.
  - mikro2nd 7y ago
    But wait! It gets worse: Date-of-birth fields where they use a date picker, and the default/starting date is today. I'm a bit older than the average HM demographic, so using a date picker to scroll back many years might take hundreds of clicks. Then I made a mistake (details long forgotten) and the whole thing reset and I had to start again. On the third time around I just quit.
deleted 7y ago
[deleted]
pwdisswordfish2 7y ago
To put it more succinctly and without unnecessarily referring to JavaScript semantics, type="number" is for quantities, not mere strings of digits. It's an unfortunate accident of the English language that both are commonly called ‘numbers’. We might not have had this confusion if some other language were the lingua franca of computing.
- samatman 7y ago
  You can't entirely avoid referring to JavaScript semantics here, type="number" is for values appropriate to represent and work with as IEEE 754 doubles. That covers a lot of ground, by design. But a 'number' it isn't.
  - mjevans 7y ago
    float, floating, double, etc would have been better choices for that type... Though 'quantity' as described in another post still sounds the best given the sub 1 and add 1 buttons.
- bobthepanda 7y ago
  I mean, this could've been solved by the spec using type="quantity". Many languages have generic, ambiguous umbrella terms, it's the sloppiness of the spec picking one.
  - alexis_fr 7y ago
    A sequence of numbers could be called, with a little approximation, a barcode. Which makes me wonder why credit cards don’t have an actual barcode to easily enter it on the computer.
- jsjohnst 7y ago
  The spec could’ve used type=“quantity” and there wouldn’t be as much or any confusion. Point being, blaming the language used for writing the spec, when you readily offered up a better alternative, feels misguided to me.
- 7y ago
robocat 7y ago
inputmode=”numeric” and inputmode=”decimal” have different quirks between Android and iOS. inputmode also acts differently on iPad and iPhone, and the keyboard shown varies from that for pattern=, and support for inputmode is missing from iOS11 (or iOS12?). Tread carefully! Note that type="number" is particularly horrible on iOS because it allows typing non-numeric values and then input.value just returns zero. Instead you must check input.checkValidity(), and perhaps use the CSS :invalid pseudo-selector to show the user that their entry is not valid. You cannot read the actual invalid value AFAIK on iOS (although you could simulate it by looking at key events, if you ignore selection and cut/paste). Data entry with HTML is one area where you really want a native app, and you can get severely burnt trying to use a WebView. I have wasted months dealing with a variety of quirks over the years trying to make time entry friendly in HTML: all solutions have terrible compromises, and different browsers act quite differently (and can have nasty bugs).
- duxup 7y ago
  Gah, that iOS issue is a nightmare.
- thirty6degrees 7y ago
  Those iOS issues with type="number" are really interesting – thanks for sharing. Support for inputmode was added in iOS 12.2, but initially it used the 'numeric keypad with punctuation' – is that what you mean by 'the keyboard shown varies from that for pattern='? iOS 13 updated this behaviour, so it now uses the 'correct' numeric keypad, without the punctuation keys. The pattern attribute is still provided in order to trigger the numeric keypad on older versions of iOS. Once traffic from older iOS devices drops off we'll likely remove it. There's a little more info here: https://github.com/alphagov/govuk-frontend/issues/1449 https://github.com/alphagov/govuk-frontend/issues/1449 (I work on the team)
  - robocat 7y ago
    > iOS 13 updated this behaviour, so it now uses the 'correct' numeric keypad, without the punctuation keys The iPhone shows the 0-9 keyboard. The iPad shows the punctuation keyboard. This is not obvious, and one of the places where Mobile Safari acts differently between the two device types. Try jsbin.com/necuzoj
neves 7y ago
The main issue is that the numeric key pad, with larger buttons, are a lot easier to type (as predicted by Fitt's Law). We must allow they to automatically use this keypad without the confusing behavior of the <input type=number>
dylan-m 7y ago
That's a good rule of thumb there :) More pedantically, credit card numbers _aren't_ numbers in the first place. They are identifiers that happen to use numerical digits. Same as phone numbers. Treating them as numbers at any point in a system is an error. My dream is this detail of the HTML spec forces people to rethink their schema design while they're at it.
- reaperducer 7y ago
  See also: New England ZIP Codes, which can cause all kinds of problems.
  - velosol 7y ago
    To save a search for those who might not know off the top of their head - New England is home to leading zero ZIP codes (e.g. 02122 for Boston).
gbersac 7y ago
I didn't knew you had an inputmode and pattern tag on the html input balise

VBprogrammer 7y ago

I've come across this problem a number of times. The same applies in, for example, passing IDs across in JSON where I use strings if at all possible. Even money amount are typically challenging to treat as numeric as often that drops them into a float when you shouldn't be processing money amounts as floats.

downerending 7y ago

One good reason for this is that for things like credit card numbers, a good interface will accept leading, trailing, or interior spaces. Sites that make me type in values in exactly their own weird format are an abomination. Site A: Ah ah ah! You put a slash in your date! No soup for you! Site B: Ah ah ah! You didn't put a slash in your date! No soup for you!

airstrike 7y ago
> a good interface will accept leading, trailing, or interior spaces Won't pattern="[0-9]*" do the exact opposite of what you're suggesting?
- dmix 7y ago
  Yes, you're right, this isn't a great solution for credit card inputs either. They should be able handle dashes and other spacing characters and the site should be able to filter/format it automatically either on the front-end before submission or with some server-side processing. And no we don't need four different input boxes to enter a credit card numbers either. Flexibility is key here and since many websites handle things differently (and since many of the physical cards have literal dashes on them, which they are looking at when inputting the numbers), you should be able to guide your user into the right format without them having to get error messages or other nonsense. Not enough web designers appreciate the anxiety of having to input a credit card number or other format-varied content into input boxes.
  - fallous 7y ago
    Part of the problem is that inputs don't necessarily reflect the specific intent behind the use of certain symbols. For 99% of people using US keyboards when they input a dash in a credit card number they are using the exact same key as one would use for the minus when inputting a negative number. If you asked them to verbalize their inputs they would probably use different words for the same symbol, signifying that the meaning or intent isn't the same but even that isn't entirely reliable. You can attempt to infer intent or meaning based on the context of the input field but often the least-problematic method is to provide instruction/hints with the field, examples of correctness, and real-time validation with specific syntax errors when invalid or unexpected data is provided. I'd argue that it would also be worthwhile to request clarity from the user when an input hits a filtering rule so that they can make clear their intent... e.g. if you assume that they're using "-" as a symbol for separation rather than simply follow that assumption, ask if that's the case and list other optional valid contexts for that symbol so they can be explicit. If they choose None of the Above or a context that is inappropriate for the field, inform them of that. The 4-box credit card form, while pretty terrible in many ways, at least made explicit the expectations. Often we now hide the expectations and either auto-reformat what was put in the field (which can be surprising to the user or worse can modify their input to mean something other than what they intended) or do hidden filtering, which can have the same problems but doesn't even bother to inform the user of the changes.
    - DonHopkins 7y ago
      Not to mention that some countries use . as a decimal point and , as a digit grouping separator, and others do it the other way around.
      - bcrosby95 7y ago
        Yes, I'm rather glad I haven't had to deal with localizing decimal inputs, just displaying them. I have had to deal with localizing date inputs though. Ugh.
        7y ago
- joelanman 7y ago
  Important to note that in the article we mention we only use pattern to trigger the right keyboard in old iOS. We actually turn off HTML validation in favour of doing server side validation, we'll soon be publishing guidance on that too. Disclaimer - I work on the team.
  - OJFord 7y ago
    Disclosure* - you're claiming to be on the team, not disclaiming it.
  - andreareina 7y ago
    Why are you going to server-side only? I've always held that client-side validation is important for UX as it provides instant feedback and doesn't need any extra work to preserve the other data that's already been input. Obviously the inputs still need to be validated on the server e.g. to protect against things that get past (or bypass) the client-side checks, or perform more expensive validation.
    - joelanman 7y ago
      We'll be publishing soon on the GOV.UK Design System, but in summary we can't make browser validation consistent with our Design System, or guarantee it's always accessible. In our research it's commonly most often helpful to validate when the user submits as that's when you can be sure they're 'done'. There are cases when realtime helps so it's fine to add it in those situations.
- OJFord 7y ago
  It won't accept it.. in exactly the right way. Because you can't enter spaces, they don't get submitted, and validation doesn't fail. As long as they don't also do 'class="nopaste"' or whatever, we're golden!
dmix 7y ago
That's one of the reasons I love Stripe's checkout being used everywhere and designers elsewhere basically copying them. The internet is constantly getting better and I don't think we give that progress we've made in web design over the last few decades enough credit. Just imagine how bad it used to be to just purchase a simple thing on an ecommerce site in the mid 2000s. Or remember what car websites used to look like vs what they look like now. Even newspaper websites like NYT are leaders with quality design. It's easy to complain about those who still don't get it, but I feel like we've also made massive progress from the early wild-west days of the internet. Still, I'm all for shaming those sites who still make inserting credit card numbers a pain in the ass.
- BrianB 7y ago
  > Or remember what car websites used to look like vs what they look like now. lingscars.com ?
  - admax88q 7y ago
    This site is amazing.
  - frob 7y ago
    This might be the best website ever. It is over the top, but the theme is consistent. It reminds me of a myspace page, but if someone just wanted to be ridiculous, not unsightly. Side note: anyone remember "I knows me some ugly myspace" from Ze Frank?
    - aspenmayer 7y ago
      Ze Frank. Now there’s a name I haven’t heard in quite some time. What an early internet vlog pioneer. I wondered what happened to him and looked him up a while back. Turns out he’s some bigwig at BuzzFeed so I guess he made out okay, but part of me misses that early enthusiasm and wonder of early internet 2.0.
      - zimpenfish 7y ago
brlewis 7y ago
This may not be semantically pure, but I think type="tel" is a simple and ergonomic approach to credit card input. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/tel https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... EDIT: Also more widely supported than https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
- Wowfunhappy 7y ago
  I'm not against weird hacks where necessary, but how is this better than the GP's non-hacky suggestion? Inputmode isn't supported by most desktop browsers but it doesn't need to be. Every mobile browser save mobile Firefox supports it. ...I wonder what's up with Mobile Firefox?
  - brlewis 7y ago
    Using the same markup for desktop and mobile means less code which usually translates to fewer bugs.
    - Wowfunhappy 7y ago
      It would be the same markup. It just wouldn't do anything on desktop. Which is fine because desktops generally have physical keyboards. I apologize if you already know this, but to make sure we're on the same page: what "inputmode" does is tell phones to display the onscreen keyboard as a numpad, instead of a full set of QWERTY letters and numbers. Outside of a few edge-cases, you don't generally need that on desktop.
      - brlewis 7y ago
        TBH I went on autopilot looking at MDN's browser compatibility list. Also as a user of Firefox on Android I was interested in something that works there, but type="tel" doesn't behave any better. The only advantage to not using inputmode is getting rid of an HTML validator warning, so you're right.
jmiserez 7y ago
Also sites that accept a 07/21 expiration date but not 7/21. Even worse if they accept it but then say it's an invalid card.
DonHopkins 7y ago
I hate it when they have drop-down menu for entering your year of birth, so the older you are, the further you have to scroll, but only infants and toddlers can select the year they were born without scrolling. A non-numeric text field is so much easier, and you should also be able enter your birth year as Roman numerals (which is even easier for millennials).
- RandallBrown 7y ago
  I think you're joking about Roman numerals, but millennials birth years are anything but easy to type in as a Roman numeral. For example, my birth year of 1987 is MCMLXXXVII.
  - DonHopkins 7y ago
    Oh that's right, I meant post-millennials, who got a fresh start in MM.
    - xboxnolifes 7y ago
      Zoomers
- numpad0 7y ago
  Can’t you just type “1984” or “Alaska” while focused on the dropdown to select on modern browsers
  - smcl 7y ago
    Not on mobile
- saagarjha 7y ago
  Trying to change the system because millennials have it slightly easier than you is the most “ok boomer” thing I’ve seen today ;)
- mc3 7y ago
  Gen Z are the ones born on MM or later.
anonsivalley652 7y ago
Exactly. Good control UX should be very liberal in what it accepts and normalize it to whatever form they want. Same goes with editing, it should allow temporary invalidity (extra or fewer digits) turn red/disable submit and then return to green when fixed. Don't make hundreds to millions of users do extra work that could've been automated with a little more care.
gwillz 7y ago
Also, the expiry date should never be a date picker. I'm not trying to _choose_ a date, I'm just dumping the exact numbers from my card. I want to type, tab, type, tab, type, enter, and be done.
- mikro2nd 7y ago
  But wait! It gets worse: Date-of-birth fields where they use a date picker, and the default/starting date is today. I'm a bit older than the average HM demographic, so using a date picker to scroll back many years might take hundreds of clicks. Then I made a mistake (details long forgotten) and the whole thing reset and I had to start again. On the third time around I just quit.

deleted 7y ago

[deleted]

pwdisswordfish2 7y ago

To put it more succinctly and without unnecessarily referring to JavaScript semantics, type="number" is for quantities, not mere strings of digits. It's an unfortunate accident of the English language that both are commonly called ‘numbers’. We might not have had this confusion if some other language were the lingua franca of computing.

samatman 7y ago
You can't entirely avoid referring to JavaScript semantics here, type="number" is for values appropriate to represent and work with as IEEE 754 doubles. That covers a lot of ground, by design. But a 'number' it isn't.
- mjevans 7y ago
  float, floating, double, etc would have been better choices for that type... Though 'quantity' as described in another post still sounds the best given the sub 1 and add 1 buttons.
bobthepanda 7y ago
I mean, this could've been solved by the spec using type="quantity". Many languages have generic, ambiguous umbrella terms, it's the sloppiness of the spec picking one.
- alexis_fr 7y ago
  A sequence of numbers could be called, with a little approximation, a barcode. Which makes me wonder why credit cards don’t have an actual barcode to easily enter it on the computer.
jsjohnst 7y ago
The spec could’ve used type=“quantity” and there wouldn’t be as much or any confusion. Point being, blaming the language used for writing the spec, when you readily offered up a better alternative, feels misguided to me.
7y ago

robocat 7y ago

inputmode=”numeric” and inputmode=”decimal” have different quirks between Android and iOS. inputmode also acts differently on iPad and iPhone, and the keyboard shown varies from that for pattern=, and support for inputmode is missing from iOS11 (or iOS12?). Tread carefully! Note that type="number" is particularly horrible on iOS because it allows typing non-numeric values and then input.value just returns zero. Instead you must check input.checkValidity(), and perhaps use the CSS :invalid pseudo-selector to show the user that their entry is not valid. You cannot read the actual invalid value AFAIK on iOS (although you could simulate it by looking at key events, if you ignore selection and cut/paste). Data entry with HTML is one area where you really want a native app, and you can get severely burnt trying to use a WebView. I have wasted months dealing with a variety of quirks over the years trying to make time entry friendly in HTML: all solutions have terrible compromises, and different browsers act quite differently (and can have nasty bugs).

duxup 7y ago
Gah, that iOS issue is a nightmare.
thirty6degrees 7y ago
Those iOS issues with type="number" are really interesting – thanks for sharing. Support for inputmode was added in iOS 12.2, but initially it used the 'numeric keypad with punctuation' – is that what you mean by 'the keyboard shown varies from that for pattern='? iOS 13 updated this behaviour, so it now uses the 'correct' numeric keypad, without the punctuation keys. The pattern attribute is still provided in order to trigger the numeric keypad on older versions of iOS. Once traffic from older iOS devices drops off we'll likely remove it. There's a little more info here: https://github.com/alphagov/govuk-frontend/issues/1449 https://github.com/alphagov/govuk-frontend/issues/1449 (I work on the team)
- robocat 7y ago
  > iOS 13 updated this behaviour, so it now uses the 'correct' numeric keypad, without the punctuation keys The iPhone shows the 0-9 keyboard. The iPad shows the punctuation keyboard. This is not obvious, and one of the places where Mobile Safari acts differently between the two device types. Try jsbin.com/necuzoj

neves 7y ago

The main issue is that the numeric key pad, with larger buttons, are a lot easier to type (as predicted by Fitt's Law). We must allow they to automatically use this keypad without the confusing behavior of the <input type=number>

dylan-m 7y ago

That's a good rule of thumb there :) More pedantically, credit card numbers _aren't_ numbers in the first place. They are identifiers that happen to use numerical digits. Same as phone numbers. Treating them as numbers at any point in a system is an error. My dream is this detail of the HTML spec forces people to rethink their schema design while they're at it.

reaperducer 7y ago
See also: New England ZIP Codes, which can cause all kinds of problems.
- velosol 7y ago
  To save a search for those who might not know off the top of their head - New England is home to leading zero ZIP codes (e.g. 02122 for Boston).

gbersac 7y ago

I didn't knew you had an inputmode and pattern tag on the html input balise