Add support for ShippingOption.selected. #179
Conversation
| will be set to the <code>id</code> of this option without running the <a>shipping option changed | ||
| algorithm</a>. Authors SHOULD NOT set <code>selected</code> to <code>true</code> on more than | ||
| one item. If more than one item in the sequence has <code>selected</code> set to <code>true</code>, | ||
| then <a>user agents</a> MUST select the last one in the sequence.</p> |
There was a problem hiding this comment.
There are two ways to read this line, so it's slightly unclear if the UAs should select the last one in the sequence of shipping options, or the last one in the sequence /with the selected flag set to true/. I think you mean the latter.
|
Is there a plan to include this "default" option for email as well? Here's the concern: Collecting email at the very last step in the shopping process means that email retargeting is an issue (what happens when the customer leaves the cart before hitting "buy" in a guest checkout scenario?). Some merchants want to be able to easily do email retargeting if a shopping cart is abandoned. This means they'll attempt to collect an email before the customer attempts to checkout (not using the Web Payments Browser API). If they then call the Browser API requesting an email address, the customer may get annoyed that they have to specify their email twice. The customer most likely expect to have a default email specified if the merchant knows what it is. |
|
In general, I'm a -1 to any PR that tries to collect general customer information (like shipping address, phone, email, coupons, loyalty number, etc.) via a payment request API because I think it's the wrong place to put this feature. Customer information collection should be split out into a separate spec (Customer Information API) and the group should be re-chartered to work on that API as well (doing so wouldn't slow the group down as the re-chartering process would happen in parallel). We're already doing that API, it seems. There are clean ways to mix the use of both APIs in a single UI (as the Web Payments Community Group Checkout API demonstrated). That said, if the browser vendors (with the support of the WG) insist on pushing forward with this direction, I'm a +1 to the PR because if we're going to collect shipping address and email, we should have defaults for both of those fields. |
| has the <code>selected</code> field set to <code>true</code>, then set | ||
| <a><code>shippingOption</code></a> to the <code>id</code> of the last <a><code>ShippingOption</code></a> | ||
| in the sequence with <code>selected</code> set to <code>true</code>. | ||
| </li> |
There was a problem hiding this comment.
I'd be hesitant to make this a conformance issue, though. It may be perfectly reasonable for the user agent to use locally-configured preferences to override the "selected" flag; e.g., "remember my choice from last time" or "always default to the cheapest shipping option." So I would far prefer to see this specified as a hint rather than a normative behavior.
There was a problem hiding this comment.
A user-agent could still do that just not without firing the change event.
There was a problem hiding this comment.
Sure, that's fine. I just want such behavior to be technically conformant. The conformance section of this document denotes everything except a named list of items as normative, and this step -- which specifies that the shippingOption is set a certain way -- doesn't fall into any of the named non-normative categories. That makes performing such action mandatory for conformance purposes, and I think that's too strict.
|
msporny, I see what you are saying about the separation of these apis, but I also see a real need for acquiring at least address information because this can affect the payment amount and the payment app's ability to be used at all. I would be fine with acquiring the address strictly before hitting the payment api, but we have already seen cases where the two intermingle and I don't think blending two specs together to be implement a flow will be very straightforward. |
|
Not discussed 5 May, on agenda for 12 May |
|
Postponed again to 19 May |
|
Merged as 6846037 per telcon. |
This PR affects the case when
requestShippingistrue.Currently the spec supports the idea that providing no shipping options means that the current shipping address is not supported and that providing a single shipping option means that shipping option should be used. This helps to smooth the payment request experience because the user doesn't have to pick a shipping option.
If more than one shipping option is provided, the merchant may still know which they want to be the default and they should be able to indicate this so that the user doesn't have to explicitly pick one. Also, if the user chooses a shipping address, and then chooses a shipping option, but then changes to a different shipping address, the merchant should be able to preserve the user's choice of option even after recalculating new shipping costs.
This PR adds a
selectedfield to theShippingOptionand updates the algorithms to use it.