[Bug 12409] New: Automatic capitalization in input fields

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12409

           Summary: Automatic capitalization in input fields
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: eoconnor@apple.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


In some cases web authors may want to specify a type of auto-capitalization
behavior on form controls. This is not a style transformation of the input
like CSS's "text-transform: capitalize". It is a semantic description of
the type of data that will be input into the field. This attribute may
allow a user agent to provide a better user interface for inputting text
into that field. Some use cases would be:

  Hinting to a user agent in a "name" form field that each word should be
  capitalized by default. Ex. "Jane Doe"

  Hinting to a user agent in a "comment" text area that each sentence
  should be capitalized by default. Ex. "Great proposal. I agree!"

  Hinting to a user agent in a captcha form field that no assumptions
  should be made about the capitalization of characters. Ex. "CaPcHa"

  Hinting to a user agent in a "state" form field that each character
  should be capitalized by default. Ex. "NY", "CA"

Given these use cases a user agent may decide to:

  Automatically enable or disable a "shift" key, or make some other
  behavioral or content change to a software keyboard to more easily
  input capital or non-capital letters.

Our proposed solution is to add an "autocapitalize" attribute to form
controls. iOS form controls have had an "autocapitalize" attribute since
iOS 1.1.1. It is documented and described at [1][2][3]. This make sense
to standardize in HTML5.

As documented at [1][2][3] in earlier iOS releases there are two valid
values, "on" and "off". In reality, if the attribute is present then only
"off" is checked and all other values are assumed to be "on". This allows
markup like "<input autocapitalize>", to map to the "on" state.

There are better, more descriptive states than just "on" and "off", but
those values should be considered for backwards compatibility but are not
strictly necessary. "on" and "off" can be aliases to more descriptive
values, shown below. Proposed enumerated values [4] are:

  - "none" ("off") - no capitals are expected
  - "sentences" ("on") - each sentence is expected to start with a capital
  - "words" - each word is expected to be capitalized
  - "characters" - all characters are expected to be capitalized

  - omitted / missing attribute for form controls is a `default` [5] state
  - all unrecognized but present values fall back to "sentences" ("on")

More enumerated values can be specified in the future if new
auto-capitalization behaviors are desired. These proposed states offer
backwards compatibility with previously shipped browsers which already
implement the "autocapitalize" attribute, and a sensible fallback
value for unrecognized values.

Web authors should be able to provide default auto-capitalization
behavior for all inputs in a form. Accordingly, the "autocapitalize"
attribute of the <form> element will determine the default
auto-capitalization behavior for all elements associated with that form.
This affects the state of containing form controls in the same way that
it does for "autocomplete"; described at [5].

For example, in the following form the "first-name" and "last-name" input
fields would respect the form's default autocapitalize behavior of
"words". The "username" field has a more specific "none" behavior, the
"state" field has a more specific "characters" behavior, and the
"comment" field has a more specific "sentences" behavior.

NOTE: this behavior is not well documented but is the behavior of shipped
iOS browsers. It is also how "autocomplete" is specified.

  <form autocapitalize="words">
    First Name: <input name="first-name">
    Last Name: <input name="last-name">
    State: <input name="state" autocapitalize="characters">
    Username: <input name="username" autocapitalize="none">
    Comment: <textarea name="comment" autocapitalize="sentences"></textarea>
  </form>

This would be equivalent to:

  <form>
    First Name: <input name="first-name" autocapitalize="words">
    Last Name: <input name="last-name" autocapitalize="words">
    State: <input name="state" autocapitalize="characters">
    Username: <input name="username" autocapitalize="none">
    Comment: <textarea name="comment" autocapitalize="sentences"></textarea>
  </form>

The proposed default values for autocapitalize on form controls are:

  - "sentences" ("on") on <form>
  - "none" ("off") on <input type="password">
  - `default` on other form controls <input>, <textarea>, ...

We propose allowing the "autocapitalize" attribute on both form controls
and editing hosts (for "contenteditable" content). This would be
equivalent to how the "spellcheck" attribute is handled [6].

Note that this attribute's implementation is very similar to the
"autocomplete" attribute already specified in HTML5 [7]. Differences
include:

  - "autocapitalize" has more enumerated values than just "on" / "off"

  - "autocapitalize" should be "off" by default on password fields to
    prevent accidental automatic capitalization in a user's password.
    However, this might be worthwhile to add to "autocomplete" as well.

  - "autocapitalize" should be allowed on "contenteditable" content.
    However, this might be worthwhile to add to "autocomplete" as well.

Given the timing on this proposal, we understand that this will not be
addressed pre-Last Call.

Copyright © 2011 Apple Inc. All rights reserved.

[1]:
http://developer.apple.com/library/safari/documentation/appleapplications/reference/SafariHTMLRef/Articles/Attributes.html#//apple_ref/doc/uid/TP40008058-autocapitalize
[2]:
http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/DesigningForms/DesigningForms.html%23//apple_ref/doc/uid/TP40006512-SW2
[3]:
http://developer.apple.com/library/safari/#codinghowtos/Mobile/UserExperience/index.html%23GENERAL-DISABLE_AUTOMATIC_CORRECTION_AND_AUTOMATIC_CAPITALIZATION_IN_TEXT_FIELDS_OR_TEXT_AREAS
[4]:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#enumerated-attribute
[5]:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-autocomplete-default-state
[6]:
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#spelling-and-grammar-checking
[7]:
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#attr-form-autocomplete

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 1 April 2011 19:49:17 UTC