[whatwg] Proposal for autocompletetype Attribute in HTML5 Specification

[Ilya Sherman]

On Sun, Jan 22, 2012 at 1:50 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:

> On 12/15/2011 10:17 PM, Ilya Sherman wrote:
>
>> 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<http://wiki.whatwg.org/wiki/Autocompletetype>
>>
>
> Looking at the list of types you are proposing, I was wondering if we
> couldn't solve this another way. We could create two new input types:
> 'contact' (or person, or anything better) and 'address'. 'address' could
> even be part of 'contact' given that is a contact information.
> There is currently some work being done to access contact information [1]
> [2].
>
> Currently, the way we handle names and addresses is probably suboptimal
> and websites have to re-invent a lot of things. A simple field that would
> ask the user to give those information might be way better for both authors
> and users. For example, on a mobile phone, I would be able to pick up one
> of my contact address to send him a gift instead of typing it.
>
> I believe that doing that would have the side effect to solve the
> autocompletion issue but would do much more.
>
> Other input types like 'email' and 'tel' should be able to solve the
> phone, fax and email autocompletetypes I believe. Authors should stop using
> multiple fields for telephone and use <input type='tel'> instead. Then, UA
> could always present the same autocomplete list when type=email or type=tel
> is used if they believe it's better.
>

Extending the existing input 'type' attribute is an interesting idea,
thanks for raising it.  Looking through the existing input type values, it
seems they are primarily chosen so as to enable user agents to render and
format the input data in type-appropriate ways.  However, the existing
types do not try to nail down the field's exact data type beyond the needs
of this use case -- for example, <input type='tel'> currently covers both
phone and fax fields.  In contrast, for many autocomplete/autofill agents,
the distinction between phone and fax fields is important.

One possibility -- also suggested by Kornel Lesiński on a separate thread
-- would be to simply permit all of the attribute values from the
'autocompletetype' proposal as values for the 'type' attribute.  This
avoids introducing a new attribute, but co-opts the 'type' attribute.  My
guess is that people would object to co-opting the 'type' attribute in this
way, but perhaps I am wrong...

Another possibility, closer to your first suggestion, is to add one or two
new input types, along the lines of 'contact', 'person', and/or 'address'.
 I've given this a fair bit of thought, and I'm just not sure how to make
the details work out more smoothly than with the current autocompletetype
proposal.  Here are my two main hesitations:

(1) The website's developer still needs to specify what data, specifically,
is required.
For example, consider an <input type="contact"> field.  The phone number
might not be necessary, in which case most users would probably prefer not
to share their phone numbers.  Or, consider an <input type="address"> field
for a billing address.  It might be sufficient for the developer to simply
ask for the country and postal code information; and, again, the user might
not be willing to share further information needlessly.  So, these broad
input types still need additional markup -- seemingly quite similar to the
markup proposed for the autocompletetype attribute's values -- to more
precisely specify what data is requested.  Moreover, some Autofill agents
work better if they can distinguish a shipping address from a billing
address; again, specifying this distinction would require additional markup.

(2) As a consequence, this proposal requires additional UI from user
agents, and hence breaks backward compatibility.
While it's definitely handy to be able to select a contact from one's
phone's "address book" and fill the entire form in one go, a user should
also be able to fill such fields "by hand".  This requires the user agent
to somehow make clear to the user exactly what data is requested, and what
format to fill it in (again, some data can be optional; and some can be
required).  This seemingly requires new UI, e.g. to render a single <input
type="address"> as a list of the required address fields.  Existing user
agents would lack such UI, which means that site developers could not use
these new input types for the vast majority of users running older user
agents.

Had you already considered these issues, and perhaps had some solutions for
them in mind?

Also, I do not understand why we have credit cards types. Is anyone willing
> to have his credit cards information saved locally? Is any website not
> using autocomplete=off as soon as credit cards are involved?
>

Regarding the first question: Yes, we have usage statistics indicating that
many people appreciate the convenience of saving credit card information
locally, just as many people appreciate the convenience of saving password
information locally ;)

Regarding the second: About half of the websites that I've examined specify
autocomplete="off" for credit card numbers; the other half do not.  Most
websites in the first group do not specify autocomplete=”off” for the
credit card name and expiration date fields; only for the credit card
number and cvv code.

For the other types, we can consider them minor enough. This said,
> 'birthday' is part of contact information.
>
> [1] http://w3c-test.org/dap/**contacts/<http://w3c-test.org/dap/contacts/>
> [2] https://wiki.mozilla.org/**WebAPI/ContactsAPI<https://wiki.mozilla.org/WebAPI/ContactsAPI>


This work does look to be in a very similar vein to the autocompletetype
proposal -- thanks for the pointers!  It would be great for the APIs from
these efforts to dovetail, at least in their vocabulary for identifying
field types.

Thanks,
> --
> Mounir
>