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

> I'm still not clear what role you see the spec playing here, though.

It's basically what you state, but to be clear: 

1. should the `shippingaddresschange` event always fire? Or can a flow be complete without firing an event? 
1. should `PaymentAddress`'s attributes be nullable or always the empty string.

I still feel uneasy about 1, because it assumes that there will be a UI and that `.updateWith()` will always have the opportunity to play a role in the payment flow.  

> Why does it matter whether the browser sets them to null or an empty string or "foolandia"?

Because types matter, even when they can be coerced. 

> We could change it to allow null in more places but the browser is still going to be the one determining what to put their (in interaction with the user) so it's not like that's going to get us more interoperability. 

You are probably right wrt interop. I might be arguing for purity. 

> Unless you are thinking of adding normative UI requirements (like "if the user doesn't do anything this field must be null")?

No, definitely don't want language like that. It's again, more about what information the user agent can pass back to the app with certainty (not null) - but sometimes it could pass back the empty string for certain attributes, if that's the data it has been provided with by the user. 


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