Bug 12409 - WF3: Automatic capitalization in input fields
WF3: Automatic capitalization in input fields
Status: REOPENED
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
All All
: P1 enhancement
: ---
Assigned To: Travis Leithead [MSFT]
HTML WG Bugzilla archive list
:
Depends on: 12885
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-01 19:49 UTC by Edward O'Connor
Modified: 2015-06-17 05:48 UTC (History)
13 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Edward O'Connor 2011-04-01 19:49:12 UTC
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
Comment 1 Ian 'Hixie' Hickson 2011-06-15 23:11:32 UTC
Do we have data on how commonly this attribute is used? Since it's implemented it would be great to study how it has fared in the real world.
Comment 2 Aryeh Gregor 2011-06-16 18:09:55 UTC
This is closely related to bug 12885 (filed by Microsoft).  See in particular bug 12885 comment 6, where I suggest a unified mechanism that would handle both this case and that one.
Comment 3 Ian 'Hixie' Hickson 2011-06-16 22:47:22 UTC
This and bug 12885 are really asking for something like the old XForms-derived inputmode="" feature (though hopefully much simpler).
Comment 4 Michael[tm] Smith 2011-08-04 05:15:57 UTC
mass-move component to LC1
Comment 5 Ian 'Hixie' Hickson 2011-09-28 23:21:25 UTC
I strongly encourage those interested in this bug to help fill out this wiki page:
http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control
Comment 6 Michael[tm] Smith 2011-11-20 15:08:02 UTC
See comment #5 from Hixie:
> I strongly encourage those interested in this bug to help fill out this wiki
> page:
> http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control

I note that none of the commenters here other than Hixie have yet actually taken
time to add any content to that page. Is that because nobody has any
information to contribute toward this? Or just because it's not enough of a
priority for anybody to put time into providing the needed info?
Comment 7 Ian 'Hixie' Hickson 2011-11-24 02:35:19 UTC
(I'm not closing this NEEDSINFO because if nobody else does the research, I
eventually will.)
Comment 8 contributor 2012-07-18 07:28:50 UTC
This bug was cloned to create bug 17984 as part of operation convergence.
Comment 9 Silvia Pfeiffer 2012-09-28 08:24:48 UTC
Is this a feature that we want to see in the HTML5 spec or something for HTML.next?

I have the changes parked in a feature branch for now, see 

https://github.com/w3c/html/compare/master...feature;whatwg_inputmode
Comment 10 Edward O'Connor 2012-10-16 17:16:12 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: No spec change.
Rationale: Let's address this in a future version of HTML.
Comment 11 Robin Berjon 2013-01-21 15:58:53 UTC
Mass move to "HTML WG"
Comment 12 Robin Berjon 2013-01-21 16:01:39 UTC
Mass move to "HTML WG"
Comment 13 Travis Leithead [MSFT] 2013-02-02 00:14:14 UTC
This proposes a new input element attribute "autocapitalize" with the following enumerated values:
* none - no capitalization should be performed by a soft keyboard
* sentences - suggest that sentences start with a capital
* words - suggest that each word is capitialized
* characters" - suggest that caps-lock be enabled.

In bug 12885, the "inputmode" attribute was added with support that overlaps this proposal. It seems that:
* inputmode="latin-name" maps to the "words" proposal above
* inputmode="latin-prose" maps to the "sentences" proposal above.

However, the inputmode attribute does not seem to capture the "characters" scenario: input for a form field expecting US-state codes (e.g., WA, TX, NY).

Ted, do you think the inputmode attribute sufficiently addresses your use cases? Do you think we should consider the "characters" scenario for addition to inputmode? (e.g., "latin-yelling")

If you're happy with inputmode as-is we can resolve won't fix.
Comment 14 Travis Leithead [MSFT] 2013-02-14 22:59:22 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:


   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: No spec change
Rationale: The bug's proposed core scenarios have been met by the spec.
Comment 15 Travis Leithead [MSFT] 2013-03-05 00:21:05 UTC
See also: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038914.html

Ongoing discussion...
Comment 16 Mounir Lamouri 2015-03-16 15:09:22 UTC
Reopening based on http://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/0022.html

See a proposal here:
https://github.com/mounirlamouri/html-autocapitalize/blob/master/proposal.md

Philip Jägenstedt in blink-dev mailing list suggested that we only apply the attribute on Text and Search states. I would be fine given that it seems that Safari iOS and my current implementation in Chrome Android are actually doing that.

How does that sound? Also, my proposal does not include the <form> attribute because it is, according to my research, barely used and would add unnecessary complexity for an unclear use case.
Comment 17 Philip Jägenstedt 2015-03-16 16:58:38 UTC
I've opened a separate WHATWG bug since this would ideally be in both HTML specs: bug 28228.
Comment 18 Michael[tm] Smith 2015-06-16 11:37:52 UTC
in iOS

See https://www.w3.org/Bugs/Public/show_bug.cgi?id=28228#c7 and other comments at that bug.