One of the biggest bottlenecks on any conversion funnel is filling out an online form – shopping and registration flows all rely on forms as a crucial and demanding step in accomplishing the goals of your site. For many users, online forms mean repeatedly typing common information like our names and addresses on different sites across the web – a tedious task that causes many to give up and abandon the flow entirely.
Chrome’s Autofill and other form-filling providers help to break down this barrier by remembering common profile information and pre-populating the form with those values. Unfortunately, up to now it has been difficult for webmasters to ensure that Chrome and other form-filling providers can parse their form correctly. Some standards exist; but they put onerous burdens on the implementation of the website, so they’re not used much in practice.
Today we’re pleased to announce support in Chrome for an experimental new “autocomplete type” attribute for form fields that allows web developers to unambiguously label
text and select fields with common data types such as ‘full-name’ or ‘street-address’. With this attribute, web developers can drive conversions on their sites by marking their forms for auto-completion without changing the user interface or the backend.
Just add an attribute to the input element, for example an email address field might look like:
<input type=”text” name=”field1” x-autocompletetype=”email” />We’ve been working on this design in collaboration with several other autofill vendors. Like any early stage proposal we expect this will change and evolve as the web standards community provides feedback, but we believe this will serve as a good starting point for the discussion on how to best support autofillable forms in the HTML5 spec. For now, this new attribute is implemented in Chrome as
x-autocompletetype to indicate that this is still experimental and not yet a standard, similar to the webkitspeech attribute we released last summer.For more information, you can read the full text of the proposed specification, ask questions on the Webmaster help forum, or you can share your feedback in the standardization discussion!
Shouldn't this come for free if the input was type="email" ?
ReplyDeleteWhy not use data- instead of x- to avoid breaking validation in the meantime?
ReplyDeleteWhat Dave Miller said. This is how input type="email" have been implemented already in Opera.
ReplyDeleteyes, it would make more sense if Chrome would adopt an already existing convention so we do not need to add an extra attribute to acomplish the same thing.
ReplyDeleteYep, Chrome does already understand <input type="email"> fields. However, there is not currently sufficient type-attribute granularity to cover the full range of Autofill field types. For example, there is currently no standard way to identify a form field as being an "Address line 1" field. Even for a field that is <input type="tel">, there is no standard way to indicate whether this is a regular telephone number or a fax number. That's where the autocompletetype attribute comes in.
ReplyDelete@Michael Smith: Since this attribute is not currently part of any official standard, we think that breaking validation is a feature rather than a bug. While we encourage developers to try out 'x-autocompletetype' in its current state and give us feedback, we hope that this will develop into a full-fledged standard, and that developers will then migrate to the standardized version. Lack of validation will be a gentle nudge reminding you to update ;)
Why not use the same 'classic' convention as Opera already does? Would be easier for everyone and especially the users.
ReplyDeleteThis is nothing new. Opera has already has these features
ReplyDeleteWhat about IE's version of this?
ReplyDeletehttp://msdn.microsoft.com/en-us/library/ie/ms533032(v=vs.85).aspx
Let's not encourage non-standard markup that only works in one specific browser. It's IE6 all over again.
ReplyDeleteThis is a good idea and I'll implement this on our webstore checkout pages today. There's really no downside to doing so.
ReplyDeleteSurprised to see some negative comments about this - and no, Opera doesn't do this already
@Ilya Sherman you said "Since this attribute is not currently part of any official standard, we think that breaking validation is a feature rather than a bug."
ReplyDeleteDo you really remember these good old days? Would you call InternetExplorer a feature or bug?
Don't do this. WHATWG is working hard enough to stop this shit! They gave you html5 form attributes
Could you not simply overload the autocomplete attribute, which currently only supports the values 'on' and 'off'?
ReplyDeleteautocomplete="email"
would then imply that autocomplete is on, and we would save writing a redundant attribute.
I have to join the dismissive chorus and label this a misstep. I'm all for adding convention-based functionality, but don't fragment standards in the process.
ReplyDelete@Paul Lindner: IE's version of this indeed influenced the design of this feature, as did several other related existing proposals and standards. Our goal is to work with the web standards community to develop this proposal into something that becomes part of the HTML specification.
ReplyDelete@ElbertF, netzaffin, Oskar: Don't worry, this attribute is standards-bound... it just isn't there *yet*. We are working with the WhatWG community to refine the design and build consensus. In the meantime, the attribute is prefixed with "x-" to indicate that it is non-standard markup. Think of this as a "developer preview" :)
@stephband: Thanks for the suggestion. We had previously thought that there would be backward compatibility issues with extending the autocomplete attribute; but after further testing, it looks like this should be ok. I'll follow up on this idea on the WhatWG thread.
This is a nice move from Google as it will reduce much of our effort and time taken in filling various online forms. Why can't web developers use this attribute in the data tag itself?
ReplyDeleteIt's a great move from Google and it will definitely help visitors save a huge amount of their time and energy. Filling a form has always been a tedious task and such kinds of options will surely change our search experience!
ReplyDeleteDUKE said:
ReplyDeleteI believe that effort used to standardize basic information forms would not be wasted. Example: Employment applications are all seeking the same information as can be legally asked for, any more specific information is handled by resume.
Specific jobs can be covered by that standard application. I feel that this type of thinking would help the employment process flow smoother on both sides of the desk. It would make the formfill a lot better.
It would be great to standardize forms types (shopping, financial, newsletter, social, etc), to allow greater customization of prefill within browser settings. A person might want to allow their browser to prefill a mailing list signup, but not a loan application.
ReplyDeleteDoes this work on all versions of Chrome?
ReplyDeleteYou have a great browser, don't make it shit. Implement standards if you can, don't make developers work harder.
ReplyDeleteAgreed, entering information on web is one of the most tedious job. thanks to browser like chrome and firefox which remembers lot of information but having support for this in protocol html5 itself would be even much better.
ReplyDeleteJavin
"there is not currently sufficient type-attribute granularity to cover the full range of Autofill field types. For example, there is currently no standard way to identify a form field as being an 'Address line 1' field."
ReplyDeleteNot so; that's "street-address" in vcard and the matched hCard standards. Further, if you match form fields to those standards, you can allow a user to just paste the URL of their (or someone else's - think gift recipients) v/hCard and fetch the rest from there.
Also, matching the design of such forms to vCard fields is best practice, as it allows for the reuse/ export of the data in vCard format.
"Even for a field that is input type="tel", there is no standard way to indicate whether this is a regular telephone number or a fax number."
Again; not so, already in v/hCard standards.
Work on marking up forms using hCard has already been done: http://microformats.org/wiki/hcard-input
[angle brackets removed fro quoted text at blogger's insistence]
This information may no longer be relevant...
ReplyDeletehttps://code.google.com/p/chromium/issues/detail?id=156508
Raised on the 17th October, 2012:
We are currently parsing autocomplete type hints from the experimental x-autocompletetype attribute. This has now been added to the living draft of the WhatWG HTML spec at [ http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofilling-form-controls:-the-autocomplete-attribute ]. We should update our implementation to parse the attribute according to this spec rather than according to the experimental implementation.
Issue was closed on the 23rd October... so I presume its now following the spec at:
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofilling-form-controls:-the-autocomplete-attribute
Seems that it has been included in the "autocomplete" form fields attribute standard:
ReplyDeletehttp://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofilling-form-controls:-the-autocomplete-attribute
BTW, the doc specifies that any browser implements it, anyone has any experience with that?