[whatwg] Proposal for autocompletetype Attribute in HTML5 Specification

[Arun Patole]

Thanks for the detailed explanation!
I also think that specifying a "good" list of common tokens is a good
approach. Today itself I observed different behavior when I tried
structured auto form fill on ebay.com registration form. Chrome auto
completed it but the android browser didn't, because of the different
approaches used to identify full-name fields. Having common way of
differentiating fields makes it straightforward to implement it as well.

Regards
Arun

On Fri, Jan 20, 2012 at 3:05 PM, Ilya Sherman <isherman at chromium.org> wrote:

> 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
>>>
>>>
>>
>