[whatwg] A mechanism to improve form autofill

[Ilya Sherman]

Apologies for the delay of this response -- I kept getting sidetracked by
other tasks...

On Thu, Aug 2, 2012 at 11:42 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 23 Jul 2012, Ian Hickson wrote:
> >
> > So we could define the autocomplete="" field's value as follows: [...]
>
> I've now specced this, with some minor changes.
>

Thanks!  I think the spec is quite clear and appropriately detailed.

My only high-level question is: Why did you choose to drop the proposed
aliases like "city" for "locality" and "province" for "region"?  While
"locality" and "region" are probably the most technically correct terms --
they're certainly the best that I found while researching -- they're not
terms that I'd expect most web developers to be familiar with.  I think
including the proposed aliases allows for a more "natural" way to express
many site's forms; and I think that more natural/readable source HTML code
is a Good Thing™.

Otherwise, a bunch of minor typos and the like, all related to the parsing
algorithm and subsequent sections:
* In step 13.3, "hint set" should be "hint tokens".
* It seems like step 13.6 should precede step 13.5.
* In step 14.3, "hint set" should be "hint tokens".
* In step 14.3, "contact" should be "mode".
* In step 14.4, I think "either is" is more natural than "either be".
* It seems like step 14.6 should precede step 14.5.
* Step 18 is the last mention of the "scope tokens" data in the parsing
algorithm, as well as in the subsequent commentary.  What is the intended
function of the scope tokens -- should they be combined with the hint set,
or is there a separate notion of scope that should be invoked by the UA
when parsing this attribute?
* In the paragraph beginning with "Suppose a user agent knows of two phone
numbers", there is a typo: "pefilled" -> "prefilled".
* For terms like "autofill hint set", should the spec use "autocomplete"
rather than "autofill", or is there an intentional distinction being made
here?

> So instead of <input type=tel autocomplete="work tel"> you would just
> > say <input type=tel autocomplete=work> (and would not be able to say
> > <input type=text autocomplete="work tel">, which would be an inferior
> > user experience when tel is given special behavior, or <input type=email
> > autocomplete="work tel">, which would be inconsistent).
>
> I'm a little wary about adding more magic here, these attributes are
> already pretty complicated. See the autocomplete section's algorithms and
> let me know if you still think we should do something along those lines.
> If it's something people are willing to implement, I wouldn't want to
> stand in the way; I agree that it has some good side-effects (like making
> it impossible to have certain combinations).
>
> I could also introduce some conformance requirements to make the bogus
> combinations non-conforming; currently I haven't made type=tel
> autocomplete=email non-conforming for instance.
>

Since the autocomplete type hints are just hints, I think it's ok to leave
this behavior undefined; but I also don't see any problem with making such
mismatches non-conforming, other than that makes the spec even longer/more
verbose.

On Thu, 26 Jul 2012, Aryeh Gregor wrote:
> >
> > Government-issued ID numbers might be worth adding.  In America, social
> > security numbers are sometimes used for this purpose, but are treated as
> > semi-secret, so you usually don't enter them on web forms. (My American
> > college did use my social security number as an ID number, but not in
> > web forms as far as I remember.)  But in Israel, and I assume some other
> > countries, there are national ID numbers that are considered public
> > info.  E.g., my Israeli id number (mispar zehut) is 332752187.  It's
> > printed on my checks and things like that, so it's no secret, and since
> > it's guaranteed to exist and be unique, various institutions use it for
> > login instead of or in addition to a username -- my bank, health
> > insurance provider, etc.
>
> I haven't added this yet.
>
> I also haven't added:
>  - payment instrument type
>  - payment instrument start date
>  - payment instrument issue number (for Maestro)
>
> I also haven't removed, as some people suggested, the three cc-name
> subfields.
>
> I'm open to making all these changes, but figured I would get some more
> input on them first, in particular from Ilya who did the research to come
> up with the original set of fields.
>

I have seen a relatively high number of Chrome bug reports requesting
better handling of (e.g. government) ID numbers.  One example: [
http://code.google.com/p/chromium/issues/detail?id=64433 ].  I think it
would be helpful to add these to the spec; though as subsequent posters
have noted, there's a lot of potential complexity in how these should be
represented.  This might fall under the broader class of "identity"-related
fields, which I think merit their own carefully thought out set of tokens.
 There was some work done on the beginnings of such a specification -- see
https://wiki.mozilla.org/Identity-inputs -- but my current understanding is
that this is an area in need of further development.

The payment instrument type is almost certainly appropriate to add -- it is
included on almost every website that I've encountered that includes
payment card fields.  It was an oversight on my part to omit it from the
initial proposal.

The other two payment instrument field types I haven't encountered on the
Web, as far as I can recall.  So, based on my data set accumulated while
working on Chrome Autofill, I'm ok with leaving these out of the spec for
now.  However, my experience is biased toward US websites; it's possible
that these fields are more prominent internationally.

The three cc-name subfields are split out surprisingly often on existing
websites.  I was initially opposed to including these in the spec; but that
data in support of them was overwhelming.

Finally, I have gotten a request to include a field type for bank account
numbers, though I have only seen this info actually requested on a small
handful of extremely prominent (and generally trusted) websites: Amazon,
PayPal, and I think Google Wallet.