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/CAMMzaWHJoKpd_3ct0xeS_JZbdo9cV4ifRDL30n_Ve5ZdZUWEEg%40mail.gmail.com.
