Technically, yes. Deprecation warnings should only land when we're _actually_ going to deprecate a thing, and have a reasonable schedule to point to.
Here, though, I think we have agreement that the deprecation itself is reasonable, and agreement on a schedule. We're only blocking on documentation of alternatives and developer awareness, both of which deprecation warnings support. So, I'd LGTM CLs that added warnings if you wanted to send them my way. -mike On Thu, Sep 16, 2021 at 9:17 PM Rouslan Solomakhin <[email protected]> wrote: > 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/CAKXHy%3DeRtBt-6pSLPL%2BuqJ5v-U63EPH9U3i3n4O2_bj3XnV15A%40mail.gmail.com.
