-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop PaymentAddress, shipping + billing address support #955
Conversation
This pull request removes a number of features from the specification around addresses and contact information. I have marked it as blocked because it will require some review before we proceed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gave this a print and run through... changes seem fine.
Thanks @marcoscaceres. I’d like to run this by the group. |
Sure, take your time! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@@ -353,40 +309,12 @@ <h3> | |||
total: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this example can be made more clear by adding a new display item for shipping? e.g.
displayItems: [
{ // sub-total },
{ // tax },
{
label: "Standard shipping",
amount: { currency: "GBP", value: "5.00" },
},
]
… but the label referred to VAT. Fixed the label to refer to shipping
We discussed this pull request at today's WPWG meeting: There were no objections to it. We have a couple of things to do before a CfC to the WG to proceed (back) to CR Ian |
@samuelweiler, can you let us know if removing address features through this pull request would address your concern (raised in #842)? Thank you. |
@ianbjacobs, when you merge, please make sure the merge message is clear (e.g., "Remove PaymentAddress, shipping + billing address support" or something similar). |
Test removals: web-platform-tests/wpt#28830 |
2) Removed shipping, contact information to align with PR 955 on PR API w3c/payment-request#955
Filed bugs on Firefox and Safari (links at the top). @rsolomakhin, could you please do the same for Blink? |
Filed https://crbug.com/1206261 for Blink. |
👋😭 so long |
w3c/payment-request@486c07a (w3c/payment-request#955) removed the PaymentAddress and PayerErrors objects from the Payment Request specification — as well as removing related members from the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. So this change marks PaymentAddress and PayerErrors as deprecated and standard_track:false, as well as all their members, and the related members of the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. The change also removes all the spec URLs for the deprecated features (they’re no longer in the spec).
w3c/payment-request@486c07a (w3c/payment-request#955) removed the PaymentAddress and PayerErrors objects from the Payment Request specification — as well as removing related members from the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. So this change adds Deprecated and Non-standard banners to the PaymentAddress and PayerErrors articles, as well as to he articles for all their member, and to the articles for the related members of the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. The change also removes all the Specifications tables for the deprecated features (they’re no longer in the spec). Related BCD change: mdn/browser-compat-data#10413
w3c/payment-request@486c07a (w3c/payment-request#955) removed the PaymentAddress and PayerErrors objects from the Payment Request specification — as well as removing related members from the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. So this change adds Deprecated and Non-standard banners to the PaymentAddress and PayerErrors articles, as well as to the articles for all their member, and to the articles for the related members of the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. The change also removes all the Specifications tables for the deprecated features (they’re no longer in the spec). Related BCD change: mdn/browser-compat-data#10413
w3c/payment-request@486c07a (w3c/payment-request#955) removed the PaymentAddress and PayerErrors objects from the Payment Request specification — as well as removing related members from the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. So this change adds Deprecated and Non-standard banners to the PaymentAddress and PayerErrors articles, as well as to the articles for all their member, and to the articles for the related members of the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. The change also removes all the Specifications tables for the deprecated features (they’re no longer in the spec). Related BCD change: mdn/browser-compat-data#10413
w3c/payment-request@486c07a (w3c/payment-request#955) removed the PaymentAddress and PayerErrors objects from the Payment Request specification — as well as removing related members from the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. So this change marks PaymentAddress and PayerErrors as deprecated and standard_track:false, as well as all their members, and the related members of the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. The change also removes all the spec URLs for the deprecated features (they’re no longer in the spec). Related MDN change: mdn/content#4850
FYI, I’ve raised PRs to make corresponding updates to MDN and BCD — |
… request 955) (#389) 1) Andre Lyver moved to former editor 2) Removed shipping, contact information to align with PR 955 on PR API w3c/payment-request#955 * minor fix to index.html updated tidyconfig to align with PR API version * remove tidy mark + fixup ws * removed some whitespace Co-authored-by: Marcos Cáceres <marcos@marcosc.com>
@rayankans, wrote:
Yeah, let's move it over. We can also give it a better name as it's not longer tied to payments. |
@rayankans could you kindly mention me on your issue for moving it? We have some input related to w3c/contact-picker#71 that is not relevant to this repo anymore. Other |
The ContactAddress interface used to depends on the PaymentAddress interface defined in the Payment Request spec. That definition was recently removed in w3c/payment-request#955.
w3c/payment-request@486c07a (w3c/payment-request#955) removed the PaymentAddress and PayerErrors objects from the Payment Request specification — as well as removing related members from the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. So this change adds Deprecated and Non-standard banners to the PaymentAddress and PayerErrors articles, as well as to the articles for all their member, and to the articles for the related members of the PaymentRequest, PaymentResponse, and PaymentDetailsUpdate objects. The change also removes all the Specifications tables for the deprecated features (they’re no longer in the spec). Related BCD change: mdn/browser-compat-data#10413
Not implemented by anyone and wasn't in the spec even before w3c/payment-request#955.
This reverts commit 486c07a.
This reverts commit 486c07a.
This reverts commit 486c07a.
This reverts commit 486c07a.
This reverts commit 486c07a.
This reverts commit 486c07a.
closes #842,
closes #939,
as well as issues raised to add family name, given name, and phonetic name:
closes w3c/contact-picker#69
closes w3c/contact-picker#70
This edit also reduces the number of strings in the specification, which means there are fewer (but still some) strings requiring better lang/dir support.
Also closes the follow address related issues:
closes #902
closes w3c/contact-picker#71
closes #888
closes w3c/contact-picker#72
closes w3c/contact-picker#65
closes #653
closes #615
closes #614
closes #548
closes #537
closes #389
The following tasks have been completed:
Implementation commitment:
Optional, impact on Payment Handler spec?
If these changes are adopted, then we will also want to make corresponding changes in Payment Handler API to remove API-level data (instead of payment method level data).
Preview | Diff