Note on API shape #99
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ion it will change.
rsolomakhin
requested changes
Aug 10, 2021
spec.bs
Outdated
Comment on lines
372
to
383
| <div class="note">This specification describes an API implemented | ||
| to support a Stripe pilot that began in December 2020. To quickly | ||
| provide support for that experiment, the Chrome team added SPC | ||
| support atop existing implementations of the Payment Request and | ||
| Payment Handler APIs. However, given findings from the pilot and | ||
| subsequent use case and requirements discussions, there is now | ||
| general agreement that SPC should be usable independent of Payment | ||
| Request. To foster more experimentation in a timely fashion we are | ||
| moving forward with the API in its current form, but we expect | ||
| (without a concrete timeline) that SPC will move away from its | ||
| Payment Request origins. For developers, this should improve | ||
| feature detection, invocation, and other aspects of the API.</div> |
There was a problem hiding this comment.
That's a lot of information... Could it be simplified into this?
Suggested change
| <div class="note">This specification describes an API implemented | |
| to support a Stripe pilot that began in December 2020. To quickly | |
| provide support for that experiment, the Chrome team added SPC | |
| support atop existing implementations of the Payment Request and | |
| Payment Handler APIs. However, given findings from the pilot and | |
| subsequent use case and requirements discussions, there is now | |
| general agreement that SPC should be usable independent of Payment | |
| Request. To foster more experimentation in a timely fashion we are | |
| moving forward with the API in its current form, but we expect | |
| (without a concrete timeline) that SPC will move away from its | |
| Payment Request origins. For developers, this should improve | |
| feature detection, invocation, and other aspects of the API.</div> | |
| <div class="note">This specification describes an API implemented | |
| atop existing implementations of the Payment Request. We expect | |
| (without a concrete timeline) that SPC will move away from its | |
| Payment Request implementation to align better with WebAuthn. | |
| For developers, this should improve feature detection, invocation, | |
| and other aspects of the API.</div> |
There was a problem hiding this comment.
@rsolomakhin, I think the rationale / history is useful. I don't mind shortening it. Let me edit a bit...
rsolomakhin
requested changes
Aug 10, 2021
spec.bs
Outdated
Comment on lines
374
to
375
| Request and Payment Handler APIs. There is now general agreement | ||
| that SPC should be usable independent of Payment Request. We |
There was a problem hiding this comment.
Perhaps "There is not general agreement that using SPC independent of Payment Request should be considered" or "should be explored"? I don't want to make it sound like we have a concrete plan in place.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New note with background on current shape of API and setting expectation it will change.
Relates to issues #81 and #65 (but does not close them).