[whatwg] Proposal for autocompletetype Attribute in HTML5 Specification

[Ilya Sherman]

On Thu, Jan 19, 2012 at 7:01 AM, Arun Patole <arun.patole at motorola.com>wrote:

> Hi,
>
> For "what should not be auto completed", I think "autocomplete=off" is
> sufficient.
>

I think you're referring to the paragraph beginning with "In practice, this
allows..." in the proposal [1].  If so, note that this is not directly part
of the proposed mechanics; rather, it's simply a practical on how to
leverage those mechanics.
[1]
http://wiki.whatwg.org/wiki/Autocompletetype#4.10.7.2.13_The_autocompletetype_attribute

As mentioned in that same paragraph, specifying something like
autocompletetype="x-other" would have different behavior from specifying
autocomplete="off".  To explain that, I'm going to have to detour for a bit
and describe the difference between "regular autocomplete" and "structured
autofill".  By "regular autocomplete", I mean the baseline, cross-browser
autocomplete feature that remembers verbatim what you've typed into a field
based on the field's name, and nothing else.  In contrast, by "structured
autofill" I am referring to something more like Chrome or Safari's Autofill
functionality, which enables filling of a complete address all at once.

Now, using that terminology, there are some fields for which regular
autocomplete is perfectly appropriate, whereas structured autofill is not.
 Namely, if you have a form field requesting a relatively unique type of
data -- e.g. the user's alma mater -- it might be useful to specify
autocompletetype="x-other" to avoid false positives triggering in
structured Autofill providers, while still enabling the regular
autocomplete functionality that saves time if you ever find yourself
filling out this selfsame form again.


> As far as I understand, the issue comes when you want different fields to
> be auto completed and only related suggestions should be shown. With the
> approach mentioned in this proposal, we can easily differentiate fields.
> But problem is the never ending list of field type tokens. Even the list
> mentioned here looks a small subset. Is it not sufficient to have just
> generic types like name, address, contact, etc? I understand user would
> always like to see more specific auto complete suggestions but then it
> looks hard to standardize huge list of tokens like name, surname, cc-name,
> etc. and also it may not support internationalization properly.
>

Unfortunately, generic types of the sort you mention are not sufficiently
descriptive to enable structured Autofill providers to fill the form
without falling back upon heuristics.  The primary goal of this proposal is
to enable site authors to instruct such providers -- including, for
example, Chrome, Safari, and the popular Firefox extension "Autofill Forms"
[2] -- precisely how to fill common types of forms, especially registration
and e-commerce forms.
[2] https://addons.mozilla.org/en-US/firefox/addon/autofill-forms/

Your point that it is hard to standardize the list of tokens is well taken,
and is also something that Tantek touched upon in his Google+ comment that
I previously linked to.  If we agree that specifying a list of common
tokens is a good approach, there will no doubt be some bikeshedding about
which tokens, exactly, should be included; and what they should be named.
 This discussion is welcome, though -- when the time comes -- it might be
wise to fork it to a separate thread (perhaps in a different forum) so as
to not distract from any broader concerns.

However, I will mention now that there is precedent for defining such lists
of tokens; and indeed, the list of tokens in the initial proposal is
consolidated across the token types in ECML [3], vCard [4, 5], xNAL [6],
and Google Map's geocoding APIs [7]; as well as the types filled by
Chromium's and by Safari's Autofill features.
[3] http://www.ietf.org/rfc/rfc3106
[4] http://en.wikipedia.org/wiki/VCard#Properties
[5] http://msdn.microsoft.com/en-us/library/ms533032(v=vs.85).aspx
[6] http://www.oasis-open.org/committees/ciq/download.shtml
[7] http://code.google.com/apis/maps/documentation/geocoding/#Types


> Have you considered just having autocompletetype attribute on form?
> autocompletetype=registration/private(banking, etc)/personal/login, etc.
>

Yes, we did consider this.  However, as with the generic types you mention
above, such a high-level labeling is not sufficiently descriptive to avoid
the need for heuristics.  Again, it is a premise of this proposal that
enabling site authors to fully override heuristics provides a much better
user experience for users of structured autofill providers.


> Having such attribute attribute on form also make it easy to control what
> kind of forms should be auto completed. For example, not many user would
> want their banking details like cc-name,cc-exp-year to be auto completed on
> a desktop browser. Probably only users with personal electronic
> devices(mobile/other) would like to have banking details auto completed.
>

I agree that the mobile use case is particularly compelling for structured
autofill.  However, based on our experiences with Chrome Autofill, we have
found that a sizable fraction even of desktop users appreciate the
convenience of quickly filling credit card information, just as many users
appreciate the convenience of having their desktop browser remember login
passwords.


> Regards
> Arun
>
> On Thu, Dec 15, 2011 at 1:17 PM, Ilya Sherman <isherman at chromium.org>
> wrote:
>
>>
>> Current autofill products rely on contextual clues to determine the type
>> of
>> data that should be filled into form elements. Examples of these
>> contextual
>> clues include the name of the input element, the text surrounding it, and
>> placeholder text.
>>
>> We have discussed the shortcomings of these ad hoc approaches with
>> developers of several autofill products, and all have been interested in a
>> solution that would let website authors classify their form fields
>> themselves. While current methods of field classification work in general,
>> for many cases they are unreliable or ambiguous due to the many variations
>> and conventions used by web developers when creating their forms:
>>
>>  + Ambiguity: Fields named "name" can mean a variety of things, including
>> given name, surname, full name, username, or others. Similar confusion can
>> occur among other fields, such as email address and street address.
>>
>>  + Internationalization: Recognizing field names and context clues for all
>> the world’s languages is impractical, time-intensive, and error-prone (as
>> good context clues in one language may mean something else in another
>> language)
>>
>>  + Unrelated Naming: Due to backend requirements (such as a framework that
>> a developer is working within), developers may be constrained in what they
>> can name their fields. As such, the name of a field may be unrelated from
>> the data it contains.
>>
>>
>> We believe that website authors have strong incentive to facilitate
>> autofill on their forms to help convert users in purchase and registration
>> flows. Additionally, this assists users by streamlining their experience.
>>
>> To that end we would like to propose adding an autocompletetype attribute
>> [1] to the HTML5 specification, as a complement to the existing
>> autocomplete attribute that would eliminate ambiguity from the process of
>> determining input data types.  We developed this initial draft proposal
>> working together with developers or several autofill products, and are now
>> looking forward to feedback and suggestions from the broader community.
>> [1] http://wiki.whatwg.org/wiki/Autocompletetype
>>
>> Thanks,
>> ~Ilya Sherman, Chromium Autofill Developer
>>
>>
>