HI Mike, We've been working on updating our docs and reaching out to external documentation owners as well. We will respond back to this email thread once we have significant progress to report :-D
By the way, do we need to get blink-dev@ approval for starting to print deprecation warnings in the Developer Console? I'm not sure whether Developer Console warnings are considered web-facing. Cheers, Rouslan On Thu, Sep 16, 2021 at 3:11 PM Mike West <[email protected]> wrote: > Hey folks, > > We talked about this in the API owners meeting tonight, and I think folks > are conceptually on board with this deprecation along the timeline we > talked about above (4 milestones). That said, there's still practical > concern that the messaging for developers currently doesn't match the > requirements y'all are creating by removing `basic-card`, and we'd be much > more comfortable moving forward if we had concrete docs to point developers > to in any deprecation warning so they they have a clear migration path. > > If you can land some documentation changes, I think you'll quickly get > LGTMs for deprecation/removal. > > -mike > > > On Thu, Sep 16, 2021 at 8:03 PM Daniel Bratell <[email protected]> > wrote: > >> Good, because if not, I think it will leave the standard in a strange >> mess where a majority of the documentation will use constructs that no >> longer exists and that will make everyone unhappy. >> >> /Daniel >> On 2021-09-09 22:22, Rouslan Solomakhin wrote: >> >> Yes, we absolutely can fixup the docs that we own and reach out to the >> owners of the docs that we don't own ourselves. >> >> On Thu, Sep 9, 2021 at 4:21 PM Yoav Weiss <[email protected]> wrote: >> >>> Would you also be able to fix up the documentation out there that's >>> pointing at basic-card? >>> A few places I see at a glance are MDN >>> <https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API>, >>> WebFundementals >>> <https://developers.google.com/web/fundamentals/payments/merchant-guide/deep-dive-into-payment-request>, >>> Whatwebcando <https://whatwebcando.today/payments.html> , ayden.com >>> <https://www.adyen.com/blog/online-payments-using-the-new-web-payment-apis> >>> and samsung >>> <https://developer.samsung.com/internet/android/web-payments-integration-guide.html>. >>> It seems like with a few PRs and a bit of outreach, we can make sure that >>> the API's canonical documentation points people in the right direction. >>> >>> On Thu, Sep 9, 2021 at 9:28 PM Rouslan Solomakhin <[email protected]> >>> wrote: >>> >>>> Sure, let's do 4 milestones. We can put the deprecation message in the >>>> developer console in M96 and perform the removal in M100. >>>> >>>> On Thu, Sep 9, 2021 at 3:26 PM Mike West <[email protected]> wrote: >>>> >>>>> Ok. Does ~4-5 milestones (M100-101 sound good to you?) >>>>> >>>>> -mike >>>>> >>>>> >>>>> On Thu, Sep 9, 2021 at 9:20 PM Rouslan Solomakhin < >>>>> [email protected]> wrote: >>>>> >>>>>> > a deprecation period before removal isn't an unreasonable path >>>>>> forward. WDYT >>>>>> >>>>>> That sounds reasonable to us. We are planning a blog post, too, by >>>>>> the way. >>>>>> >>>>>> (Responding on behalf of Stephen and Max because they happen to be >>>>>> both OOO today.) >>>>>> >>>>>> On Thu, Sep 9, 2021 at 2:57 PM Mike West <[email protected]> wrote: >>>>>> >>>>>>> Given the UKM-driven manual analysis, I'm willing to believe that >>>>>>> sites using this mechanism won't crumble if it's removed. That said, the >>>>>>> deprecation in the spec that you pointed to above landed ~2 weeks ago. >>>>>>> Perhaps it's reasonable to extend developers' ability to conduct >>>>>>> transactions through this mechanism for a release or three before >>>>>>> removing >>>>>>> it, warning in the console about the deprecation, blog posting, etc. >>>>>>> >>>>>>> Perhaps I'm being unreasonably cautious here (and I'm totally >>>>>>> willing to hear reasons that might be the case!), but it seems to me >>>>>>> that a >>>>>>> deprecation period before removal isn't an unreasonable path forward. >>>>>>> WDYT? >>>>>>> >>>>>>> -mike >>>>>>> >>>>>>> >>>>>>> On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> When I looked around to see what other methods were available, it >>>>>>>> seemed to me like all documentation and explainers included basic-card >>>>>>>> as >>>>>>>> the standard method, and few of them used anything else. I wonder if >>>>>>>> that >>>>>>>> means that it's too early to deprecate before documentation and specs >>>>>>>> is >>>>>>>> updated to suggest alternatives. >>>>>>>> >>>>>>>> /Daniel >>>>>>>> >>>>>>>> >>>>>>>> On 2021-09-09 14:14, Stephen Mcgruer wrote: >>>>>>>> >>>>>>>> > Can you clarify what breakage may look like for sites that may >>>>>>>> rely on it? >>>>>>>> >>>>>>>> If a site was *entirely* relying on basic-card to collect credit >>>>>>>> card details from their user, it would be impossible for the user to >>>>>>>> complete their checkout. So arguably 'site completely broken' from that >>>>>>>> perspective (assuming buying a thing is the main user journey). >>>>>>>> >>>>>>>> However, such a site would also be broken on Firefox and Safari >>>>>>>> today (unless serving user-agent specific code), and sites also tend >>>>>>>> to not >>>>>>>> rely on just one approach to get paid. Sites will almost definitely >>>>>>>> have a >>>>>>>> fallback mechanism, and it will likely be invisible to the user. For >>>>>>>> example: >>>>>>>> >>>>>>>> 1. Site checks `if (window.PaymentRequest)` - passes in Chrome and >>>>>>>> Safari, fails in Firefox. >>>>>>>> 2. Site calls `new >>>>>>>> PaymentRequest([basic-card-data]).canMakePayment()` (or `show()` >>>>>>>> directly) >>>>>>>> - passes in Chrome today, fails/throws in Safari. >>>>>>>> 3. If either of #1 or #2 failed, render a fallback payment >>>>>>>> information collection flow such as a HTML form. >>>>>>>> >>>>>>>> TL;DR - we expect very few to no sites to break due to this >>>>>>>> removal, unless they're doing user-agent specific branching with no >>>>>>>> fallback mechanisms for 'what if basic-card fails'. >>>>>>>> >>>>>>>> On Thu, 9 Sept 2021 at 08:03, Yoav Weiss <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Can you clarify what breakage may look like for sites that may >>>>>>>>> rely on it? >>>>>>>>> >>>>>>>>> On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> > Any usecounter stats you can share? >>>>>>>>>> >>>>>>>>>> Unfortunately no usecounters for two reasons: >>>>>>>>>> >>>>>>>>>> 1) Payment APIs in general have very low usage when compared to >>>>>>>>>> 'page loads', because the most popular sites on the web aren't >>>>>>>>>> merchants >>>>>>>>>> and so don't use them. For example, PaymentRequest.show is at >>>>>>>>>> 0.001 >>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/2895>. >>>>>>>>>> They're still very important, so we have to measure usage other ways >>>>>>>>>> :) >>>>>>>>>> >>>>>>>>>> 2) In particular for basic-card, it's actually just a method-type >>>>>>>>>> of PaymentRequest, so our top-level usecounters don't show it. >>>>>>>>>> >>>>>>>>>> We have internal stats that I can't share publicly due to >>>>>>>>>> sensitivity (Googlers, feel free to ping me for a link), but I can >>>>>>>>>> share >>>>>>>>>> that of transactions using PaymentRequest, basic-card is ~2% of all >>>>>>>>>> transactions and <1% of completed transactions. So it's a very niche >>>>>>>>>> feature that also performs poorly. >>>>>>>>>> >>>>>>>>>> Max has also done an analysis of the top 10 sites from UKM data >>>>>>>>>> that use basic-card. For 4, he couldn't get to the payments page or >>>>>>>>>> couldn't get it to trigger basic-card at all (possibly geographically >>>>>>>>>> gated), but for the remaining 6 he confirmed that all 6 function >>>>>>>>>> properly >>>>>>>>>> in a version of Chrome that has basic-card disabled (falling back to >>>>>>>>>> the >>>>>>>>>> same behavior they use for Firefox + Safari). >>>>>>>>>> >>>>>>>>>> On Mon, 6 Sept 2021 at 03:26, Yoav Weiss <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Contact emails [email protected], [email protected] >>>>>>>>>>>> >>>>>>>>>>>> Specification https://www.w3.org/TR/payment-method-basic-card/ >>>>>>>>>>>> >>>>>>>>>>>> Summary >>>>>>>>>>>> >>>>>>>>>>>> Deprecate the "basic-card" payment method from PaymentRequest >>>>>>>>>>>> API. >>>>>>>>>>>> >>>>>>>>>>>> Blink component Blink>Payments >>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments> >>>>>>>>>>>> >>>>>>>>>>>> Motivation >>>>>>>>>>>> >>>>>>>>>>>> * Its usage is low and declining, underperforms other payment >>>>>>>>>>>> methods in time-to-checkout and completion rate and does not have >>>>>>>>>>>> improvement potential. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Any usecounter stats you can share? >>>>>>>>>>> >>>>>>>>>>>> * W3C's interest in it has waned. 6 participants supported the >>>>>>>>>>>> deprecation and no objection[1], and W3C has deprecated the >>>>>>>>>>>> spec[2]. [1] >>>>>>>>>>>> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html >>>>>>>>>>>> [2] >>>>>>>>>>>> https://github.com/w3c/payment-method-basic-card/pull/90/files >>>>>>>>>>>> >>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>> * Chrome is the only implementer of basic-card, so the >>>>>>>>>>>> basic-card removal from Chrome will increase interoperability. >>>>>>>>>>>> * Since no other browser implements basic-card, web developers >>>>>>>>>>>> already need workarounds to support other browsers. >>>>>>>>>>>> * Whether basic-card is supported can be detected via >>>>>>>>>>>> canMakePayment >>>>>>>>>>>> <https://w3c.github.io/payment-request/#canmakepayment-method>. >>>>>>>>>>>> Web developers normally use this to decide whether to fallback to >>>>>>>>>>>> other methods. >>>>>>>>>>>> * We have checked the few top sites via UKM - they all appear >>>>>>>>>>>> to work with basic-card disabled because they fallback to other >>>>>>>>>>>> methods to >>>>>>>>>>>> get payment info. >>>>>>>>>>>> >>>>>>>>>>>> Tracking bug https://crbug.com/1209835 >>>>>>>>>>>> >>>>>>>>>>>> Estimated milestones M96 >>>>>>>>>>>> >>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>> https://chromestatus.com/feature/5730051011117056 >>>>>>>>>>>> >>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>> <https://www.chromestatus.com/>. >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google Groups "payments-dev" group. >>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAL5BFfUaHsXJEEwN3JO2MSGw9WHsVt5nszPPscKh9mBrRt5U1g%40mail.gmail.com >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAL5BFfUaHsXJEEwN3JO2MSGw9WHsVt5nszPPscKh9mBrRt5U1g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafMcTV1GOHS62bHd%2BK%2BH1ftH0pBZL_1k77GWJqK8o9Uvg%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafMcTV1GOHS62bHd%2BK%2BH1ftH0pBZL_1k77GWJqK8o9Uvg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25df3c17-3cf3-695a-451f-ef1007581d53%40gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25df3c17-3cf3-695a-451f-ef1007581d53%40gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "payments-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAKXHy%3De-AdXxo8CtZrSk-iPN05KmJ0_FWHOw5duyBXFGR58oGA%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAKXHy%3De-AdXxo8CtZrSk-iPN05KmJ0_FWHOw5duyBXFGR58oGA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWEfPJfq%3DJCkLZ%3DFQ0TPTjXDqfu36d3rOOUYCMnYuipiVA%40mail.gmail.com.
