From c1b702c0335a52956881e1ed033bfddd288da9d1 Mon Sep 17 00:00:00 2001
From: Ade Bateman <bateman@acm.org>
Date: Thu, 7 Jul 2016 12:12:56 +0100
Subject: [PATCH] Removing notes for closed issues.

---
 index.html | 36 ------------------------------------
 1 file changed, 36 deletions(-)

diff --git a/index.html b/index.html
index 6aba8907..a401ad54 100644
--- a/index.html
+++ b/index.html
@@ -341,18 +341,6 @@ <h2>PaymentRequest constructor</h2>
           </pre>
     </div>
 
-    <div class="issue" data-number="15" title="Combine API parameters into a single request object + options">
-      There is an open issue about whether <code>methodData</code>, <code>details</code>, and <code>data</code>
-      should be combined into a single object.
-    </div>
-
-    <div class="issue" data-number="51" title="Should the payment API be more conversational or less conversational?">
-      There is an open issue regarding whether the current pattern of using
-      events for exchange of data between the user agent and the website is
-      the best design for this API. An alternative pattern has been
-      proposed in the issue thread.
-    </div>
-
     <p>
       The <a><code>PaymentRequest</code></a> constructor MUST act as follows:
     </p>
@@ -496,20 +484,6 @@ <h2>abort()</h2>
       reject the returned <a>Promise</a>.
     </p>
 
-    <p class="issue" data-number="39" title="How are web-based payment apps supported?">
-      The architecture document suggests that payment apps may take
-      numerous forms, including as web-based apps. This specification
-      should describe how the user-agent will pass the payment request
-      data and the complete signal to a web-based payment app and also how
-      it will receive the payment response from the payment app.
-    </p>
-
-    <p class="issue" data-number="50" title="How are payment requests and responses passed between the browser and third-party native wallets?">
-      This specification should describe how the user agent will pass the
-      payment request data and the complete signal to a native payment app
-      and also how it will receive the payment response from the payment app.
-    </p>
-
     <p>The <a><code>abort</code></a> method MUST act as follows:</p>
     <ol>
       <li>
@@ -846,10 +820,6 @@ <h2>PaymentItem dictionary</h2>
         There is an open issue about whether it should be possible to provide a <code>PaymentItem</code>
         with amounts in more than once currency.
       </div>
-      <div class="issue" data-number="4" title="Should it be possible to vary amounts depending on payment method">
-        There is an open issue about whether it should be possible to provide a different amounts depending
-        upon the payment method.
-      </div>
     </dd>
   </dl>
 </section>
@@ -1214,12 +1184,6 @@ <h2>updateWith()</h2>
   </section>
 </section>
 
-<p class="issue" data-number="53" title="Add section on internationalization">
-  The spec needs to clearly state how it will handle internationalization
-  issues (such as selection order for language via explicit preferences,
-  Accept-Language headers, etc.)
-</p>
-
 <section>
   <h2>Algorithms</h2>