[whatwg] Improving autocomplete

[Dan Beam]

On Fri, Oct 26, 2012 at 12:43 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Fri, Oct 26, 2012 at 9:24 AM, Elliott Sprehn <esprehn at gmail.com> wrote:
>> [...]
>
> I'm missing the scenario that requires such interference from a web
> developer. Can't a UA just offer to autocomplete a form for me once it
> finds one? (Or in other words, unless I'm missing something this seems
> like a solution without a provided use case.)

One great example use case is payments on the web.  A user agent has
greater knowledge of a user than a web site does and is more trusted.
With a small amount of code, web developers can implement an improved
checkout flow:

  <a onclick=”document.forms[0].requestAutocomplete();”>Buy a frobber now!</a>
  <form action=”/buy” method=”post” onautocomplete=”submit();” hidden>
    <input type=”text” autocomplete=”cc-name”/>
    <input type=”text” autocomplete=”cc-number”/>
    <input type=”text” autocomplete=”cc-exp”/>
    <input type=”text” autocomplete=”cc-csc”/>
  </form>

With the addition of an imperative API, site authors can request a UI
from the browser for secure and simple data input and more efficiently
and effectively harness autofill data.

On Fri, Oct 26, 2012 at 3:09 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Fri, Oct 26, 2012 at 10:01 AM, Adam Barth <w3c at adambarth.com> wrote:
>> When should the UA offer to fill in the form (e.g., to select which
>> address they would like to use for shipping this particular order)?
>
> Presumably on page load.

There are quite a few use cases we've thought of so far that would not
be possible if triggering this UI is uncontrollable by site authors.

Some examples:
- dynamically changing <form>s based on user input (i.e. showing a
list of regions after a country has been chosen).  Extra/unwanted info
may show if the UI is only invoked on load. Also, third-party
widgets/scripts that create “Buy now” buttons that’d want to use this
new UI could insert hidden forms into the DOM dynamically after page
load.
- with more than 1 form on the page (think login + registration +
payment) it'd be hard to accurately know which one to autocomplete on
load.
- [hidden] forms triggering this UI on page load would probably be
unexpected, though some websites may want this behavior.  Letting the
author decide rather than relying on heuristics is much simpler to
implement and can be right 100% of the time.

An imperative API gives site authors the greatest amount of control
over when and what should be interactively autocompleted.  I think
we’ll be unable to accommodate all use cases if we prescribe when this
UI should be invoked.

>> In particular, Elliott wrote:
>>
>>> Authors can also display
>>> no forms at all to users of a browser who implements this proposal for
>>> one click checkout experiences which are important on mobile devices.
>
> I guess in that case it would be nice to know the user agent actually
> did display some UI.
>
> Are we using "cancel" elsewhere by the way? Fullscreen uses "error" as
> suffix for the event type.

The experimental implementation [1] has been updated to dispatch an
"autocompleteerror" as per convention/your feedback.

Dan Beam
dbeam at chromium.org

[1] http://bugs.webkit.org/show_bug.cgi?id=100557