Re: [w3c/payment-request] Allow incremental request of billing and shipping address (#873)

marcoscaceres commented on this pull request.



> +              the user's privacy can use <a>requestShippingAddressParts</a> to
+              restrict the initial set of address parts returned by the
+              <a>user agent</a>.
+            </p>
+          </aside>
+        </dd>
+        <dt>
+          <dfn>requestShippingAddressParts</dfn> member
+        </dt>
+        <dd>
+          A sequence of {{AddressParts}} that specifies which fine-grained
+          parts of the shipping address that the payee wishes to receive when
+          the <a>requestShipping</a> member is true. An empty list means no
+          restriction, i.e. the <a>user agent</a> will return the full shipping
+          address, subject to the
+          <a>shipping redact list</a>. This field has no effect if the

We generally try to avoid the word "field", as it's ambiguous in the context of JS/WebIDL. Properties on dictionaries are formally referred to as "members".

```suggestion
          <a>shipping redact list</a>. The {{PaymentOptions/requestShippingAddressParts}} member has no effect if the
```

> +              restrict the initial set of address parts returned by the
+              <a>user agent</a>.
+            </p>
+          </aside>
+        </dd>
+        <dt>
+          <dfn>requestShippingAddressParts</dfn> member
+        </dt>
+        <dd>
+          A sequence of {{AddressParts}} that specifies which fine-grained
+          parts of the shipping address that the payee wishes to receive when
+          the <a>requestShipping</a> member is true. An empty list means no
+          restriction, i.e. the <a>user agent</a> will return the full shipping
+          address, subject to the
+          <a>shipping redact list</a>. This field has no effect if the
+          <a>requestShipping</a> member is false. The payee can request

```suggestion
          {{PaymentOptions/requestShipping}} member is false. The payee can request
```

> @@ -2830,7 +2983,8 @@ <h2>
         <p>
           The steps to <dfn>create a `PaymentAddress` from user-provided
           input</dfn> are given by the following algorithm. The algorithm takes
-          a <a>list</a> |redactList|.
+          a <a>list</a> |redactList| and a
+          <a>sequence</a>&lt;<a>AddressParts</a>&gt; |requestedParts|.

```suggestion
          <a>sequence</a>&lt;{{AddressParts}}&gt; |requestedParts|.
```

> @@ -3915,6 +4098,119 @@ <h2>
             more information.
           </p>
         </section>
+        <section>
+          <h2>
+            <dfn data-lt="requestBillingAddress(addressParts)">
+              requestBillingAddress()
+            </dfn> method
+          </h2>
+          <aside class="note">
+            <p>
+              The {{PaymentMethodChangeEvent/requestBillingAddress()}} method
+              allows the developer to incrementally request additional pieces of
+              the billing address that were not initially requested in
+              {{ PaymentOptions.requestBillingAddressParts }}.

Just noting that the usage of {{X.Y}} in other parts of the spec is wrong... I need to fix those ☺️ The {{X.Y}} means "access **static** method/attribute Y on X" - while {{X / Y}} means "access the **instance** method/attribute Y of X"

```suggestion
              {{ PaymentOptions/requestBillingAddressParts }}.
```

> +
+              // ❌ Bad - this won't work!
+              request.onshippingaddresschange = (ev) =&gt; {
+                // This will throw InvalidStateError since not inside updateWith().
+                ev.requestShippingAddress([]);
+
+                ev.updateWith(getPromiseForNewDetails(ev.target.shippingAddress));
+              };
+            </pre>
+          </aside>
+          <p>
+            The <a>requestShippingAddress(|addressParts|)</a> method MUST act as
+            follows:
+          </p>
+          <ol class="algorithm">
+            <li>Let |event:PaymentRequestUpdateEvent| be this

I'm ok to defer. 

-- 
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/payment-request/pull/873#pullrequestreview-315994719