Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330)

> It's fairly easy for a developer to construct a FormData object and fill it with whatever they want including taking data from a PaymentResponse.

Absolutely, but that's kinda missing the point. We've spec'ed a crazy complex object hierarchy that could be collapsed down into a multi-map structure (FormData or the like). Additionally, the interface we've created has fairly limited serialization options (just JSON) and it's not very extensible.  

> I've not personally heard feedback before that this is needed and I'm reluctant to make this change at this stage for what might be a small convenience for a few developers that can be handled with a JavaScript function.

This is not really about a small convenience. Consider the two main things the current API doesn't address (or maybe you can tell me how it addresses the following): 

 1. Existing web store fronts that are already using `form`s.
 2. Validation of the Payment Response (where 1 already has `form` validation - via form.checkValidity()). 
 3. The site expects the `form` to be `submit()`ted somewhere.  

Note again the the above applies in all cases where a browser does not support the API - where a form needs to always be used as a fallback (basically 99% of all websites rely on `form`s to achieve this today). There almost 2 decades of form validation machinery in browsers and in libraries which we are effectively not making use of: this strikes me as a bit of an oversight in the design of this API, particularly into how it integrates with the existing web. 

If we do choose to keep the current complex object hierarchy, we should perhaps consider instead adding `.json()` and `.formData()` methods instead? 


-- 
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/330#issuecomment-265641643