inputmode

Draft Community Group Report,

This version:
https://raw.githubusercontent.com/dtapuska/inputmode/master/index.html
Issue Tracking:
GitHub
Editor:
(Chromium)

Abstract

This standard describes an attribute that is applicable to fields that have an editing capability. Most modern virtual keyboards allow customization and this brings a redefinition of the inputmode attribute to modernize it.

Status of this document

This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

1. Introduction

This section is non-normative.

iOS and Android platforms have provided the ability for native apps to customize which virtual keyboard is provided during editing. Web authors have requested the same richness on the web platform. xhtml inputmode was originally specified in the XHTML Basic standards and over time inputmode migrated into the HTML5 specification. The parameter is not implemented by any major vendor and a number of the properties do not make sense with today’s keyboard properties. This standard is about respecifying the attribute values and permitting it’s use on editing-host elements.

2. inputmode.

The inputmode content attribute is an enumerated attribute with the following keywords:

The inputmode SHALL be implemented on all editing-host elements and form controls.

The user-agent is free to choose the missing value default based on contextual information. For example if the virtual keyboard appears on an element contained inside a form control of type tel, email or url it MAY wish to use an appropriate default for each. none indicates that no virtual keyboard SHOULD be shown.

3. Internationalization

decimal SHALL show a keyboard with the appropriate locale separator.

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[ENCODING]
Anne van Kesteren. Encoding Standard. Living Standard. URL: https://encoding.spec.whatwg.org/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119