On Thu, 19 Jan 2012 06:30:08 +0100, Ilya Sherman <[email protected]>
wrote:
On Thu, Dec 15, 2011 at 1:17 PM, Ilya Sherman <[email protected]>
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
