Payment-request: Use HTML's (or infra) definition of “valid decimal monetary value”, once available

[marcoscaceres]

I'm sure there is a good reason for this, but why is details.total.amount.value not defined as a number, but instead as a string?

[halindrome]

I imagine to give flexibility to future currencies where there are VERY LONG floating point values so that we do not need to deal with precision when, in fact, nothing in the tool chain actually cares what the value is. It is only really there for display purposes and to pass along to the next actor in the chain.

[marcoscaceres]

@halindrome, thanks for the clarification.

[burdges]

You must specify maximum and minimum values for any number represented as a string anyways. You'll wind up with people converting it to potentially incompatible number formats like 32 bit floats otherwise. And other people dragging in unnecessary bignum packages. If one corrects this underspecification, then you might as well use a 64 bit float with a fixed exponent here.

[marcoscaceres]

So, this has a mismatch with HTML's transaction-amount and I think they need to match.

[nickjshearer]

So, this has a mismatch with HTML's transaction-amount and I think they need to match.

What's the mismatch in the context of this issue? transaction-amount is defined as a valid floating point value, which in the spec is a string, not a number. Like the amount here, it is a string that must conform to specific rules - but it's a string, nonetheless.

[marcoscaceres]

Sorry, I meant that it should be defined as the same thing "number", with validity check being done via the "valid floating point number" algorithm. The algorithm in the two specs work essentially the same, but just avoid more duplication.

[adrianhopebailie]

Representing amounts in payments as floating point numbers is generally accepted as a bad idea. Amounts should be represented as decimals.

I believe the most widely used definition of a decimal type is the XML Schema Decimal Type which is used outside of XML as a way to define decimals [1].

[1] https://www.w3.org/TR/xmlschema-2/#decimal

[burdges]

Strings have all the problems of floats and more thought, no? You want an integer that represents the currency value divided by 1000 for tenths of a cent, or 10,000 for hundredths of a cent, or whatever folks agree on. JavaScript numbers are all f64s under the hood, but one should only use the integer part. It's plenty big enough and avoid the issues with floats. You do need to specify how division rounds of course, but that can be done so as to avoid undefined behavior.

[nickjshearer]

I meant that it should be defined as the same thing "number", with validity check being done via the "valid floating point number" algorithm.

That seems sensible, the type remains a string and just cross-reference the existing algorithm.

You want an integer that represents the currency value divided by 1000 for tenths of a cent, or 10,000 for hundredths of a cent, or whatever folks agree on

This is certainly an ideal, but in the real world it becomes unmanageable. Firstly, you need to define exactly what unit of precision you're going to use - which itself is nearly impossible, because we have to support arbitrary currencies that may not exist yet, and some currencies have very large precision as-is (BTC supports eight decimal places, for example). So instead you need to define your integer units on a per-currency basis, except currencies can be revalued and change from under you, introducing additional precision (or dropping it).

[sideshowbarker]

Representing amounts in payments as floating point numbers is generally accepted as a bad idea. Amounts should be represented as decimals.

I agree with this.

When I wrote https://github.com/w3c/browser-payment-api/pull/256/commits/380c86274cfb967697d38b82847e5c0301b0d935 I considered defining it as a reference to HTML’s _valid floating point number_ rather than minting the new _valid decimal monetary value_ we now have.

But after discussion with others it became clear that using _valid floating point number_ for monetary values is suboptimal.

Ideally I think what we should have a common definition for monetary values. So I opened https://github.com/whatwg/html/issues/2104 against the HTML spec to suggest adding it there.

If that change is made, then HTML’s transaction-amount definition could be updated to reference that “valid decimal monetary value” definition rather than “valid floating point number”—and we could replace the definition we have in the Payment Request API spec with just a reference to that.

That’d be a better way to avoid duplication and to use a common definition for monetary amounts.

[marcoscaceres]

Ideally I think what we should have a common definition for monetary values. So I opened whatwg/html#2104 against the HTML spec to suggest adding it there.

Thanks, @sideshowbarker for doing that. I agree that it should change in HTML.

[marcoscaceres]

This is blocked on whatwg/html#2104

[marcoscaceres]

I'm closing this, as it hasn't moved for over a year. If there is any movement on the HTML side, can always reopen and add it. It's editorial, so 🤷🏽‍♂️