I have a form which contains a lot of individual fields which contain numeric values. The issue I have is that on an iPad the on-screen keyboard is split between an alphabetic and numeric one like so:
The issue is that when switching between each individual form field, the iPad reverts to the alphabetic keyboard which is not disastrous but definitely inconvenient for the end user. Is there anything I can do to tell iPad which keyboard to show for a specific input type or some other way of keeping the numeric keyboard for certain form elements?
I'm specifically referring to developing for the web and not iOS apps. I'm sceptical and so far Googling has not brought up any results but I wonder if there is an input type that iPad might recognise as numeric automatically.
Change your input type. Instead of using a text input try one of the following to bring up the special keyboard (note: this is not unique to the iPad). This is going to be device-dependent and be supported depending on the device used.
<input type="number">
Shows the number pad
<input type="email">
Shows the text pad with the # symbol
<input type="url">
Shows the text pad with the .com button (if available)
<input type="text">
Shows the standard text pad
Use HTML5 field types
Change the field type:
<input type="text" name="SomeField">
To:
<input type="number" name="SomeField">
This should make the iPad and phones default to the numeric input pad.
http://www.w3schools.com/html/html5_form_input_types.asp
I found the specs for the HTML autocomplete attribute here:
http://www.w3.org/Submission/web-forms2/#the-autocomplete
But it doesn't mention when it is applied to. It seems like when it is on, then that means a user can press the Back and Forward button of the browser and the data will be kept in the input text box, or if the user chooses a history item using the Back and Forward button area. And when it is off, that means the data should not be kept in the input box.
And it is not about:
the history window bringing a page back (after clicking on a history item)
any bookmark bringing a page back
typing in the same URL in the browser
suggestion, such as when a user typed in "macbook" before, now the user types in "mac", and it tries to suggest "macbook" either just inside the input box (but with the "book" part highlighted so the user can keep on typing, or by showing an extra pop up box down under the input text box, for a list of suggestions.
since any time a user exits the browser, for what is known as a "session end", then by (1) to (4) above, there is no way that the data will follow the autocomplete="on" behavior.
Is this the exact behavior of autocomplete? (any pointers to a more exact spec will be appreciated).
I made a static webpage and tried it on a Macbook locally using Apache and localhost://try.html, but the basic behavior can be tested here:
http://jsfiddle.net/jzNTM/3/
http://jsfiddle.net/jzNTM/4/
Autocomplete: Should the browser remember answers for the given field. (number 4 in your list)
autocomplete="on" is the default
Say you have a social-security-number input field
<input name="ssn" placeholder="xxx-xx-xxxx" />
If I enter 555-55-5555 the browser will remember that answer
If I (or anyone else) comes back to the form later and start to type "5" into the field, the browser will auto-complete / auto-suggest "555-55-5555"
For something sensative like a SSN, this is probably most undesireable. (great way to harvest personal data from a public computer)
Adding autocomplete="off" to the input (or form) will prevent the browser from remembering entered values
<input name="ssn" placeholder="xxx-xx-xxxx" autocomplete="off" />
I have an html5 number input: <input type="number" />
I would like it to accept fractions and mixed numbers, such as 38 1/2 as well as whole numbers and decimals.
I parse the fractions server side.
Currently, when the input loses focus, the browser changes the input to 38.
A current workaround is using a plain text input, but I would like the benefits of using type="number" such as specific keyboards on mobile.
The <input type="number"> element is defined to create a browser-dependent browser-locale-dependent input control for entering numbers. There is no way to change this in your document, except in the sense that you can use attributes to specify the range and precision. So a browser could accept 38 1/2 and convert it internally to 38.5, but there is no way to say that it should, still less force it to do so. Moreover, the internal format of the numbers (as passed to the server) is defined strictly; it cannot be 38 1/2 for example.
So you need to use plain text input or some special widget (programmed in JavaScript). You can use the pattern attribute to specify the allowed format somehow, at least the allowed set of characters; this may or may not affect the on-screen keyboard displayed on touch devices (it probably won’t, for current devices).
We recently ran into the same issue.
Our goals were ...
Allow users to enter fractions, decimals, and integers on all devices
Display the numeric keyboard on mobile devices
If we simply used type='number', most desktop browsers would prevent us from entering the slash character. In mobile Safari, we were able to enter a slash (e.g., 2/3), but the browser converted the value to an empty string since it wasn't strictly numeric.
Our solution has been to temporarily change the input type to number for devices that we want to display the numeric keyboard.
Our solution looks like:
var elmInput = document.getElementById("elmID");
if (/(iPad|iPhone|iPod|Android)/g.test(navigator.userAgent)) {
elmInput.setAttribute("type", "number");
elmInput.focus(); // brings up numeric keyboard
setTimeout(function () {elmInput.setAttribute("type", "text"); }, 200);
}
We have tested on several iOS devices, and we are seeing the intended behavior. Obviously, this solution is limited to these devices. Also, in the unlikely event that the user submits the form in less than 200 milliseconds, he will run into the empty string problem previously mentioned.
Our situation is obviously unique since we're only dealing with one element that we can trigger focus. However, a similar approach could work by using a CSS class selector. You could set type to number for mobile devices, and then change back to text when focused.
autocomplete="off" is not what I am after. Basically, on my registration form there are fields "phone" and "password" placed one above the other. (see screenshot)
The "phone" field gets, annoyingly, prepopulated with a username, as I guess what the browser is doing - the browser finds a field of type password and assumes the text input field just before it is a username field. The effect is this:
Why I am not interested in the non-standard autocomplete attribute for the phone field, is that I do want user to be able to fill this form as easily as possible and if they have previously entered their phone number on other sites (into fields called "phone") they could benefit from this showing up as they start typing into the field. That's why I don't want to turn autocomplete off altogether.
I was thinking more in the direction of reorganizing the fields somehow to avoid this behaviour. Or some way of telling the browser that the field above the password field has nothing to do with it, or that the password field is not used for authentication purposes. Somehow mark it as that. Or inject some invisible element inbetween these two fields?
Any ideas?
Markup used:
<input id="phone" name="phone" type="text" value="" maxlength="30">
<input id="newPassword" name="newPassword" type="password" value="" maxlength="20">
I am getting this behaviour on Chrome, FF, (not sure about IE, got an archaic version of that on my machine, don't even want to start worrying about IE yet.)
Most password managers will search the first password field, and the closest text field before it.
So all you have to do is add invisible text and password fields (display:none) above "new password".
Firefox tries to interpret 3 password fields as a "change password" action, so if you don't want that you should be safe adding yet another invisible password field.
I had a similar issue with the set password field. Try
<input type="password" autocomplete="new-password">
From MDN input documentation:
autocomplete
This attribute indicates whether the value of the control can be automatically completed by the browser.
Possible values are:
....new-password: A new password (e.g. when creating an account or changing a password)
For the phone number issue, I set this and it stopped autocompleting the username there.
<input type="tel">
A home number cannot be 30 characters, this is probably why the browser is assuming it could be a username or login email due to the size. Change it to something real and see what happens.
Also, consider having 3 field for phone number, area code, prefix, suffix. Once a certain number of digits are filled, you can auto focus using JavaScript the next phone segment field so it's easier for user.
Have you also tried changing positions of fields? What's happened?
Also, just to make sure, you can turn off auto complete on a particular item during registration without worrying that it will be off during login (cuz it won't) unless you turned it off for the login fields as well, and of course you have no need to.
Also, delete your unused saved form auto complete stuff, could just be a local issue with your version, you may have entered a bad value one day in one of the browsers, and then you installed the other browser (chrome or FF), and then the newly installed browser copied the rules exactly as they were from your original browser.... So, you end up thinking it's a global issue with your form, simply because of one bad entry and because your second installed browser copied and replicated the bad entry rule from your first browser, making it look like a real, universal problem to you, get me? So try the browsers InPrivate modes, or try the browsers from a different installation or a different computer, or from a virtualpc instance you may have.
Otherwise, export all your setting from your browsers and uninstall both browsers, then reinstall from scratch FF and chrome, then test your webpage, then feel free to import your exported settings back.
Also, test on IE even if it is for the insight it may give you, know what I mean?
Hope this helps, let me know how you get on, and if you have any other questions.
UPDATE:
Given the method you've chosen, what you should be able to do is, when rendering the phone field, add a value=" " attribute into the input tag, instead of using JavaScript. This should prevent the pre-filling from occuring without needing to use javascript. Now, if you want to go one step further, you can do this:
During the OnLoad Event of when page loads, check the phone field using JavaScript, and if the value equals one space (" ") then overwrite it with an empty string using JavaScript once onLoad is triggered. Or, if the browser is still prefilling (i doubt it will but if it is) you can delay this check by a few hundred milliseconds and run the javascript a few hundred milliseconds after the page has loaded, or tie it to all or some of the input fields onFocus events, so as soon as any of the fields gain focus, you do the "does phone.value equals one space character (" ") and if it does, overwrite it with and empty string, i'm even more certain the browser isn't going to jump in and hijack that field in this situation. Although, as mentioned, even if you do this onLoad, i doubt the browser will hijack your field, as the pages/javascript onload occurs AFTER the browsers internal onLoad (DocumentComplete) event occurs, and worst case scenario, you can do the few hundred millisecond lag or onFocus method, but i doubt you will need these.
Let me know how it goes.
I tried disabling the input fields type=text& type=password after loading of the DOM then enabled all the disabled fields after certain milliseconds lets say 100. It seems to be working for me.
Try :
$(document).ready(function()
{
$("input[type=text],input[type=password]").prop('disabled','disabled');
$("body").delay(10,function(){
$("input[type=text],input[type=password]").prop('disabled','');
});
});
In Windows 7, you can configure keyboards so that you can type in different languages. To switch "virtual" keyboards, you have to click the little icon in the task bar and select the language in which you want to type.
I have two text boxes on a page, one is for typing English letters and the other is for typing Korean Hangul and Hanja. I would like users to be able to click into one, type English, and click in the other and type Korean without having to switch keyboards in the task bar (or optimally without even having alternate keyboards set up). The user will be switching languages often, so it will be highly inconvenient to have to switch manually every time.
Is there a way to specify for a certain textbox that you want the keyboard for that textbox to be a specific one?
In theory there is a CSS property called ime-mode which should let you control the behavior of input tags:
<input id="english" style="ime-mode: disabled">
<input id="korean" style="ime-mode: active">
The problem is, browser support is very limited (at least that is what MDN says) and it might not just work for certain web browser/Operating System combinations (i.e. won't run on Linux).