diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index d5160f90..615a79c8 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -89,7 +89,7 @@ Web Platform Incubator Community Group.
- +Buying things on the @@ -133,50 +133,50 @@
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.
-- This specification defines one class of products: -
-- A user agent MUST behave as described in this specification +
+ This specification defines one class of products: +
++ A user agent MUST behave as described in this specification in order to be considered conformant. In this specification, user agent means a Web browser or other interactive user agent as defined in [[!HTML5]]. -
-- 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. -
-- A conforming Payment Request API user agent MUST also be a - conforming implementation of the IDL fragments - of this specification, as described in the - “Web IDL” specification. [[!WEBIDL]]
- - ++ 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. +
++ A conforming Payment Request API user agent MUST also be a + conforming implementation of the IDL fragments + of this specification, as described in the + “Web IDL” specification. [[!WEBIDL]] +
+ +- This specification relies on several other underlying specifications. -
-+ This specification relies on several other underlying specifications. +
+Event
type and the terms fire an event, dispatch flag,
stop propagation flag, and stop immediate propagation flag are defined by [[!DOM4]].
@@ -249,7 +249,7 @@ The following example shows how to construct a PaymentRequest
and begin the
+
The following example shows how to construct a PaymentRequest
and begin the
user interaction:
@@ -341,6 +341,12 @@PaymentRequest constructor
currently described in the specification. ++ 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. ++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 @@ -408,7 +414,7 @@PaymentRequest constructor
Set the value of theshippingOption
attribute on request to null.- - If
@@ -938,7 +944,7 @@details
contains ashippingOptions
sequence with a + Ifdetails
contains ashippingOptions
sequence with a length of 1, then setshippingOption
to theid
of the onlyShippingOption
in the sequence.PaymentRequestUpdateEvent
- Let newOption be null.
- - If
@@ -1013,7 +1019,7 @@details
contains ashippingOptions
sequence with a + Ifdetails
contains ashippingOptions
sequence with a length of 1, then set newOption to theid
of the onlyShippingOption
in the sequence.PaymentRequest updated algorithm
The PaymentRequest updated algorithm is run by other algorithms above to fire an event to indicate that a user has made a change to aPaymentRequest
called request with an event name of name. -It MUST run the following steps:
+It MUST run the following steps:
- If the request@[[\updating]] is true, then terminate