Thanks for the clarifications. I'm still not clear what role you see the spec playing here, though. So far I know we want to clarify whether paymentaddresschange always fires before show() completes. But this business about nullable paymentAddress fields is unclear to me. Why does it matter whether the browser sets them to null or an empty string or "foolandia"? 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. Unless you are thinking of adding normative UI requirements (like "if the user doesn't do anything this field must be null")? -- 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-291375834
Received on Tuesday, 4 April 2017 02:20:55 UTC