Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
I've shown this proposal to a couple of people here at Apple, and we have no issues with it. I'm personally eager to see it move forward! -- Jon On Dec 15, 2011, at 1:17 PM, Ilya Sherman isher...@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
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
...as I'm in the middle of a project implementing schema.org markup, is there any consideration of using those properties as the tokens within the autocomplete attribute? While not perfectly compatible, it would lessen the burden on developers—Is it given-name or givenName for form fields?—and schema.org's notion of scoping might prove a better solution than the section- nomenclature. After all, form elements already have a grouping element in fieldset. In any case, I echo Jon's sentiment: looking forward to it! — nz On Feb 15, 2012, at 4:10 PM, Jon Honeycutt jhoneyc...@apple.com wrote: I've shown this proposal to a couple of people here at Apple, and we have no issues with it. I'm personally eager to see it move forward! -- Jon On Dec 15, 2011, at 1:17 PM, Ilya Sherman isher...@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
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Wed, Feb 15, 2012 at 3:57 PM, Nathan Ziarek nzia...@gmail.com wrote: ...as I'm in the middle of a project implementing schema.org markup, is there any consideration of using those properties as the tokens within the autocomplete attribute? While not perfectly compatible, it would lessen the burden on developers—Is it given-name or givenName for form fields? The current set of tokens was chosen to match the hCard [ http://microformats.org/wiki/hcard ] naming as much as possible. Unfortunately, it's not possible to match all of the major naming schemes without bloating the token space with lots of redundant tokens. —and schema.org's notion of scoping might prove a better solution than the section- nomenclature. After all, form elements already have a grouping element in fieldset. We considered this, but realized that structural scope does not necessarily match semantic scope for many existing web forms. The most common reason for this is using table elements to control layout :/ In any case, I echo Jon's sentiment: looking forward to it! :) — nz On Feb 15, 2012, at 4:10 PM, Jon Honeycutt jhoneyc...@apple.com wrote: I've shown this proposal to a couple of people here at Apple, and we have no issues with it. I'm personally eager to see it move forward! -- Jon On Dec 15, 2011, at 1:17 PM, Ilya Sherman isher...@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
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Sun, Jan 22, 2012 at 1:50 AM, Mounir Lamouri mou...@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/**Autocompletetypehttp://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
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Sun, Jan 22, 2012 at 11:57 PM, Simon Pieters sim...@opera.com wrote: On Sat, 21 Jan 2012 00:28:25 +0100, Ilya Sherman isher...@chromium.org wrote: The extensibility story should maybe use the wiki registration style like link rel keywords. Sorry, I'm not quite following what you mean by this. http://www.whatwg.org/specs/**web-apps/current-work/** multipage/links.html#concept-**rel-extensionshttp://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#concept-rel-extensions http://www.whatwg.org/specs/**web-apps/current-work/** multipage/semantics.html#**concept-meta-extensionshttp://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#concept-meta-extensions Ah, I see. That seems like a good idea -- added an Extensibility section with this suggestion to the wiki. Thanks :)
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
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, This name is very verbose. Isn't there something shorter — for example fieldtype — that we could use instead?
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Fri, Jan 20, 2012 at 6:28 PM, Ilya Sherman isher...@chromium.org wrote: 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? Dropping the discouraged keywords (e.g. phone-local-prefix) certainly seems reasonable to me, in the interest of keeping the predefined token set relatively small. On the other hand, these seven discouraged keywords were added to the initial proposal because a nontrivial number of existing forms currently structure their fields in this way. I'd love to get more people's insights into this tradeoff. I'll go ahead and fork off a thread specifically for discussion of the specific choice of tokens, so that this thread can remain focused on the more high-level details of the proposal. For the address lines, I don't think it's practical to encourage authors to use a textarea rather than separate fields. To the best of my knowledge, almost no website currently uses textareas for this purpose, so textareas are only a theoretical best practice -- users and developers both tend to expect the address lines to be separate fields. Moreover, transitioning from separate fields to a single textarea would require backend migrations (in the parsing code, the database, or both) in order to store the data entered in this new format. That would negate one of the key advantages of this proposal, i.e. the lack of need for backend migrations, relative to ECML. I don't see how requiring forms to lump the address together is going to help -- if the database stores the fields separately, other APIs that the backend needs to give the address to (such as shipping carriers, address cleanup/geocoding, etc) expects separate fields then all you are doing is pushing the parsing of the address off to the backend rather than letting the user see it. Also, I think a properly localized (ie, fields dependent on the country given) address form is much more likely to get the correct data from the user than just asking them to enter a blob of text. One question -- how does this fit with, say, a select element for country that shows localized country names? Can it be autocompleted as well? If so, does it match on the localized names, the value (which might be an ISO 2 or 3-digit code, or something unique to the app), or what? -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Thu, Jan 26, 2012 at 12:15 AM, Ilya Sherman isher...@chromium.orgwrote: 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. I think of the distinction here as follows: Imagine the various values forms might want. For example, first name, last name, home address, work address, home phone, mobile phone, fax. Now classify these by kind. (For an object-oriented programmer like me, this would be enumerate the different classes/types required to hold the above values.) You might come up with name, address, phone number. All phone numbers share some set of properties, such as consisting of digits, as do all names, all addresses, etc. The distinction between what kind of a value something is and what precise instance of that kind it is is a valuable distinction. As you noted already, the former can be used to do structural validation or provide helpful UI for entry without needing to understand the latter. I see type versus autocompletetype in this same way. type allows the UA to understand the structure of a form value while autocompletetype allows it to understand which particular values might commonly go there. Certainly we could eliminate the former and just use the latter, but there is a major downside. Imagine my UA has support for all the above example specific types I gave. Now a web author wants to write a form with a new value, e.g. maiden name or pager number. It would be wrong to use any of the above autocompletetype values, since this field doesn't mean any of those things. But that means I can't get the UA to do validation or UI assistance for me either. We could try to solve this by allowing our unified type attribute to take on the union of all type and autocompletetype values. But this is confusing. When I can have type phone number or home phone number, which do I use? It's not necessarily clear to a web author what the practical ramifications of this choice are. Therefore, I think leaving these fields separate makes sense even if sometimes one could imply the type from the autocompletetype. PK
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Thu, Jan 26, 2012 at 1:29 AM, James Graham jgra...@opera.com 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, This name is very verbose. Isn't there something shorter — for example fieldtype — that we could use instead? Or perhaps we could simply extend the autocomplete attribute with these new semantics (see my most recent message to this thread).
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
One question -- how does this fit with, say, a select element for country that shows localized country names? Can it be autocompleted as well? If so, does it match on the localized names, the value (which might be an ISO 2 or 3-digit code, or something unique to the app), or what? I would expect that this varies across autofill agents. For Chrome, we handle this case pretty well by leveraging the ICU library [ http://site.icu-project.org/ ].
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
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 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. 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? 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/ [2] https://wiki.mozilla.org/WebAPI/ContactsAPI Thanks, -- Mounir
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Sat, 21 Jan 2012 00:28:25 +0100, Ilya Sherman isher...@chromium.org wrote: The extensibility story should maybe use the wiki registration style like link rel keywords. Sorry, I'm not quite following what you mean by this. http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#concept-rel-extensions http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#concept-meta-extensions -- Simon Pieters Opera Software
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Thu, Jan 19, 2012 at 3:08 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Ilya Sherman isher...@chromium.org schrieb am Wed, 18 Jan 2012 21:30:08 -0800: I have gotten a bit of feedback […] https://plus.sandbox.google.com/114128403856330399812/posts/9dKsD7Mi7JU I am being redirected to an unrelated page promoting the immense benefits of having a Google profile. Is there a publicly available instance of the resource or is that discussion “limited” ? Whoops, typo in the URL -- it should be [ https://plus.google.com/114128403856330399812/posts/9dKsD7Mi7JU ]. Thanks for pointing that out!
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
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. Regards Arun On Fri, Jan 20, 2012 at 3:05 PM, Ilya Sherman isher...@chromium.org wrote: On Thu, Jan 19, 2012 at 7:01 AM, Arun Patole arun.pat...@motorola.comwrote: Hi, For what should not be auto completed, I think autocomplete=off is sufficient. I think you're referring to the paragraph beginning with In practice, this allows... in the proposal [1]. 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. [1] http://wiki.whatwg.org/wiki/Autocompletetype#4.10.7.2.13_The_autocompletetype_attribute 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 [2] -- precisely how to fill common types of forms, especially registration and e-commerce forms. [2] 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 [3], vCard [4, 5], xNAL [6], and Google Map's geocoding APIs [7]; as well as the types filled by Chromium's and by Safari's Autofill features. [3] http://www.ietf.org/rfc/rfc3106 [4] http://en.wikipedia.org/wiki/VCard#Properties [5] http://msdn.microsoft.com/en-us/library/ms533032(v=vs.85).aspx [6] http://www.oasis-open.org/committees/ciq/download.shtml [7] 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
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Fri, Jan 20, 2012 at 2:02 AM, Simon Pieters sim...@opera.com wrote: On Thu, 19 Jan 2012 06:30:08 +0100, Ilya Sherman isher...@chromium.org wrote: On Thu, Dec 15, 2011 at 1:17 PM, Ilya Sherman isher...@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/**Autocompletetypehttp://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/9dKsD7Mi7JUhttps://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? Dropping the discouraged keywords (e.g. phone-local-prefix) certainly seems reasonable to me, in the interest of keeping the predefined token set relatively small. On the other hand, these seven discouraged keywords were added to the initial proposal because a nontrivial number of existing forms currently structure their fields in this way. I'd love to get more people's insights into this tradeoff. I'll go ahead and fork off a thread specifically for discussion of the specific choice of tokens, so that this thread can remain focused on the more high-level details of the proposal. For the address lines, I don't think it's practical to encourage authors to use a textarea rather than separate fields. To the best of my knowledge, almost no website currently uses textareas for this purpose, so textareas are only a theoretical best practice -- users and developers both tend to expect the address lines to be separate fields. Moreover, transitioning from separate fields to a single textarea would require backend migrations (in the parsing code, the database, or both) in order to store the data entered in this new format. That would negate one of the key advantages of this proposal, i.e. the lack of need for backend migrations, relative to ECML. The extensibility story should
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
Ilya Sherman isher...@chromium.org schrieb am Wed, 18 Jan 2012 21:30:08 -0800: I have gotten a bit of feedback […] https://plus.sandbox.google.com/114128403856330399812/posts/9dKsD7Mi7JU I am being redirected to an unrelated page promoting the immense benefits of having a Google profile. Is there a publicly available instance of the resource or is that discussion “limited” ? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
Hi, For what should not be auto completed, I think autocomplete=off is sufficient. 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. Have you considered just having autocompletetype attribute on form? autocompletetype=registration/private(banking, etc)/personal/login, etc. 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. Regards Arun On Thu, Dec 15, 2011 at 1:17 PM, Ilya Sherman isher...@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
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Thu, Dec 15, 2011 at 1:17 PM, Ilya Sherman isher...@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
[whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
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
