Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add reference to issue #47. #81

Closed
wants to merge 3 commits into from
Closed

Add reference to issue #47. #81

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
81b3240
Remove trailing whitespace.
msporny Mar 14, 2016
3ddca06
Add reference to issue #47.
msporny Mar 16, 2016
2eef634
Simplify reference to issue #47.
msporny Mar 29, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
82 changes: 44 additions & 38 deletions specs/paymentrequest.html
View file
Open in desktop
Expand Up @@ -89,7 +89,7 @@
<a href="https://www.w3.org/community/wicg/">Web Platform Incubator Community Group</a>.
</p>
</section>

<section class='informative'>
<h2>Introduction</h2>
<p>Buying things on the
Expand Down Expand Up @@ -133,50 +133,50 @@ <h2>Non-goals</h2>
</section>

</section>

<section id='conformance'>
<p>
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
and notes in this specification are non-normative. Everything else in this specification is
normative.
</p>
<p>
This specification defines one class of products:
</p>
<dl>
<dt><dfn>Conforming user agent</dfn></dt>
<dd>
<p>
A <dfn data-lt="user agents">user agent</dfn> MUST behave as described in this specification
<p>
This specification defines one class of products:
</p>
<dl>
<dt><dfn>Conforming user agent</dfn></dt>
<dd>
<p>
A <dfn data-lt="user agents">user agent</dfn> MUST behave as described in this specification
in order to be considered conformant. In this specification, <a>user agent</a> means a <em>Web
browser or other interactive user agent</em> as defined in [[!HTML5]].
</p>
<p>
User agents MAY implement algorithms given in this
specification in any way desired, so long as the end result is
indistinguishable from the result that would be obtained by the
specification's algorithms.
</p>
<p>
A conforming Payment Request API user agent MUST also be a
<em>conforming implementation</em> of the IDL fragments
of this specification, as described in the
“Web IDL” specification. [[!WEBIDL]]
</p>

<aside class="note">
This specification uses both the terms "conforming user agent(s)"
and "user agent(s)" to refer to this product class.
</aside>
<p>
User agents MAY implement algorithms given in this
specification in any way desired, so long as the end result is
indistinguishable from the result that would be obtained by the
specification's algorithms.
</p>
<p>
A conforming Payment Request API user agent MUST also be a
<em>conforming implementation</em> of the IDL fragments
of this specification, as described in the
“Web IDL” specification. [[!WEBIDL]]
</p>

<aside class="note">
This specification uses both the terms "conforming user agent(s)"
and "user agent(s)" to refer to this product class.
</aside>
</dd>
</section>

<section id="dependencies">
<h3>Dependencies</h3>
<p>
This specification relies on several other underlying specifications.
</p>
<dl>
<section id="dependencies">
<h3>Dependencies</h3>
<p>
This specification relies on several other underlying specifications.
</p>
<dl>
<dt>Payment Request Document Architecture</dt>
<dd>The terms <dfn data-lt="payment method|payment methods">Payment Method</dfn>,
<dfn data-lt="payment app|payment apps">Payment App</dfn>, and <dfn>Payment Transaction
Expand All @@ -200,7 +200,7 @@ <h3>Dependencies</h3>
be serialized to a string using <a>JSON.stringify</a> and later deserialized back to an object
using <a>JSON.parse</a> with no loss of data.</p>
</dd>
<dt>DOM4</dt>
<dt>DOM4</dt>
<dd>
The <code><dfn>Event</dfn></code> type and the terms <dfn>fire an event</dfn>, <dfn>dispatch flag</dfn>,
<dfn>stop propagation flag</dfn>, and <dfn>stop immediate propagation flag</dfn> are defined by [[!DOM4]].
Expand Down Expand Up @@ -249,7 +249,7 @@ <h2>PaymentRequest interface</h2>
<a>user agent</a> while the user is providing input before approving or denying a payment request.
</p>

<p>The following example shows how to construct a <a><code>PaymentRequest</code></a> and begin the
<p>The following example shows how to construct a <a><code>PaymentRequest</code></a> and begin the
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@msporny Can you reword this to be a lot simpler and leave the deeper explanation for users to read in the issue itself? I would also suggest placing this issue marker alongside those for #15 and #16 which also relate to the shape of the API.

Suggestion:

<div class="issue" data-number="47" title="Should a payment request be just data, or a 
programmable object?"> There is an open issue about whether the payment request should 
be a programmable object or should be just pure data that can be operated on by methods.</div>

user interaction:</p>

<pre class="example highlight">
Expand Down Expand Up @@ -341,6 +341,12 @@ <h2>PaymentRequest constructor</h2>
currently described in the specification.
</div>

<div class="issue" data-number="47" title="Should a payment request be just data, or a programmable object?">
There is an open issue about whether the payment request should
be a programmable object or should be just pure data that can be
operated on by methods.
</div>

<div class="issue" data-number="19" title="Should the API handle pre-auth, recurring payments, and similar scenarios">
There is an open issue about whether the API should handle occasions when a site wants to request a payment
method but not actually make a charge immediately. These may include identification validation, pre-auth
Expand Down Expand Up @@ -408,7 +414,7 @@ <h2>PaymentRequest constructor</h2>
Set the value of the <a><code>shippingOption</code></a> attribute on <em>request</em> to <em>null</em>.
</li>
<li>
If <code>details</code> contains a <code>shippingOptions</code> sequence with a
If <code>details</code> contains a <code>shippingOptions</code> sequence with a
length of 1, then set <a><code>shippingOption</code></a> to the <code>id</code> of
the only <a><code>ShippingOption</code></a> in the sequence.
</li>
Expand Down Expand Up @@ -938,7 +944,7 @@ <h2>PaymentRequestUpdateEvent</h2>
</li>
<li>Let <em>newOption</em> be <em>null</em>.</li>
<li>
If <code>details</code> contains a <code>shippingOptions</code> sequence with a
If <code>details</code> contains a <code>shippingOptions</code> sequence with a
length of 1, then set <em>newOption</em> to the <code>id</code> of the only
<a><code>ShippingOption</code></a> in the sequence.
</li>
Expand Down Expand Up @@ -1013,7 +1019,7 @@ <h2>PaymentRequest updated algorithm</h2>
The <dfn>PaymentRequest updated algorithm</dfn> is run by other algorithms above to fire
an event to indicate that a user has made a change to a <a><code>PaymentRequest</code></a>
called <em>request</em> with an event name of <em>name</em>.</p>
<p>It MUST run the following steps:</p>
<p>It MUST run the following steps:</p>
<ol>
<li>
If the <em>request</em>@[[\updating]] is <em>true</em>, then terminate
Expand Down