Re: [w3c/browser-payment-api] PaymentAddress and null values (#495)

Sorry, I'm not too familiar with this part of the spec. To me it seems like this issue is talking about a bunch of separate unconnected things, so I will just reply to each individually, and you can help me understand how they're accepted.

> However, it gives no guidance about null values incoming from the information source for the PaymentAddress.

What is "the information source for the PaymentAddress"? How would null values be incoming from it?

> Noting this assumes that there is always a "shippingaddresschange" event fired before PaymentResponse is constructed (and returned via the [[acceptPromise]]).

The spec seems pretty vague on that:

> The shipping address changed algorithm runs when the user provides a new shipping address.

I don't know what counts as the user providing a new shipping address. If this is indeed an invariant, maybe we should state it. @rsolomakhin, does Chrome always fire "shippingaddresschange"?

> To outline the problem, a browser's Autofill DB from which we might pull shipping addresses might be Swiss Cheese when it comes to the ShippingAddress values. In other cases, the information might not be appropriate (e.g., organization, and dependentLocality)

I'm not sure how this is related. It seems the same as the user not typing values. I am not sure how the spec handles this; the only validation I see is whether it's null or not. Probably it's up to the UA to determine whether the user has entered enough information (through autofill or otherwise) and whether it wants to allow them to click the "proceed" button or whatever.

-- 
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/issues/495#issuecomment-291357119