chore(tidy): tidy up document

Author: plehegar

index.html

@@ -1013,16 +1013,16 @@ <h2>
               <p>
                 This allows the user agent to not require user activation, for
                 example to support redirect flows where a user activation may
-                not be present upon redirect. See
-                <a href="#user-activation-requirement"></a> for security
+                not be present upon redirect. See <a href=
+                "#user-activation-requirement"></a> for security
                 considerations.
               </p>
               <p>
-                See also
-                <a href="https://github.com/w3c/payment-request/issues/1022">
-                issue #1022</a> for discussion around providing more guidance
-                in the specification on when user agents should or should not
-                require a user activation for {{PaymentRequest/show()}}.
+                See also <a href=
+                "https://github.com/w3c/payment-request/issues/1022">issue
+                #1022</a> for discussion around providing more guidance in the
+                specification on when user agents should or should not require
+                a user activation for {{PaymentRequest/show()}}.
               </p>
             </div>
           </li>
@@ -4514,24 +4514,24 @@ <h2 id="user-activation-requirement">
         </h2>
         <p>
           If the user agent does not require user activation as part of the
-          {{PaymentRequest/show()}} method, some additional security mitigations
-          should be considered. Not requiring user activation increases the risk
-          of spam and click-jacking attacks, by allowing a Payment Request UI
-          to be initiated without the user interacting with the page immediately
-          beforehand.
+          {{PaymentRequest/show()}} method, some additional security
+          mitigations should be considered. Not requiring user activation
+          increases the risk of spam and click-jacking attacks, by allowing a
+          Payment Request UI to be initiated without the user interacting with
+          the page immediately beforehand.
         </p>
         <p>
-          In order to mitigate spam, the user agent may decide to enforce a user
-          activation requirement after some threshold, for example after the
-          user has already been shown a Payment Request UI without a user
+          In order to mitigate spam, the user agent may decide to enforce a
+          user activation requirement after some threshold, for example after
+          the user has already been shown a Payment Request UI without a user
           activation on the current page. In order to mitigate click-jacking
-          attacks, the user agent may implement a time threshold in which clicks
-          are ignored immediately after a dialog is shown.
+          attacks, the user agent may implement a time threshold in which
+          clicks are ignored immediately after a dialog is shown.
         </p>
         <p>
           Another relevant mitigation exists in step 6 of
-          {{PaymentRequest/show()}}, where the document must be visible in order
-          to initiate the user interaction.
+          {{PaymentRequest/show()}}, where the document must be visible in
+          order to initiate the user interaction.
         </p>
       </section>
     </section>