- From: Marcos Caceres <marcos@marcosc.com>
- Date: Thu, 7 Sep 2017 02:07:59 -0400
- To: Manu Sporny <msporny@digitalbazaar.com>, w3c-webpayments-wg <w3c-webpayments-wg@digitalbazaar.com>
On September 7, 2017 at 5:17:24 AM, Manu Sporny (msporny@digitalbazaar.com) wrote: > Hi Web Payments WG and WPIG (bcc'd), > > Exciting news. The engineering team at Digital Bazaar has been hard at > work creating a production grade polyfill for both the Payment Request > API and the Payment Handler API in Chrome, Safari, Edge, and Firefox. Great to Manu and team. Be mindful that we should start seeing support for *Payment Request* in all of the above around the same time the polyfill lands. As such, be very *really really REALLY* careful not to squat or otherwise override any standard behavior. And please please please (please) follow the TAG's guidance on Polyfills. https://www.w3.org/2001/tag/doc/polyfills/ The above is critical for *Payment Handler*, which is still super unstable! Please make sure you put that into a completely different namespace (e.g., window.DigitalBazaar.PaymentHandler etc.). > * Web developers won't need to wait for browsers to implement the latest > Web Payments API in order to deploy to their customers. Instead, the > polyfill will provide missing browser features until the browsers > support them. Ok, but it's absolutely critical that you pass the test suite. If any developers start coding against your polyfill, and it doesn't conform, they are going to have a really bad time as real implementations land (as they will break). So please be super vigilant with conformance testing. This will be really good for the whole WG, because it will help us verify the test suite. > * This will enable us to more rapidly test and deploy new payment > features, greatly reducing the cost of innovation in the group, and > enabling more people to participate in the design and development > process. Please be sure to also steer developers to relying on HTML5 autocomplete too (as a fallback)... I imagine whatever pollyfill you produce will rely on HTML5 autocomplete. > * The polyfill is one more implementation of the specs. Absolutely - and could provide critical feedback during the CR process! (though it won't count as an implementation for CR unfortunately - but that's ok!) We've strived really hard to make it implementable in JS, so I really hope it's comprehensible and clear. > What is next? > > * We'll continue to harden the polyfill for production usage. Tests are your friend. And lots of tests incoming. Would be awesome to have Digital Bazaar use the tests, and also contribute. > * We plan to provide technical review feedback on both specs after > having implemented them. 🎸 - again, be mindful that Payment Handler will likely change. > * We'll pick an open license that works for all orgs and implementers. C0! :D > * There are some issues in Safari that require preference changes that > we're trying to work around. Will be interesting to see how you work around the lack of service workers ATM. > * The foundation of the polyfill is, as predicted, almost exactly the > same as the verifiable claims polyfill, which may have repercussions > for how these sorts of APIs are designed at W3C. We'll produce a > report detailing the similarities before W3C TPAC. Looking forward to reading it. Particularly if it can better inform: https://www.w3.org/2001/tag/doc/polyfills/
Received on Thursday, 7 September 2017 06:08:31 UTC