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:

Agree, but it's not uncommon with dictionaries to do:

```JS
{
  phone: isValid(phone) ? "Phone is invalid" : undefined; 
}
```

Which the IDL layer will treat as "not passed". 

> 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?

Making `null` mean default also feels a bit weird, tbh.   

> 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?

@aestes? (I'm guessing is for consistently error messages that also get localized for free)

I'm happy to concur on this. Worst case, internally, in Firefox:

```JS
payerInput.setCustomValidity( 
  "payer" in errors === false ?  "" : errors.payer === "" ? defaultError : errors.payer
) 
```


-- 
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-428042953