Re: [w3c/payment-request] Fine grained error recovery for fields (#647)

> I'm not sure any UAs plan to expose the underlying languageCode so I'm not sure how useful an error message for it would be but I think it's fine to be consistent and support errors on all fields in the shipping address.

Agree. 

> Tangent: I'd rather we fixed the misnomer of addressLine => addressLines everywhere rather than continuing to propagate it 

I'm thinking it might be too late... consider what happened already when we changed `supportedMethods` to a string. I think we are still dealing with the fallout. 

> support both in the code already shipped in UAs treating the old name as an alias to the new name.

I personally think this will cause confusion, as people might think they can set one or the other, but then one will trash the other, etc. Naming things is hard 😢 

That reminds me, nevertheless, that maybe `addressLine` needs special treatment, because it's a sequence of lines. 

So, maybe we actually need:

```JS
  (DOMString or sequence<DOMString?>) addressLine;
```

We could say that:

  * When it's a DOMString - the whole address is bad.
  * When it's a sequence, the UA can match the errors to particular lines. 

So: 

```JS
// The whole address is bad!
const addressErrors.addressLine = "Look, buddy, I can't ship to a PO Box!";

// Address is partially bad!
const addressErrors.addressLine = [
  null, 
  "the second line is bad!", 
  null, 
  "the fourth line is bad!"
];
```  

Or is that overkill? 

-- 
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/647#issuecomment-386188031