So I have an existing HTML page that has a field for Last 4 digits of Credit Card:
<input value="" name="Last4ofCC" maxlength="4" id="Last4ofCC1">
Works great, but a feature request just came in to make it a numeric field and not allow non-numeric characters.
At first I thought of plugging in some Javascript, but then I thought, why not just use an HTML5 element. I changed to the following:
<input type="number" value="" name="Last4ofCC" max="4" id="Last4ofCC1">
But not only does it still allow non-numeric characters, the max attribute doesn't work either! I'm testing this on FireFox 8, so not sure what the problem is.
Does anyone know what I've done wrong here?
you need to include the proper doctype at the top of your page in addition to changing your input types.
<!DOCTYPE html>
However, it's not going to do what you think it's going to. Setting an input as a type="number" will pretty much only get you the spinners on the side and tell the form what it should be. If you want to ensure only digits are entered, you will need to do a regex, like /^\d+$/ on keyup.
More info on HTML5
Yes, you can add HTML5 features to existing pages. Browser support to them is, at least at present, independent of any doctype stuff you may or may not have at the start of your page.
It is, however, probably not a good idea to use type="number" for reading four digits. It is meant for reading numeric data, and it will happily accept 42 without requiring any more digits, for example. Moreover, the user interface may even confuse the user. But if you use type="number", you should in this case set min="0" and max="9999".
A better HTML5 construct is pattern="[0-9]{4}" required. It is supposed to run a check on the input, checking that it consists of exactly four digits. This is supposed to happen even when JavaScript is disabled.
Since browser support is still rather limited, it’s a good idea to use JavaScript checks, too, as a convenience to the user.
'max' indicates the maximum value allowed, not the maximum number of characters.
Jason's answer is mostly correct. However, you should not do validation on keyup unless the user needs additional help. I'm the author of h5Validate. In the process of improving conversion rates in a large production shopping cart, we discovered that users get confused if they see a validation error message while they're still trying to type the number.
h5Validate first runs validation on change, and if the value is invalid, it will add keyup to help the user correct the field with each keystroke. This seems like a minor nitpick, but the difference it makes measures in the millions of dollars per year in revenue for large scale shopping cart systems.
Nothing, as far as I know Firefox doesn't support those yet, http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29. Try Chrome to see the effect.
You can check out the latest form support for Firefox here (it's supposed to be support):
https://developer.mozilla.org/en/HTML/Forms_in_HTML
Also check out:
http://caniuse.com/#search=form%20validation
This jQuery plugin will add support for all browsers though. It's a safe approach that still uses HTML5 syntax:
http://ericleads.com/h5validate/
Good luck!
Related
In modern browsers the standard of autofill and autocomplete is to completely ignore autocomplete="off" for password fields that are placed in a form. And insert saved passwords, even if it's in a user management page. Although the reason is in the right place, it makes creating a user management page a huge pain.
My team's web application runs with angular 7 and currently only supports chrome. But there's a big possibility that we will need support other browsers like internet explorer, edge, firefox, etc.
I know this is a largely touched subject, and that I can find many questions with answers similar to this question (like this, or this). But every solution I've found so far has at least one big flaw.
What I've tried so far on chrome:
1) Use autocomplete="new-password"
It seems that chrome/chromium developers ignores even this for type="password".
2) Use type="text" autocomplete="new-password" with asterisk font family
This disables chrome from auto-filling the input field and hides the letters. But the big flaw is that the value is still there and can be copy-pasted in a different font family. The input field also loses the security of type="password" and any hacker can easily get the value.
3) Use -webkit-text-security
This is pretty much the same solution as the one before but this isn't even css standard and few browsers support it.
4) Replace value with *
This is the trickiest solution I've tried so far. When input value is changed I call a function in typescript that: Adds the new character to a local string, Change DOM value to * equal to the amount of characters, Return the locally saved value on (blur).
This leaves me with a large amount of problems to deal with including: Erasing any character in the string removes the last character always, In addition to the last problem the first character will always stay the same even if the value is completely erased, Having to know where in the string to remove characters.
This solution is less than ideal.
5) Disable password management for domain in browser settings
This really isn't a solution to the problem as it means that I expect the users to turn off password management for domain. It would also result in not saving the password on the login page as many users may need.
6) Randomise [name] and [autocomplete] values
By one way binding said values to a randomised string based on current time, I can ensure that the password field doesn't match any fields saved by the browser. Although many has reported that this works between all browsers, this doesn't seem to work for me at all when using chrome. For me chrome shows recommended password as long as the input is of type="password".
Solutions I've seen so far:
1) Use two input fields
This seems to me to work the same as my own solution 4). And will probably be just as troublesome to work with.
2) Use jQuery Disable Auto Fill Plugin
This seem to be very close to what I'm looking for but the problem is that it uses jQuery. All I can say is that I've been told that we're not using jQuery and that I probably won't be able to use the plugin directly.
I'm currently looking for a way to implement this using angular and would love any help or directions on this.
If you know of any solution that I haven't mentioned above, please post an answer or drop me a link in comments.
The best solution I've found so far is to use type="text" on password field and use autocomplete="off" on the form and every input field in it.
I won't mark this as an answer however as it still has the great flaw of losing the type="password" security functionality. Text fields also allows spell check which can be disabled with spellcheck="false". But I've read that it's possible to override this with browser settings.
This question will remain unanswered until a better solution is proposed.
TLDR: Which input type can utilize the mobile numeric keyboards AND implement masking with spaces injected and a max limit for CVV and Credit Card inputs, such as: XXXX XXXX XXXX XXXX
When building forms, I have seen a varied degree of consistency surrounding the correct input type for credit cards. Here are my discovered pros and cons for each:
type=text
Able to mask easily with various libraries such as cleave.js or set maxLength attribute
Mobile users do not receive numeric-only keyboard, unless setting range to [0-9] (Only iOS users will get this experience, leaving Android users with full keyboard)
type=number
Proper keyboard shown on iOS and Android but unwanted characters can be entered and no maxLength can be set. Min and Max do not limit users from inputting more than 16 characters but do provide error messages when over the max. *Note, this input type is basically ruled out due to leading 0's being deleted. (Unacceptable for CVV's)
type=tel
Able to properly mask and is utilized all over the place, BUT may have unknown impacts on accessibility programs and autofillers. If anyone can provide clarification on the potential side effects of using this input type, that would be awesome!
These are all the types that came to mind. If anyone has any other recommendations, please let me know!
HTML
If you're trying to do this strictly with HTML, I believe the following is going to get you about as close as is currently possible:
<label for="ccn">Credit Card Number:</label>
<input id="ccn" type="tel" inputmode="numeric" pattern="[0-9\s]{13,19}" autocomplete="cc-number" maxlength="19" placeholder="xxxx xxxx xxxx xxxx">
inputmode sets the keyboard type (in this case, numeric)
pattern enables validation (in this case, numbers and spaces with a length of between 13 and 19) and it helps with keyboard type for browsers that don't yet support inputmode
autocomplete tells browser what should be autocompleted (in this case, a credit card number)
maxLength prevents the user from entering more than the set number of characters (in this case, 19, to include numbers and spaces)
placeholder gives the user an example (formatting hint)
JavaScript
For a more robust solution, JavaScript is going to be required. And rather than roll your own solution, it'd probably be best to use a battle-tested library. Cleave.js (as you mentioned) is a popular choice.
I’ve seen using type="tel" on many places, for the reasons you mention.
I would not recommend type="number" as then you have to fiddle with in/decrement arrows etc. And from certain point of view it is not a “number” in terms of what we usualy do with numbers (maths), see this comment on CSS tricks forum.
Another trick how to force numeric keyboard is using pattern="[0-9]*". This should work on iOS only. To make it work on Android as well, you have to combine it with the type="tel".
There's an attribute inputmode that's designed for that, it's not implemented yet (actually deprecated in HTML 5.2), but there's work done on it (FF/Chrome).
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
And see this discussion:
https://github.com/whatwg/html/issues/3290
For now set the autocomplete attribute to the correct value:
https://developers.google.com/web/updates/2015/06/checkout-faster-with-autofill
or implement a customized input with mask like you're using now.
I have been asked to help fix a bug in a web application that is mostly python (running Flask) which is what I know and why I offered to help. However my HTML knowledge is very bad and I need help. I've fixed the bug in the python code, but I want to make sure the user can't find more ways to break the application. It has to do with the form in HTML where users input the time for a deal. The input is in text format with the placeholder 'hh:mm:ss' but that doesn't stop them from entering all kinds of things other than a time in that format. If I had done this from the beginning I would have made this field a 'time' format but too many things depend on it being a text field now that I would rather just set some validation on this text input field.
The piece of code is:
<input type="text" name="time_left" id="time_left" placeholder="hh:mm:ss">
The only restriction is that the time can't be less than 00:00:00 and it can't be more than 01:30:00. I would love to just put a min/max attribute in here somewhere but I doubt it's that simple. Especially with it being text.
Can anyone advise me what I can do (the simpler the better, as I say, I'm not very good with HTML)
For HTML5 only solutions, there are two ways. One is to make it a type="time" input. It's value can still be read with input.value as a string, if that's of any concern to you.
<input type="time" min="00:00:00" max="01:30:00">
Browsers will allow steps of 1 minute. If you need second precision, add a step="1".
The other solution is to add the pattern attribute:
<input type="text" pattern="0(1:30:00|1:[012][0-9]:[0-5][0-9]|0:[0-5][0-9]:[0-5][0-9])">
Both solutions are viable and each has its advantages and disadvantages.
The latter will have better browser support, but for support closer to 100% you will either way need a JS library that takes over from the browser. I wrote Hyperform, that would do that (and more), but if it's just this one field you might be better off writing your own event handler and attaching it to the change event of that input field.
Edit: The regexp in the pattern attribute will distinguish several cases separated by |. The first and simplest is the max time 01:30:00. The next are the times from 01:00 to 01:29:59, and finally the times from 00:00 to 00:59:59.
This has already been asked numerously and lots of examples have been provided, either with tons of JavaScript, or using the inputmode or the pattern attribute with some regex. However, none of these seem to work together with the numeric keyboard (at least not on my iPhone).
Therefore my question: is this impossible? (in plain and simple HTML5)
I need an <input> for currency with on-the-fly formatting, to edit numbers like this: 1,000,000.00 or, when changing the country, to 1 234 567,89 AND the numeric keyboard appears (important for mobiles). Notice the thousands separators.
Only HTML5 will not work today. (6-6-2016)
What you want is this:
<input type="text" pattern="your-pattern" inputmode="numeric">
However, inputmode is not supported in any browser yet.
The code above explained:
We can't use type="number" because the pattern attribute is not supported on that type, so we use type="text". A better choice might be type="tel" because it's also concerned with numbers and delimiters. However, I don't know the semantic implications of this (on SEO and screenreaders for instances). The safest approach is text
inputmode is new and allows you to specify what kind of input mode is required. Especially useful for mobile devices, as you can imagine
Considering you want to have on the fly conversion from one standard notation to another, you will have to use JavaScript so you can use it for your pattern validation if you really want to use a number type. Or maybe there is even another public API to control the keyboard through JS (but I doubt it, may cause security issues).
Finally, as always: if your validation is important, do it server-side. The client-side should never be trusted. (Even if they have cookies.)
I would like to automatically initiate the numeric keyboard on touch devices for zip code and social security number input fields. Zip codes are entered in a five digit format, while SSNs are entered as 111-22-3333. My understanding is that type=number and type=tel fields will automatically initiate the appropriate keyboard, so these inputs seem appropriate, but I'm not confident they are the right choice.
Type=Number
I originally thought type=number would be the optimal solution (since it sounds semantically correct), but have since found that this type is really only for true numbers and not strings of numeric characters. I've seen blog posts making accusations of browsers automatically including the comma as a thousands separator, and stripping leading zeros on submission (neither of which are zip/ssn friendly).
Type=Tel
From what I have read, this seems like the best solution to my problem. I'm concerned by the meaning of this new type though. Should I really be using a telephone field for zip code and ssn? What if some mobile phone manufacturer decides to start showing the address book for tel fields? That would make no sense for a zip or ssn.
Alternatives
I've found that the new pattern attribute of type=text inputs can be used to trigger the numeric keyboard on iOS devices, but that only partially solves the problem.
I've also found a new attribute inputMode which seems to be the ideal solution, but doesn't seem to be implemented by any browsers yet.
The Question
What I'm hoping is that someone has a suggestion or a best practice? Should I use TEL? Should I go with the iOS solution and ignore other devices? Will inputMode ever work?
My suggestion is to use pattern and inputMode only.
Additionally, Type = number is acceptable if you are only accepting integers between 0-999 and you are okay with the extra validation that will be done - even if the user clicks cancel.
Type=Number has issues even if it is a number, let alone a SSN etc, as it has unpredictable handling of values with regard to negative numbers, localization, precision, leading zeroes, etc, depending on the browser's implementation. Best practice is to avoid unless you have an internal website with a fixed user base where you know the devices/locales being used - unless you are expecting an integer between 0 and 999. Negative numbers, decimals, and thousand characters all will have problems on certain devices.
In addition, if you use 'type' the page will validate data even if the user clicks a cancel button. You could globally turn off validation, but now the page will auto-delete any invalid data on post back! If either of these are acceptable to you, you can use 'type'.
Type=Tel works 'today' but as you point out, it is dangerous to use as who knows what browsers will do in the future. Not to mention that '122-222-2223 Ext.34' isn't even accepted by these devices. I would advise caution if it is a phone number, and avoidance otherwise. The day may come that some device decides to validate the number even though the HTML5 specs say not to.
Pattern=... is good to add. Most browsers will ignore it, so use another validator as well, but at least newer iOS devices will use it, and that's 45% of mobile users.
InputMode=... seems to be the only other hope at this time. Hopefully it will get supported in the future.