Removing this restriction simplifies the dynamic generation use case, e.g.

  buyNowButton.onclick = function() {
    var form = document.createElement('form');
    var types = [... cc fields ...];
    if (shoppingCart.hasPhysicalGoods())
      types = types.concat(... shipping fields ...);

    types.forEach(function(type) {
      var input = document.createElement('input');
      input.setAttribute('autocomplete', type);
      form.appendChild(input);
    });

    form.requestAutocomplete();
  };

Obviously this example code could also include:

  form.hidden = true;
  document.body.appendChild(form);

but it seems a bit silly [to hide something just to add it to the DOM].

One concern is that this may lead to authors creating forms which aren't backwards compatible with browsers that don't support requestAutocomplete (such as the example above). If pages want to support browsers that don't have requestAutocomplete, they're going to have to duplicate some logic if they use this approach which doesn't seem ideal.  What is the use case for this change?

(In reply to Matthew Noorenberghe from comment #2)
> One concern is that this may lead to authors creating forms which aren't
> backwards compatible with browsers that don't support requestAutocomplete
> (such as the example above). If pages want to support browsers that don't
> have requestAutocomplete, they're going to have to duplicate some logic if
> they use this approach which doesn't seem ideal.

The use case here is for sites that alter their flow dramatically based on detecting requestAutocomplete (sorry, I forgot feature detection code in the example).

rAc's main goal is to /improve/ on the web payment experience.  We have found that slapping rAc onto existing checkout flows does not add much.  Because authors are required to change their code to use this API, we highly encourage streamlining checkout flows while integrating.

> What is the use case for this change?

I wouldn't really call it a change as it's never been implemented in Chrome (the only browser that currently has rAc).[1]

An [admittedly very focused] excerpt from the WHATWG FAQ:

  "Instead of ignoring what the browsers do, we fix the spec to match what the browsers do." [2]

[1] https://code.google.com/p/chromium/issues/detail?id=361900
[2] http://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standard.22_mean.3F

(In reply to Dan Beam from comment #3)
> (In reply to Matthew Noorenberghe from comment #2)
> > One concern is that this may lead to authors creating forms which aren't
> > backwards compatible with browsers that don't support requestAutocomplete
> > (such as the example above). If pages want to support browsers that don't
> > have requestAutocomplete, they're going to have to duplicate some logic if
> > they use this approach which doesn't seem ideal.
> 
> The use case here is for sites that alter their flow dramatically based on
> detecting requestAutocomplete (sorry, I forgot feature detection code in the
> example).
> 
> rAc's main goal is to /improve/ on the web payment experience.  We have
> found that slapping rAc onto existing checkout flows does not add much. 
> Because authors are required to change their code to use this API, we highly
> encourage streamlining checkout flows while integrating.

What about the case where the autofilled data is invalid according to the page's standards. http://www.html5rocks.com/en/tutorials/forms/requestautocomplete/ suggests pages could make the form visible. Would it then get appended to the document?

> > What is the use case for this change?
> 
> I wouldn't really call it a change as it's never been implemented in Chrome
> (the only browser that currently has rAc).[1]

Well, presumably it was in the spec for a reason and comment 2 seemed like a valid reason :)

It was in the spec because I just add that kind of requirement automatically based on past experience with things out of the doc causing problems, but it should be fine here.

I agree that people would have to only use this if the browser supported rAc and in other cases would need a different flow. But I don't know that this restriction is going to stop people from doing that. I expect they'll just stick their rAc-optimised forms into display:none bits on the page, which is no better, if we keep this restriction.

(In reply to Ian 'Hixie' Hickson from comment #5)
> It was in the spec because I just add that kind of requirement automatically
> based on past experience with things out of the doc causing problems, but it
> should be fine here.
> 
> I agree that people would have to only use this if the browser supported rAc
> and in other cases would need a different flow. But I don't know that this
> restriction is going to stop people from doing that. I expect they'll just
> stick their rAc-optimised forms into display:none bits on the page, which is
> no better, if we keep this restriction.

The fundamental difference here is that rAc discourages visible form inputs as showing an HTML UI with similar fields as an explicit browser UI is duplicative.  Traditional Autofill must show form inputs to function (as a UI surface to initiate filling, for security reasons [Chrome doesn't fill hidden fields], etc.).

Filling hidden/out-of-the-DOM inputs was never possible until now, which is probably why Ian added this requirement instinctually.

(In reply to Matthew Noorenberghe from comment #4)
> What about the case where the autofilled data is invalid according to the
> page's standards.
> http://www.html5rocks.com/en/tutorials/forms/requestautocomplete/ suggests
> pages could make the form visible. Would it then get appended to the
> document?

Showing the whole <form>, including valid inputs, seems unlikely to me.  rAc is about optimizing conversion.  I assume that authors hitting `event.reason == "invalid"` are likely to show as few fields as possible to continue the checkout (studies show: more inputs => more hassle => less conversion).

> Well, presumably it was in the spec for a reason and comment 2 seemed like a
> valid reason :)

It wasn't in the pre-HTML spec I helped write[1] (and see Ian's response in comment 5), which is why this bug exists: to hopefully remove the requirement as we've always thought this was an important use case.

In fact, the code example Jake provides in that article uses a document-less <form> to invoke rAc[2].

[1] http://wiki.whatwg.org/wiki/RequestAutocomplete
[2] https://gist.github.com/jakearchibald/5774636#file-gistfile1-js-L69

I've removed this requirement.