D Input Modes

The attribute inputMode provides a hint to the user agent to select an appropriate input mode for the text input expected in an associated form control. The input mode may be a keyboard configuration, an input method editor (also called front end processor) or any other setting affecting input on the device(s) used.

Using inputMode, the author can give hints to the agent that make form input easier for the user. Authors should provide inputMode attributes wherever possible, making sure that the values used cover a wide range of devices.

D.1 inputMode Attribute Value Syntax

The value of the inputMode attribute is a white space separated list of tokens. Tokens are either sequences of alphabetic letters or absolute URIs. The later can be distinguished from the former by noting that absolute URIs contain a ':'. Tokens are case-sensitive. All the tokens consisting of alphabetic letters only are defined in this specification, in D.3 List of Tokens (or a successor of this specification).

This specification does not define any URIs for use as tokens, but allows others to define such URIs for extensibility. This may become necessary for devices with input modes that cannot be covered by the tokens provided here. The URI should dereference to a human-readable description of the input mode associated with the use of the URI as a token. This description should describe the input mode indicated by this token, and whether and how this token modifies other tokens or is modified by other tokens.

D.2 User Agent Behavior

Upon entering an empty form control with an inputMode attribute, the user agent should select the input mode indicated by the inputMode attribute value. User agents should not use the inputMode attribute to set the input mode when entering a form control with text already present. To set the appropriate input mode when entering a form control that already contains text, user agents should rely on platform-specific conventions.

User agents should make available all the input modes which are supported by the (operating) system/device(s) they run on/have access to, and which are installed for regular use by the user. This is typically only a small subset of the input modes that can be described with the tokens defined here.

The following simple algorithm is used to define how user agents match the values of an inputMode attribute to the input modes they can provide. This algorithm does not have to be implemented directly; user agents just have to behave as if they used it. The algorithm is not designed to produce "obvious" or "desirable" results for every possible combination of tokens, but to produce correct behavior for frequent token combinations and predictable behavior in all cases.

First, each of the input modes available is represented by one or more lists of tokens. An input mode may correspond to more than one list of tokens; as an example, on a system set up for a Greek user, both "greek upper" and "user upper" would correspond to the same input mode. No two lists will be the same.

Second, the inputMode attribute is scanned from front to back. For each token t in the inputMode attribute, if in the remaining list of tokens representing available input modes there is any list of tokens that contains t, then all lists of tokens representing available input modes that do not contain t are removed. If there is no remaining list of tokens that contains t, then t is ignored.

Third, if one or more lists of tokens are left, and they all correspond to the same input mode, then this input mode is chosen. If no list is left (meaning that there was none at the start) or if the remaining lists correspond to more than one input mode, then no input mode is chosen.

Example: Assume the list of lists of tokens representing the available input modes is: {"cyrillic upper", "cyrillic lower", "cyrillic", "latin", "user upper", "user lower"}, then the following inputMode values select the following input modes: "cyrillic title" selects "cyrillic", "cyrillic lower" selects "cyrillic lower", "lower cyrillic" selects "cyrillic lower", "latin upper" selects "latin", but "upper latin" does select "cyrillic upper" or "user upper" if they correspond to the same input mode, and does not select any input mode if "cyrillic upper" and "user upper" do not correspond to the same input mode.

D.3 List of Tokens

Tokens defined in this specification are separated into two categories: Script tokens and modifiers. In inputMode attributes, script tokens should always be listed before modifiers.

D.3.1 Script Tokens

Script tokens provide a general indication the set of characters that is covered by an input mode. In most cases, script tokens correspond directly to Unicode Scripts (see http://www.unicode.org/Public/UNIDATA/Scripts.txt). Some tokens correspond to the block names in Java class java.lang.Character.UnicodeBlock (see http://java.sun.com/j2se/1.4/docs/api/java/lang/Character.UnicodeBlock.html; see also Unicode Block names at http://www.unicode.org/Public/UNIDATA/Blocks.txt). However, this neither means that an input mode has to allow input for all the characters in the script or block, nor that an input mode is limited to only characters from that specific script. As an example, a "latin" keyboard doesn't cover all the characters in the Latin script, and includes punctuation which is not assigned to the Latin script. The version of the Unicode Standards that these script names are taken from is 3.2.

Input Mode TokenComments
arabicUnicode script name
armenianUnicode script name
bengaliUnicode script name
bopomofoUnicode script name
brailleused to input braille patterns (not to indicate a braille input device)
buhidUnicode script name (Unicode 3.2)
canadianAboriginalUnicode script name
cherokeeUnicode script name
cyrillicUnicode script name
devanagariUnicode script name
ethiopicUnicode script name
georgianUnicode script name
greekUnicode script name
gujaratiUnicode script name
gurmukhiUnicode script name
hanUnicode script name
hangulUnicode script name
hanunooUnicode script name (Unicode 3.2)
hebrewUnicode script name
hiraganaUnicode script name (may include other Japanese scripts produced by conversion from hiragana)
ipaInternational Phonetic Alphabet
kannadaUnicode script name
katakanaUnicode script name (full-width, not half-width)
khmerUnicode script name
laoUnicode script name
latinUnicode script name
malayalamUnicode script name
mathmathematical symbols and related characters
mongolianUnicode script name
myanmarUnicode script name
oghamUnicode script name
oriyaUnicode script name
runicUnicode script name
sinhalaUnicode script name
syriacUnicode script name
tagalogUnicode script name (Unicode 3.2)
tagbanwaUnicode script name (Unicode 3.2)
tamilUnicode script name
teluguUnicode script name
thaanaUnicode script name
thaiUnicode script name
tibetanUnicode script name
userSpecial value denoting the 'native' input of the user (e.g. to input her name or text in her native language).
yiUnicode script name
oldItalicUnicode script name
gothicUnicode script name
deseretUnicode script name
hanjaSubset of 'han' used in writing Korean
kanjiSubset of 'han' used in writing Japanese
simplifiedHanziSubset of 'han' used in writing Simplified Chinese
traditionalHanziSubset of 'han' used in writing Traditional Chinese

D.3.2 Modifier Tokens

Modifier tokens can be added to the scripts they apply to more closely specify the kind of characters expected in the form field. Traditional PC keyboards do not need most modifier tokens (indeed, users on such devices would be quite confused if the software decided to change case on its own; CAPS lock for upperCase may be an exception). However, modifier tokens can be very helpful to set input modes for small devices.

Input Mode TokenComments
lowerCaselower case (for bicameral scripts)
upperCaseupper case (for bicameral scripts)
titleCasetitle case (for bicameral scripts): words start with an upper case letter
startUpperstart input with one upper case letter, then continue with lower case letters
digitsdigits of a particular script (e.g. inputMode='thai digits')
symbolssymbols, punctuation (suitable for a particular script)
predictindicates that text prediction should be switched on (e.g. for running text)

D.4 Relationship to XML Schema pattern facets

User agents may use information available in an XML Schema pattern facet to set the input mode. Note that a pattern facet is a hard restriction on the lexical value of an instance data node, and can specify different restrictions for different parts of the data item. Attribute inputMode is a soft hint about the kinds of characters that the user may most probably start to input into the form control. Attribute inputMode is provided in addition to pattern facets for the following reasons:

  1. The set of allowable characters specified in a pattern may be so wide that it is not possible to deduce a reasonable input mode setting. Nevertheless, there frequently is a kind of characters that will be input by the user with high probability. In such a case, inputMode allows to set the input mode for the user's convenience.

  2. In some cases, it would be possible to derive the input mode setting from the pattern because the set of characters allowed in the pattern closely corresponds to a set of characters covered by an inputMode attribute value. However, such a derivation would require a lot of data and calculations on the user agent.

  3. Small devices may leave the checking of patterns to the server, but will easily be able to switch to those input modes that they support. Being able to make data entry for the user easier is of particular importance on small devices.

D.5 Examples

This is an example of a form for Japanese address input. It is shown in table form; it will be replaced by actual syntax in a later version of this specification.

Family namehiragana
(in kana)katakana
Given namehiragana
(in kana)katakana
Zip codelatin digits
(in kana)katakana
Emaillatin lowerCase
Telephonelatin digits
Commentsuser predict