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