W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

[whatwg] Additional details for invoking requestAutocomplete

From: Evan Stade <estade@chromium.org>
Date: Mon, 10 Mar 2014 13:33:43 -0700
Message-ID: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com>
To: WHAT Working Group Mailing List <whatwg@whatwg.org>
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 Monday, 10 March 2014 20:34:23 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC