Define “valid decimal monetary value” and make transaction-amount use it

[sideshowbarker]

The autocomplete transaction-amount field has valid floating point number as its microsyntax.

Defining a monetary amount’s microsyntax as a floating-point number is suboptimal. It would be better to instead define a specific microsyntax for monetary values.

For example, see the Payment Request API’s definition of valid decimal monetary value:

A string is a valid decimal monetary value if it consists of the following components in the given order:

1. Optionally, a single U+002D HYPHEN-MINUS character (-), to indicate that the amount is negative
2. One or more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9)
3. Optionally, a single U+002E FULL STOP character (.) followed by one or more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9)

NOTE The following regular expression is an implementation of the above definition.

^-?[0-9]+(\.[0-9]+)?$

[zcorpan]

Does this need a corresponding parse algorithm?

[sideshowbarker]

Does this need a corresponding parse algorithm?

Yes

[zcorpan]

So what should it be parsed into? Is it an integer than is then divided by 1000 or 10,000 as suggested in https://github.com/w3c/browser-payment-api/issues/301#issuecomment-262941239 ?

[annevk]

As I understand it the trick with the payments API (and also "transaction-amount" it seems like) is that they only need validation. Processing is left up to the server.

Presumably you want actual decimals with infinite precision, but those don't exist yet as a primitive in the platform. @littledan mentioned this might happen at some point in JavaScript, but I haven't seen proposals yet.

[sideshowbarker]

So what should it be parsed into?

Not into anything as far as I understand. It’s parsed just for the purpose of validation. It stays a string.

As I understand it the trick with the payments API (and also "transaction-amount" it seems like) is that they only need validation.

Yeah

Processing is left up to the server.

Yeah, after validation the amount is just passed on—ultimately to some payment app that processes it and the other transaction details and then sends back a response.

[zcorpan]

OK then we don't need a parse algorithm. The "valid foo" thing is enough for validation.

[annevk]

If we add a section on decimals we should probably explain the difference though and explain why we don't have a parsing algorithm. In any event, I think making this change to conformance makes sense and I don't think it necessarily requires implementor interest since it only affects the checkers.

[sideshowbarker]

I think making this change to conformance makes sense and I don't think it necessarily requires implementor interest since it only affects the checkers.

OK I had been thinking that there might be requirements somewhere in the spec related to handling of client-side validation around autofill. (But I realize now that wouldn’t really make sense anyway.)

[sideshowbarker]

OK then we don't need a parse algorithm. The "valid foo" thing is enough for validation.

So the thing is, the spec requires PaymentRequest to throw on invalid values. So this affects UA requirements as far as PaymentRequest goes at least.

[annevk]

Fair, but implementors are presumably on board with that already.

[sideshowbarker]

Fair, but implementors are presumably on board with that already.

Yes, but what I meant was, if we’re going to define this decimal thing in HTML as a common place, then it seems we also need to define a parsing algorithm in HTML for it, even if that algorithm is not used by any features in HTML itself.

[annevk]

Determining whether a string is a valid decimal does not require parsing it into one. The "is valid" check seems sufficient.

[zcorpan]

Yes, what @annevk said. A UA can check if a string is valid just like a conformance checker can, and the spec can require UAs to do so where appropriate. This already happens in some places for other reasons (e.g. https://html.spec.whatwg.org/#parsing-a-srcset-attribute:valid-non-negative-integer ).

[mnoorenberghe]

I'm confused… I don't think PaymentRequest has anything to do with @autocomplete (though maybe it did in the past). I was going to suggest to remove transaction-amount now that form.requestAutocomplete() was removed. Are there any remaining use cases for "transaction-amount"?

[annevk]

@mnoorenberghe it doesn't have anything to do with it, but "transaction-amount" and the payment API should use a shared primitive if we're going to have something like "valid decimal" (and keep both).

@foolip do you know who we can ask from Blink about autocomplete?

[foolip]

That's tricky, most of the implementation is outside of Blink. A few people I see in (maybe) relevant OWNERS files are @pkasting @sky2 @rogerm @vabr-g. Do any of you know anything about the web-exposed bits of autocomplete?

@annevk, can you summarize the problem?

[annevk]

@foolip basically, as per @mnoorenberghe, should we keep "transaction-amount" as part of the autocomplete platform or drop it. As I understand it @mnoorenberghe is implementing autocomplete support in Firefox and doesn't see value in implementing that aspect of it.

[vabr-g]

I don't know much about the monetary part of form filling. Perhaps @madmath could know?

[mnoorenberghe]

To clarify, the "transaction-amount" token was never used for "filling" ("autofill expectation mantle"), it was used for the "autofill anchor mantle" which "describes the meaning of the given value". From my perspective, it was only useful for form.requestAutocomplete as a way for the author to tell the user agent how much money the transaction is for so that the user agent could show this amount to the user when they are selecting a credit card in the requestAutocomplete dialog.

i.e. the browser would never modify a "transaction-amount" field

[domenic]

Note that the "autofill anchor mantle" still applies for input type="hidden". At least in the spec... maybe it doesn't in implementations?

[mnoorenberghe]

Note that the "autofill anchor mantle" still applies for input type="hidden". At least in the spec... maybe it doesn't in implementations?

To clarify, the "it" in "it was only useful for" was referring to transaction-amount, I think there are still valid uses for the "autofill anchor mantle"

[domenic]

Ah, I see. I guess we can't expect the browser to autofill transaction-amounts reasonably. Maybe we need to do a culling of tokens that no longer make sense now that requestAutocomplete is gone. In that case we'd n longer define this term in HTML so the original post here becomes a bit moot...

[mnoorenberghe]

Agreed. I think the transaction-* ones are the only ones no longer relevant.

[mnoorenberghe]

I'll submit a PR for removing those 2

[mnoorenberghe]

Hmm… now I'm having second thoughts because the example at https://html.spec.whatwg.org/multipage/forms.html#autofilling-form-controls:-the-autocomplete-attribute:autofill-anchor-mantle-3 still seems valid but is a case I hadn't thought of and it's not something Firefox plans to do in the short term.

The user agent could use this information to suggest a credit card that it knows has sufficient balance and that supports the relevant currency.