Re: [w3c/payment-request] consider requiring an error (non-empty dict) for .retry()? (#792)

I don't think that's a great API design as I can see authors doing something like:
```js
payer: {
phone: isValid(phone) ? "Phone is invalid" : ""; 
}
```
It's also inconsistent with `setCustomValidity` which is a similar API. There "" means "clear the error" which is the opposite of here.

This will add more complexity for Firefox because internally we are using `setCustomValidity`.

I guess since we're currently using `DOMString`, authors can't use `""`, `null`, or `undefined` in a ternary to mean "no error" like in my example above as it won't give the expected result. I wonder if we should have used `DOMString?` to allow that?

What's the rational for Safari having this behaviour? So that merchants don't have to provide their own strings and therefore have inconsistency between sites?

If there is a good reason to provide a default message on empty, or there's not and Apple doesn't want to change this, I guess that's ok with me but only if this behaviour is specified in the spec (and documented on MDN).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/792#issuecomment-427035501