As a number can be negative or with floating point, so the - and . and , should be available in the keyboard, unless you specify a digits only pattern.
In my experience, this is very inconsistent across browsers. iOS has gone back and forth between supporting this correctly for my use case. I generally just want the default displayed keyboard to be the numeric one. The last time I checked, using input type="number" correctly brings up the numeric keyboard, but the "size" attribute is ignored, which throws off my mobile format badly. I added an attribute to all inputs that I'd prefer the numeric keyboard to use by default, and I used jQuery to change any attributes (i.e. type="number") when the browser detects as one that works correctly. That way I don't have to go back through and update the individual inputs and allows me to only apply it in supported browsers.
It would be lovely if the major mobile O/S's would have an attribute for "default keyboard" aside from the input type. What if a user is entering an address or zip code? Generally those start with numbers, so showing the number keyboard by default, but allowing ANY text, is helpful.
As far as validation, I can't rely on the browser to support validation for the specific input types, so I use javascript and server-side validation.
Greetings. I know this question is old but I felt it's a very sought after solution and decided to post an answer.
Here's a solution I've created to address the iPad keyboard as well as pretty much anything.
Also, this approach does not require you to use input of type number which in my humble opinion is very ugly.
Below, you may find a working version.
Thoughts on Apple iPad keyboard keys...
I had to create a keyPress event handler to capture and suppress keys on the iPad that don't seem to be handled by the keyDown event or are ambiguous???!
// Bind keydown event to all input type=text in form.
$("form input[type=text]").keydown(function (e) {
// Reference to keyCodes...
var key = e.which || e.keyCode;
// Reference to shiftKey...
var shift_key = e.shiftKey;
// Reference to ctrlKey...
var ctrl_key = e.ctrlKey;
// Reference to altKey...
var alt_key = e.altKey;
// When user presses the shiftKey...
if(e.shiftKey) {
//...supress its click and whatever key follows after it.
console.log(e.shiftKey + ' and ' + key + ' supressed.');
// Deny
return false;
// ONLY Allow Numbers, Numberpad, Backspace & Tab
} else if ( (key >= 48 && key <=57) || (key >= 96 && key <=105) || (key >= 8 && key <=9) ) {
// Allow
return true;
} else {
// Deny every other key and/or shift + key combination NOT explicitly declared.
return false;
}
});
// KeyPresss to handle remaining iPAD keyboard keys!
// These keys don't seem to be handled by the keyDown event or are ambiguous???!
// Bind keypress event to all input type=text in form.
$("form input[type=text]").keypress(function (e) {
// Reference to keyCodes...
var key = e.which || e.keyCode;
// Reference to shiftKey...
var shift_key = e.shiftKey;
// Reference to ctrlKey...
var ctrl_key = e.ctrlKey;
// Reference to altKey...
var alt_key = e.altKey;
switch (key) {
// Character -> ^
case 94:
return false;
// Character -> #
case 35:
return false;
// Character -> $
case 36:
return false;
// Character -> @
case 64:
return false;
// Character -> &
case 38:
return false;
// Character -> *
case 42:
return false;
// Character -> (
case 40:
return false;
// Character -> )
case 41:
return false;
// Character -> %
case 37:
return false;
// Character -> !
case 33:
return false;
}
});
This prevents the user to write wrong characters by replacing the value with the previous one if there is a validity error (I dont't know if this is an iOS object or standard)
beware I did't test this code snippet because I have more complex stuff around on my side but I hope you will get the idea
With this solution :
On iOS : the user has a full classic keyboard but opened by default on the numbers and can't write wrong characters.
On Android, the number keyboard is perfect.
In the future we can hope that iOS will trigger the good keyboard for numbers and that the javascript part will never be called.