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

On Wed, 21 Nov 2012, Ilya Sherman wrote:
> 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.

Fair enough. Added.


> > > 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.

Fair enough. So what do you need for bank account information? Account 
number? Account holder name (and subproperties for that like for cc-*)? 
Routing transit number? IBAN? SWIFT-BIC? I hesitate to do something US- 
specific here; what do sites ask for in other countries? If it's always a 
name, a bank number of some sort, and an account number, I can add those 
three fields (plus the two name subfields) pretty easily.


> > 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?

autocompleteerror is fine.


On Wed, 21 Nov 2012, Dan Beam wrote:
> 
> I definitely agree to a single event.  It would be great to do this and 
> give enumerable failure reasons (if this is deemed secure enough).
>
> An example:
> 
>   enum ErrorCause {
>     FROM_FRAME,
>     NEEDS_GESTURE,
>     NOT_SECURE,
>   };
> 
> This could be a property on the event (event.cause, event.reason?) 
> argument passed to the error event (kind of like DOM exceptions). This 
> seems akin to event.property in CSS transition end events (and 
> disputably many other examples).

Sounds fine to me. If it's implemented that way by two browsers, it's what 
I'll spec. (Document it on the wiki page to increase the chance of other 
browsers doing it that way too :-) .)


As a reminder to other vendors, right now "A method to trigger autofill" 
is one of the features on this list that only has one vendor registering 
interest, which is why I haven't yet specced it:

   http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest

If you want to compete with Chrome on convenience, better get on it, cos 
it looks like the Chrome folk are going ahead with this either way. ;-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 11 December 2012 03:49:37 UTC