If we introduce something like autocomplete="transaction-currency" then it's easy to misinterpret that as the site asking the browser what the currency is for the payment method, then having a site author use transaction-currency in a non type=hidden input.

So I would prefer a separate attribute called autocomplete-hint="" or something, which has its own set of tags.

Would that be on the <form>?

What kind of syntax did you have in mind for this?

My understanding was that the proposal was:

<form>
  <input autocomplete="cc-number">
  <input autocomplete="cvc">
  <input type="hidden" autocomplete="transaction-amount" value="153">
  <input type="hidden" autocomplete="transaction-currency" value="USD">
</form>

My suggestion is a small change:

<form>
  <input autocomplete="cc-number">
  <input autocomplete="cvc">
  <input type="hidden" autocomplete-hint="transaction-amount" value="153">
  <input type="hidden" autocomplete-hint="transaction-currency" value="USD">
</form>

This is the common case, where the transaction amount is calculated by the site. But it also supports the case where a user might be asked to enter an amount, e.g. for a donation:

<form>
  <input autocomplete="cc-number">
  <input autocomplete="cvc">
  <input autocomplete-hint="transaction-amount">
  <input type="hidden" autocomplete-hint="transaction-currency" value="USD">
</form>

(I think it's still useful to have the separate autocomplete-hint attribute to make it clear the browser will never autocomplete this field.)

It occurs to me username is a little different because that is something the browser might fill in, or might just get from the page in other cases like changing passwords. So either way is a little messy...

Using <input type=hidden> without a name="" seems a bit weird too.

Are we sure browsers would never want to autofill "currency"?

I agree that "amount" is a weird thing to autofill.

I guess it's conceivable the browser could fill in transaction-amount and currency, although it seems unlikely (I've personally never been given the choice of currency). For example, a requestAutocomplete implementation might integrate the payment amount input into the requestAutocomplete flow itself, even though that information is not commonly reused/would likely not be stored for reuse.

So sorry for the noise; I would support the first option in this thread.

Does anyone other than Evan and I have any input here?

If not, my plan is to perform the following two changes:

 - introduce two new autofill values next to the existing cc-* values:

     currency
       - the currency that the user would prefer the transaction to use
       - format: ISO 4217 currency code
       - control group: text

     amount
       - the amount that the user would like for the transaction (e.g. when
         entering a bid or sale price)
       - format: valid floating-point number
       - control group: numeric


 - introduce a new semantic for autocomplete="" on type=hidden. The values "on"
   and "off" will not be valid. If specified, the attribute says that the user
   agent should act as if the user had specified the given value for the given
   autofill field.

Hello,

I'm a peer on Gecko's Password and Form Manager components though I don't speak on behalf of the DOM team. I have some comments below:

* I agree we don't need a new autocomplete attribute (e.g. autocomplete-hint) as I think the current proposal is fine.

* I definitely want to continue to be able to use hidden inputs to know which password to use in re-auth scenarios without an editable username field when a user has more than one account (username+pass) for a domain saved in the browser.

* A recurring problem with @autocomplete is that it's both used for deciding what to autocomplete/autofill and for knowing when to save the submitted data so it can later be autocompleted/autofilled. Both cases shouldn't always treated the same way and that needs to be kept in mind.

** In the case of the @type=hidden changes from comment 6, I think one could interpret that to hint that we should now be saving values from @type=hidden if there is a valid @autocomplete since we're treating it as if the user typed it. I think that's reasonable but I wanted to see if others disagree. Currently, in Gecko, we don't save non-dirty or @type=hidden values in form manager so this would be a change. I don't think the UA should modify @type=hidden fields with @autocomplete though but I'm not sure if that is disallowed in the spec anywhere. It may be worth adding.

* I don't really have much to say about the new autocomplete values other than that they seem reasonable and I agree that both should be available on visible <input>s as I've seen that in the wild before on a donation site that let you specify the amount and currency.

> In the case of the @type=hidden changes from comment 6, I think one could 
> interpret that to hint that we should now be saving values from @type=hidden if 
> there is a valid @autocomplete since we're treating it as if the user typed it.

I think it's reasonable. In the username/pw case, the browser should save the new combo just as if the user had typed both.

We definitely shouldn't modify the type=hidden fields.
What fields we should save is an interesting point. I'm not sure what the spec says about that at the moment. I could add more colour around that if that would help, but can you elaborate on the restriction about not saving non-dirty fields?

Out of curiosity, why type="hidden" rather than readonly?  Whether or not the input is hidden seems orthogonal to whether the value should be autofilled.  For requestAutocomplete(), a common pattern is to hide the entire form, since it will be presented as native UI instead.  Having type="hidden" fields in a form that is itself hidden is ... a little weird :)

(In reply to Ilya Sherman from comment #10)
> Out of curiosity, why type="hidden" rather than readonly?

The @autocomplete attribute isn't only used for requestAutocomplete so the hidden username case with a visible password field is the main thing I'm thinking of.

(In reply to Matthew Noorenberghe from comment #11)
> (In reply to Ilya Sherman from comment #10)
> > Out of curiosity, why type="hidden" rather than readonly?
> 
> The @autocomplete attribute isn't only used for requestAutocomplete so the
> hidden username case with a visible password field is the main thing I'm
> thinking of.

Well, there's nothing preventing an input from being both hidden and readonly, though I think that outside of requestAutocomplete, user agents generally wouldn't fill hidden elements anyway.  Is there any disadvantage to keying off of readonly rather than hidden?

(In reply to Ian 'Hixie' Hickson from comment #9)
> can you elaborate on the restriction about not saving non-dirty fields?

In Firefox's form manager, we don't save fields that have their default value (value == defaultValue)[1] to avoid saving data that the user didn't type (mostly to try to keep suggestions relevant). I don't feel strongly about whether this is a good idea or not since no real world examples were given in the bug but it's something that we still do.

(In reply to Ilya Sherman from comment #12)
> (In reply to Matthew Noorenberghe from comment #11)
> > (In reply to Ilya Sherman from comment #10)
> > > Out of curiosity, why type="hidden" rather than readonly?
> > 
> > The @autocomplete attribute isn't only used for requestAutocomplete so the
> > hidden username case with a visible password field is the main thing I'm
> > thinking of.
> 
> Well, there's nothing preventing an input from being both hidden and
> readonly, though I think that outside of requestAutocomplete, user agents
> generally wouldn't fill hidden elements anyway.  Is there any disadvantage
> to keying off of readonly rather than hidden?

Since AFAIK UAs didn't modify hidden inputs in the past, I think authors assumed they were readonly by default and therefore didn't add seemingly redundanct @readonly markup. I was going to propose that @type=hidden are readonly by default in my first message but I'm haven't thought about it long enough to think of cases where that wouldn't be wanted.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=463486

I think keying off readonly makes sense because there could be a situation where a site prefers to show that input. For example, when I tell my bank to remember my username, it shows me something functionally equivalent to:

<span>Login</span>
<input type="text" value="estade" autocomplete="username" readonly></input>
<input type="text" autocomplete="current-password"></input>

Evan, I'm still not sure what you're replying to (in comment 10 or comment 14) so please clarify as I think we may be on the same page. :)

Are you saying we should save for readonly but not for @type=hidden (when both have @autocomplete)? I think saving the username in the comment 14 case is definitely wanted but that wasn't the case I was talking about. @type=hidden is more special since the user definitely can't even see the value and that's why I mentioned it specifically.

> Are you saying we should save for readonly but not for @type=hidden (when both 
> have @autocomplete)? I think saving the username in the comment 14 case is 
> definitely wanted but that wasn't the case I was talking about. @type=hidden is 
> more special since the user definitely can't even see the value and that's why 
> I mentioned it specifically.

Presumably a browser already won't autocomplete readonly inputs. The browser can decide whether reading from it or storing its value makes sense (e.g. a username with readonly attribute does make sense to save, when paired with a password).

I guess it's up to Ian how much of this even needs spec'ing, but it sounds like websites already have the tools they need to create forms with enough clues for the browser to act smartly (i.e. by using inputs with an appropriate combination of readonly and hidden attributes).

If the field isn't type=hidden, then it already all works (autocomplete can't change the value in an immutable field). This is just about providing the information _without_ showing the field.

> If the field isn't type=hidden, then it already all works (autocomplete can't 
> change the value in an immutable field). This is just about providing the 
> information _without_ showing the field.

right. So it already all works when you do:

<input type="hidden" value="foo" readonly>
or
<input type="text" value="foo" readonly hidden>

Well, this:

   <input type="hidden" value="foo" readonly>

...is invalid, and the readonly="" attribute is ignored.

It should work for the other one, though, per spec. This bug is about making the one with type=hidden work, so that you don't have to rely on the hack of hiding a control, which is kinda ugly, semantically speaking.

(In reply to Ian 'Hixie' Hickson from comment #6)
> Does anyone other than Evan and I have any input here?
> 
> If not, my plan is to perform the following two changes:
> 
>  - introduce two new autofill values next to the existing cc-* values:
> 
>      currency
>        - the currency that the user would prefer the transaction to use
>        - format: ISO 4217 currency code
>        - control group: text
> 
>      amount
>        - the amount that the user would like for the transaction (e.g. when
>          entering a bid or sale price)
>        - format: valid floating-point number
>        - control group: numeric

We would prefer the original proposed names with the "transaction-" prefix since "amount" alone can be ambiguous.

>  - introduce a new semantic for autocomplete="" on type=hidden. The values
> "on"
>    and "off" will not be valid. If specified, the attribute says that the
> user
>    agent should act as if the user had specified the given value for the
> given
>    autofill field.

This is fine.

(In reply to Ian 'Hixie' Hickson from comment #19)
> Well, this:
> 
>    <input type="hidden" value="foo" readonly>
> 
> ...is invalid, and the readonly="" attribute is ignored.

I didn't realize @readonly wasn't valid on @type=hidden. Was there consideration for making the readOnly IDL attribute return true for @type=hidden? It is exposed with the value false in Gecko currently. I guess whether that makes sense depends how you interpret "

the .readOnly IDL attribute just reflects the readonly="" content attribute, it doesn't have any cleverness. readonly="" doesn't apply to type=hidden, same as with type=radio or type=button.

> - format: valid floating-point number

So to be clear, would the recommendation for user-editable input of this type (e.g. specifying a gift card amount) be:

<input type="number" autocomplete="transaction-amount" step="0.01">

And if the canonical format is not used (e.g. <input type="text" with value="1,000"), should the browser ignore the input?

> So to be clear, would the recommendation for user-editable input of this
> type (e.g. specifying a gift card amount) be:
> 
> <input type="number" autocomplete="transaction-amount" step="0.01">

That would be reasonable. I could also imagine <select> making sense (as in, pick one of these prices), or type=range.


> And if the canonical format is not used (e.g. <input type="text" with
> value="1,000"), should the browser ignore the input?

It would be handled the same way as <input type=text autocomplete=cc-number value="foo">.

ping on this. I think we have agreed that amount and currency should be added to the spec. transaction-amount, or cc-amount, either one is fine with me.

My plan is to perform the following changes:

 - introduce two new autofill values next to the existing cc-* values:

     transaction-currency
       - the currency that the user would prefer the transaction to use
       - format: ISO 4217 currency code
       - control group: text

     transaction-amount
       - the amount that the user would like for the transaction (e.g. when
         entering a bid or sale price)
       - format: valid floating-point number
       - control group: numeric

 - introduce a new semantic for autocomplete="" on type=hidden. The values "on"
   and "off" will not be valid. If specified, the attribute says that the user
   agent should act as if the user had specified the given value for the given
   autofill field.

Feel free to implement as if that was what the spec said. Sorry about the delay updating the spec, I'm in the middle of trying to revamp my spec generating pipeline.

Checked in as WHATWG revision r8735.
Check-in comment: Add transaction-currency and transaction-amount fields for autofill.
http://html5.org/tools/web-apps-tracker?from=8734&to=8735

Checked in as WHATWG revision r8736.
Check-in comment: allow autocomplete to be specified on type=hidden
http://html5.org/tools/web-apps-tracker?from=8735&to=8736

Let me know if I missed anything!