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).
Related
When you copy then paste the string “word”, macOS sometimes inserts “word” (unchanged), “ word”, “word ”, or “ word ”, depending on what you’re pasting it next to, whether it thinks you copied it as a word or as a range, and whether you’re pasting into a writing input (like a note in the Notes app) or a string input (like Safari’s URL bar). Click-and-dragging to select results in a range copy, double clicking results in a word copy.
On macOS, Safari and Chrome perform automatic space insertion in all inputs, while Firefox performs it in none. Firefox also does not follow the native behavior for double clicking a word, right clicking a word, or copying a word.
You can play with the behavior with the following demo. Try double clicking a word then pasting it multiple times, then try selecting a word by dragging then pasting it multiple times.
<div>one two three</div>
<input>
Automatic space insertion is probably fine and intuitive for macOS users, but is sometimes inappropriate for the same reason it’s inappropriate in Safari’s URL bar: some contexts are not in English or any other written language. In these contexts, automatic space insertion leads to surprising results. For example, I ran into this issue when entering input in a micro-language of the form [field.{id}], then pasting an ID, which was copied as a word, then getting [field. {id}] and the error that it caused.
Ideally, I want to instruct the browser not treat an input’s value as writing. Minimally, I want to turn off automatic space insertion an inputs. How can I do this?
Things I’ve tried that didn’t work:
Setting lang="" or lang="none" on both the input and the copied text
Setting lang="zh" on both the input and the copied text (Chinese languages do not use spaces between words)
Setting spellcheck="false" on the input
Setting autocorrect="off" on the input (non-standard, Safari only)
One solution is to cancel then mimic the paste event in JS.
<input id="example">
document.querySelector('#example').addEventListener('paste', e => {
e.preventDefault();
const pastedText = e.clipboardData.getData('text/plain');
document.execCommand('insertText', false, pastedText);
});
This solution has the following limitations:
Requires JS
Does not also disable other writing-specific niceties, if any exist
Uses the deprecated document.execCommand API
I have a html textbox in my webpage. I am able to enter a Euro symbol using Alt0128 in the text box, But on another keyboard , we use Altgr + e to enter the Euro symbol, But I am not able to use this combination on that keyboard to enter a euro symbol in the html textbox. Is there some attribute i need to add for the same ?
this is my text box:
</td>
<td class="contentCell" colspan="3" ">
[#txt|txtmyBox#]
</td>
The effect of things like AltGr E depends on the keyboard driver (keyboard setup), not on your HTML code. You might be able to interfere using JavaScript, recognizing which keys were pressed, but this could be very risky. For all that we can now, AltGr E may have any meaning in a user’s keyboard, and making it produce something different could be very confusing (and might prevent the user from typing what he wants to type).
In principle, HTML5 drafts propose an inputMode attribute that could affect the keyboard setup, but probably only on touch screens. And it has not been implemented, and the current drafts don’t have anything related to typing currency symbols.
What you could do without disturbing keyboard settings is to add a button on the page, with “€” on it, so that clicking on that buttom appends the euro sign to the input value. This would be rather straightforward to do in JavaScript.
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.
I'm building an HTML page to be viewed in mobile Safari [and other platforms]. The page lets the user specify several start and end times. They have to input at least two times, and possibly more depending on their situation.
I want the user to be able to input their times as numbers and punctuation using the numeric-SHIFT mode keyboard, i.e. the user will see fields like this:
And they'll get the numeric-SHIFT keyboard when they focus into the field:
Won't work:
<input type="time"> (and related datetime types) is not an option. The scrolly-wheel is unacceptable from an HCI perspective, particularly for repeated entries.
<input type="number"> does the right thing at first. It triggers the keyboard in numeric-SHIFT mode, i.e. the numeric & punctuation portions are visible by default. But when you exit the field, mobile Safari strips out punctuation (i.e. the colon). I tried turning off validation in the form using novalidate but that didn't work.
<input type="text" pattern="[0-9]*"> triggers the telephone keyboard with no way to enter the colon character.
I may just need a different RegExp in the PATTERN attribute, but each one I've tried triggers the normal alpha keyboard, and the user has to hit a key to get to the numeric-SHIFT keypad.
Can anyone tell me how to force the keyboard into numeric-SHIFT display without triggering harsh validation rules on the user's input?
Take a look at jQuery Mobile DateBox. here. Its possible you might want to rethink text input here. Maybe you want to go with a picker. Sencha Touch also has a DatePicker. I wrote an extension that implements a timepicker object. I'll throw it up on GitHub if you need me to.