Oh, hmm, that is confusing. I thought `error` was just a generic error signifier, not specifically related to shipping addresses. Also this idea that empty shipping options is bad is new to me: it's not captured anywhere in the spec, really. I think it might be less confusing if you changed 3.ii. to show the error anyway. Then you end up treating shippingOptions and error as separate concerns, although authors will likely use them together. Alternately, we could make the spec very clear that `error` is only to be used for shipping option-related errors, and will be ignored if requestShipping is false or shippingOptions is non-empty. In this case I'd ideally like to rename `error` to `shippingOptionsError` or similar, but that's not required, and is probably disruptive. Thoughts between those two? I guess in any case we should make it clear in the spec that if you pass `shippingOptions: []` to updateWith(), the UA should display an error, using `error` if provided. -- 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/browser-payment-api/pull/451#issuecomment-285725771
Received on Friday, 10 March 2017 17:06:58 UTC