- From: Simon Pieters <simonp@opera.com>
- Date: Fri, 20 Jan 2012 11:02:01 +0100
On Thu, 19 Jan 2012 06:30:08 +0100, 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 >> > > I have gotten a bit of feedback about this proposal via > email/IRC/Google+; > but this thread has been vewy vewy quiet. On Google+, Tantek ?elik > expressed concern [1] that this proposal ?appears to be a fait-accompli, > that is, having already been implemented? in Chrome 15 under the > experimental attribute x-autocompletetype. As I explained in my response > to Tantek's post, this proposal is not intended as a fait-accompli; but > rather is very much open to feedback and iteration. If you have any > comments or suggestions, please send them along! We have no interest in > indefinitely supporting this attribute prefixed with "x-", and fully > expect > the proposal to evolve prior to (hopefully) acceptance into the HTML > specification. > [1] > https://plus.sandbox.google.com/114128403856330399812/posts/9dKsD7Mi7JU Maybe some of the supported keywords could be dropped (e.g. those that are not recommended to use). Since there's no legacy yet, we can reject bad keywords completely and only support the best practice keywords. Similarly, there's address-line1, address-line2 and address-line3 -- maybe they could be dropped and encourage authors to use a textarea for address? The extensibility story should maybe use the wiki registration style like <link rel> keywords. The proposal states: "The main drawback to this solution is that unless approved as a part of the HTML specification, a website that implements the autocompletetype attribute would not be valid HTML." This is not technically correct. The HTML spec has the "other applicable specifications" extensibility point. -- Simon Pieters Opera Software
Received on Friday, 20 January 2012 02:02:01 UTC