- From: Ilya Sherman <isherman@chromium.org>
- Date: Thu, 26 Jan 2012 00:15:19 -0800
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 >
Received on Thursday, 26 January 2012 00:15:19 UTC