Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452)

Yeah, it's a bit confusing because this is defined partially in Web IDL and partially in the prose. Here is the breakdown of how things would work after this spec PR:

```js
const p = new PaymentRequest(m, d);
p.requestShipping === false;
p.shippingType === null;
```

```js
const p = new PaymentRequest(m, d, { });
p.requestShipping === false;
p.shippingType === null;
```

```js
const p = new PaymentRequest(m, d, { requestShipping: false });
p.requestShipping === false;
p.shippingType === null;
```

```js
const p = new PaymentRequest(m, d, { requestShipping: false, shippingType: "shipping" });
p.requestShipping === false;
p.shippingType === null;
```

```js
const p = new PaymentRequest(m, d, { requestShipping: true });
p.requestShipping === true;
p.shippingType === "shipping";
```

```js
const p = new PaymentRequest(m, d, { requestShipping: true, shippingType: "delivery" });
p.requestShipping === true;
p.shippingType === "delivery";
```

```js
new PaymentRequest(m, d, { requestShipping: true, shippingType: "asdf" });
// throws an exception
```

```js
new PaymentRequest(m, d, { requestShipping: true, shippingType: null });
// throws an exception
```

Currently what the spec says doesn't make any sense, so it needs to be fixed. But we could fix it so that the first 4 cases have `p.shippingType === null`, or `p.shippingType === "shipping"`. This patch goes with `null` but we could go either way.

ALSO: I just noticed this PR needs some tweaks because I forgot there's a step before this that already sets it to null. So I should combine those two steps. So please nobody merge yet. But sign off on the behavior would be good :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/452#issuecomment-285558986