Re: [whatwg] Additional details for invoking requestAutocomplete

Perhaps now is a more appropriate time for this discussion, given that
requestAutocomplete is now published in the spec (!).


-- Evan Stade


On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade <estade@chromium.org> wrote:

> Hi WhatWG.
>
> Currently, requestAutocomplete lets a user agent provide the same user
> experience across multiple sites for common data input flows. A site
> describes the data it desires (via a form and autocomplete attributes), and
> the user agent uses this information and what it knows about the user to
> expedite data input. For example, if one of the form elements has
> autocomplete=”cc-number” the browser might provide an experience tailored
> for a payment flow, or if there’s an element with autocomplete=”bday” the
> browser might use an experience that’s tailored for sharing identiy.
>
> We’ve found that there are some details of the interaction which might
> affect the UX which cannot be inferred from the data inputs. We propose to
> add an optional argument to the requestAutocomplete method. Thus invocation
> would look like:
>
>     form_element.requestAutocomplete(details);
>
> This |details| argument would be an object where key-value pairs provide
> additional details regarding the request. The spec should define a set of
> keys and associated data types which are recognized. There are currently
> two key-value pairs we would like to add:
>
>     key: “transactionAmount”
>     value: number
>     description: For data that is going to be applied towards a
> transaction, the /maximum/ value of the transaction. The browser does not
> guarantee that the returned payment instrument will work, but keeping the
> transaction under this amount will increase the likelihood of receiving a
> valid card number.
>
>     key: “transactionCurrency”
>     value: string
>     description: a valid ISO 4217 currency code that describes the
> currency for transactionAmount. If not provided, the default is “USD”.
>
> Justification? There are upper bounds on certain payment instruments, for
> example different credit cards have different credit limits; a debit card
> is linked to a bank account with a certain balance. It’s a much preferable
> user experience to be able to catch these problems earlier rather than
> waiting for the merchant to attempt the transaction and have it fail (or
> have a user’s account overdrawn). Concretely, Chromium wants to handle
> transactions over $2000 differently from transactions under that amount.
>
> Does this seem reasonable?
>
>
> -- Evan Stade
>

Received on Friday, 11 April 2014 18:19:53 UTC