Re: [whatwg] Autocomplete and autofill features and feedback thereon

On Tue, Nov 20, 2012 at 5:17 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 16 Oct 2012, Ilya Sherman wrote:
> > 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.
>
> It's redundant data, the credit card number itself says what type it is.
>
> More importantly, I don't know how to store the information. What values
> should we be expecting here? If a site has radio buttons "v", "m" and "a",
> and another has a <select> with "4", "5", and "3", and yet another has
> three buttons which set a type=hidden with the values "visa", "mastercard"
> and "amex", how is the user agent to figure out what's going on? This
> makes the magic needed around dates look positively easy.
>

I agree that it's redundant data, but many websites ask for it separately
anyway.  One common reason for this is that the website only supports a
subset of all possible credit card issuers -- for example, many do not
support DiscoverCard.  While the site *could* theoretically infer from the
entered card number that the card is not supported, and show the user an
error, most sites instead force the user to select the card type, and
inform the user of unsupported card types by omitting them from the list.

Regarding storing of the data: I think being able to fill the data is more
important than being able to store it.  For example, Chrome stores just the
card number, and not the type; but Chrome supports filling the type by
inferring it from the stored card number.  For filling the card type, I
think it's strictly easier than filling a <select> dropdown containing
country names, since localization issues don't come into play as much.  The
user agent is presumably not going to be able to handle *every* case; but
in my experience, it's not too hard to handle many/most of the real-world
cases.  Since this attribute is used just as a hint, esoteric difficult
cases don't seem like enough reason to omit the card type as a known token
in the spec.


> > 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.
>
> Is there any reason we shouldn't just treat bank accounts like just
> another credit card, and use cc-number for these?
>

Yes: Most websites that support credit card numbers as inputs do not
support bank account numbers.  The few websites that do support bank
account numbers use separate fields for these vs. credit card number
inputs.  Labeling both fields identically would leave the browser unable to
distinguish which field to fill with what info.


> On Wed, 31 Oct 2012, Dan Beam wrote:
> >
> > The experimental implementation [1] has been updated to dispatch an
> > "autocompleteerror" as per convention/your feedback.
>
> "autocompleteerror" seems like it'd be fired for an error, not user
> cancelation. User cancelation is usually called either "abort" or
> "cancel". I think autocompletecancel is fine. It's consistent with
> oncancel, which we used for <dialog>. (Fullscreen's "error" event is for a
> slightly different case, based on what the spec says.)
>

There are also cases where we'd want to return actual errors.  For example,
in Chrome, we are only planning to support this dialog for sites served
over HTTPS and without security errors.  We might also want to fire an
error in case the input fails to pass the form's validation requirements.
 Should we use autocompleteerror for the errors, and autocompletecancel for
user cancelations?  Firing separate events for cancelations vs. errors
forces developers to check for each of these cases separately, which seems
like a less convenient API than just checking for one sort of failure
event.  Perhaps we should have a single event named something like
autocompletefail or something like that?

Received on Thursday, 22 November 2012 01:08:50 UTC