From fee46a298de7ac02af780a20696e13a511c85dd8 Mon Sep 17 00:00:00 2001
From: Ade Bateman <bateman@acm.org>
Date: Thu, 7 Apr 2016 08:05:33 -0700
Subject: [PATCH] Change e.g. to e.g.,

Fixes #66.
---
 specs/method-identifiers.html |  2 +-
 specs/paymentrequest.html     | 12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/specs/method-identifiers.html b/specs/method-identifiers.html
index d765ecfa..0c316d7d 100644
--- a/specs/method-identifiers.html
+++ b/specs/method-identifiers.html
@@ -415,7 +415,7 @@ <h2>Issues</h2>
         <p>The following issues are tracking aspects of the payment method identifier specification:</p>
 
         <div class="issue" data-number="11" title="What is the format for payment method identifiers for distributed extensibility">
-          <p>Should the format of the identifiers be URLs (e.g. http://example.com/paymentmethod) or reverse host name (e.g. com.example.paymentmethod) or some other extensible syntax?</p>
+          <p>Should the format of the identifiers be URLs (e.g., http://example.com/paymentmethod) or reverse host name (e.g., com.example.paymentmethod) or some other extensible syntax?</p>
           <p>If the identifier is a URL, should there be a resource that can be fetched from the URL?</p>
           <p>Is there a need to describe the payment method at the URL or provide some other information?</p>
         </div>
diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html
index 7d269907..556ee0fc 100644
--- a/specs/paymentrequest.html
+++ b/specs/paymentrequest.html
@@ -73,7 +73,7 @@
       <p>
         This specification describes a web API to allow merchants (i.e. web sites selling
         physical or digital goods) to easily accept payments from different payment methods with
-        minimal integration. User agents (e.g. browsers) will facilitate the payment flow between
+        minimal integration. User agents (e.g., browsers) will facilitate the payment flow between
         merchant and user.
       </p>
     </section>
@@ -100,15 +100,15 @@ <h2>Introduction</h2>
         over and over again. Likewise, it is difficult and time consuming for developers to create good
         checkout flows that support various payment schemes.</p>
 
-        <p>This specification describes an API that allows <a>user agents</a> (e.g. browsers) to act
-        as an intermediary between the three key parties in every transaction: the merchant (e.g. an
-        online web store), the buyer (e.g. the user buying from the online web store), and the
-        <a>Payment Method</a> (e.g. credit card). Information necessary to process and confirm a
+        <p>This specification describes an API that allows <a>user agents</a> (e.g., browsers) to act
+        as an intermediary between the three key parties in every transaction: the merchant (e.g., an
+        online web store), the buyer (e.g., the user buying from the online web store), and the
+        <a>Payment Method</a> (e.g., credit card). Information necessary to process and confirm a
         transaction is passed between the <a>Payment Method</a> and the merchant via the <a>user agent</a>
         with the buyer confirming and authorizing as necessary across the flow.</p>
 
         <p>In addition to better, more consistent user experiences, this also enables web sites to take
-        advantage of more secure payment schemes (e.g. tokenization and system-level authentication)
+        advantage of more secure payment schemes (e.g., tokenization and system-level authentication)
         that are not possible with standard JavaScript libraries. This has the potential to reduce
         liability for the merchant and helps protect sensitive user information.</p>