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/CAKXHy%3DfO748E2rv86%2Bqq5j10BBVFTgfC4HYXJgUEeeN3y8rFoA%40mail.gmail.com.
