- From: Ilya Sherman <isherman@chromium.org>
- Date: Mon, 6 Feb 2012 15:54:05 -0800
On Thu, Jan 26, 2012 at 3:01 PM, Ilya Sherman <isherman at chromium.org> wrote: > 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 >> > > Copying from the "autocompletetype vs autocomplete, type attributes" > thread: > > On Thu, Jan 26, 2012 at 5:03 AM, Kornel Lesi?ski <kornel at geekhood.net> > wrote: > >> How about merging autocompletetype with autocomplete then? >> >> It looks sensible to me: >> >> <input autocomplete=off> <input autocomplete=email> >> >> In case of <form autocomplete=off><input autocomplete=email></form> I'd >> expect autocomplete=email to override form's "off" value. > > > I actually like this idea a lot. We had previously chosen not to extend > the autocomplete attribute because we were worried about backward > compatibility. In particular, we were worried that existing user agents > might interpret <input type="text" autocomplete="bogus"> -- and hence also > <input type="text" autocomplete="email"> -- to be equivalent to <input > type="text" autocomplete="off">. However, I just checked with IE, Chrome, > Firefox, Safari, and Opera -- all simply ignore autocomplete="bogus". So, > we seem to be ok in terms of backward compatibility -- hooray! > > If I don't see any objections over the next few days, I'll go ahead and > update the proposal to extend the autocomplete attribute rather than > introducing the additional autocompletetype attribute. > Since I saw no objections, I've gone ahead and made this update. The wording could probably use some editing/tweaking -- feel free to nitpick, and especially to edit away nits if you have a wiki account with suitable permissions :) I have also updated all the token names to match hCard where possible. Please let me know -- preferably on the token name-specific thread -- if you see any remaining issues with the token names.
Received on Monday, 6 February 2012 15:54:05 UTC