Also, in response to something Ian wrote on another thread:
Why would this only apply to requestAutocomplete()? Surely it would be
just as important for the case where the user agent is filling in a form
without using that API.
That is true, but I don't know of a better way to convey this
This optional argument sounds reasonable to me (FWIW, I'm working on
the requestAutocomplete implementation for Firefox). The transaction
fields also seem sensible, but I have no experience with payment APIs,
so I can't give feedback on how well this will work with payment
providers in general
Specifically, Chromium would disable Wallet for transactions over a certain
limit (at the moment, that's $2k, but this business logic is subject to
change). When Wallet is disabled, users can still store/access their data
in Chrome/Chrome Sync.
-- Evan Stade
On Wed, Apr 23, 2014 at 5:02 PM,
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
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
