This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 12409 as part of operation convergence. Originally filed: 2011-04-01 19:49:00 +0000 Original reporter: Edward O'Connor <eoconnor@apple.com> ================================================================================ #0 Edward O'Connor 2011-04-01 19:49:12 +0000 -------------------------------------------------------------------------------- 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 ================================================================================ #1 Ian 'Hixie' Hickson 2011-06-15 23:11:32 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #2 Aryeh Gregor 2011-06-16 18:09:55 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #3 Ian 'Hixie' Hickson 2011-06-16 22:47:22 +0000 -------------------------------------------------------------------------------- This and bug 12885 are really asking for something like the old XForms-derived inputmode="" feature (though hopefully much simpler). ================================================================================ #5 Ian 'Hixie' Hickson 2011-09-28 23:21:25 +0000 -------------------------------------------------------------------------------- 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 ================================================================================ #6 Michael[tm] Smith 2011-11-20 15:08:02 +0000 -------------------------------------------------------------------------------- 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? ================================================================================ #7 Ian 'Hixie' Hickson 2011-11-24 02:35:19 +0000 -------------------------------------------------------------------------------- (I'm not closing this NEEDSINFO because if nobody else does the research, I eventually will.) ================================================================================
Patially done: http://www.whatwg.org/specs/web-apps/current-work/#attr-inputmode I haven't added support for equivalents of "words" and "characters" yet, mostly because I forgot about this bug until just now and I didn't see use cases elsewhere. Leaving this open to consider those further. For "characters", it might be better for the page to just autocapitalise the input itself. For "names", though, it might make sense to introduce a "names" keyword that maps to the user's preferred locale's conventions for names.
There's a "latin-name" field now. I'm going to skip adding things for capital letters for now since that's easy to fix up later. Please file new bugs if there are use cases that need addressing that are not addressed, giving example pages that need the feature.