[whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
arun.patole at motorola.com
Fri Jan 20 05:36:22 PST 2012
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.
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:
>> For "what should not be auto completed", I think "autocomplete=off" is
> I think you're referring to the paragraph beginning with "In practice,
> this allows..." in the proposal . 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.
> 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"
>  -- precisely how to fill common types of forms, especially registration
> and e-commerce forms.
>  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 , vCard [4, 5], xNAL ,
> and Google Map's geocoding APIs ; as well as the types filled by
> Chromium's and by Safari's Autofill features.
>  http://www.ietf.org/rfc/rfc3106
>  http://en.wikipedia.org/wiki/VCard#Properties
>  http://msdn.microsoft.com/en-us/library/ms533032(v=vs.85).aspx
>  http://www.oasis-open.org/committees/ciq/download.shtml
>  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
>> On Thu, Dec 15, 2011 at 1:17 PM, Ilya Sherman <isherman at chromium.org>
>>> Current autofill products rely on contextual clues to determine the type
>>> data that should be filled into form elements. Examples of these
>>> 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
>>> solution that would let website authors classify their form fields
>>> themselves. While current methods of field classification work in
>>> for many cases they are unreliable or ambiguous due to the many
>>> 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
>>> occur among other fields, such as email address and street address.
>>> + Internationalization: Recognizing field names and context clues for
>>> the world’s languages is impractical, time-intensive, and error-prone (as
>>> good context clues in one language may mean something else in another
>>> + Unrelated Naming: Due to backend requirements (such as a framework
>>> a developer is working within), developers may be constrained in what
>>> 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
>>> flows. Additionally, this assists users by streamlining their experience.
>>> To that end we would like to propose adding an autocompletetype attribute
>>>  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
>>> looking forward to feedback and suggestions from the broader community.
>>>  http://wiki.whatwg.org/wiki/Autocompletetype
>>> ~Ilya Sherman, Chromium Autofill Developer
More information about the whatwg