public-webpayments-specs@w3.org from December 2016 by author

adamroach

• Re: [w3c/webpayments-method-identifiers] How should we address payment method manifest files? (#19) (Thursday, 15 December)
• [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)

Ade Bateman

• Re: [w3c/webpayments-methods-card] Update spec to use 4-digit expirations (#22) (Tuesday, 20 December)
• Re: [w3c/browser-payment-api] Straighten out the payment method data flow (#382) (Friday, 16 December)
• Re: [w3c/browser-payment-api] Add canMakePayment() method (#380) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Straighten out the payment method data flow (#382) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) (Friday, 9 December)
• Re: [w3c/browser-payment-api] Use current settings object. (#366) (Friday, 9 December)
• [w3c/browser-payment-api] Use current settings object. (#366) (Friday, 9 December)
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) (Friday, 9 December)
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) (Thursday, 8 December)
• Re: [w3c/browser-payment-api] "allowed to use" check is incorrect (#363) (Thursday, 8 December)
• Re: [w3c/browser-payment-api] Update allowed to use check. (#364) (Thursday, 8 December)
• [w3c/browser-payment-api] Update allowed to use check. (#364) (Thursday, 8 December)
• Re: [w3c/browser-payment-api] editorial: clarify examples (#329) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] Reference W3C HTML for allowpaymentrequest definition (#359) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] The origin restrictions in the PaymentRequest are not nearly strong enough (#332) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] Browsing contexts don't have an "origin" (#324) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Monday, 5 December)

Adrian Hope-Bailie

• Re: [w3c/browser-payment-api] How are digital signatures supported for Payment Requests? (#291) (Thursday, 22 December)
• Re: [w3c/webpayments-method-identifiers] How should we address payment method manifest files? (#19) (Monday, 19 December)
• Re: [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) (Thursday, 15 December)
• Re: [w3c/webpayments-payment-apps-api] Edited specification to remove notions of open/proprietary (#70) (Friday, 2 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Friday, 2 December)
• Re: [w3c/browser-payment-api] The origin restrictions in the PaymentRequest are not nearly strong enough (#332) (Friday, 2 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] The origin restrictions in the PaymentRequest are not nearly strong enough (#332) (Thursday, 1 December)

Andre Lyver

• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Saturday, 10 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 8 December)

Anne van Kesteren

• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) (Friday, 9 December)

Boris Zbarsky

• Re: [w3c/browser-payment-api] Need to define the interaction of payment API with navigation and browsing context destruction (#360) (Tuesday, 20 December)
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] The shippingOptions field is used in more cases than the spec claims, as far as I can tell (#345) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] DOMStrings don't contain "characters" (#322) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] The "if d is resolved" section of updateWith needs to be more explicit about how it gets a PaymentDetails dictionary (#349) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) (Saturday, 10 December)
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) (Friday, 9 December)
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) (Friday, 9 December)
• Re: [w3c/browser-payment-api] Update allowed to use check. (#364) (2893862) (Friday, 9 December)
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) (Thursday, 8 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 7 December)
• [w3c/browser-payment-api] "allowed to use" check is incorrect (#363) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) (Wednesday, 7 December)
• [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) (Wednesday, 7 December)
• [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Tuesday, 6 December)
• [w3c/browser-payment-api] Need to define the interaction of payment API with navigation and browsing context destruction (#360) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentDetailsModifier doesn't seem to be used for anything (#346) (Monday, 5 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentDetailsModifier doesn't seem to be used for anything (#346) (Monday, 5 December)
• Re: [w3c/browser-payment-api] The origin restrictions in the PaymentRequest are not nearly strong enough (#332) (Friday, 2 December)
• Re: [w3c/browser-payment-api] PaymentDetails "total" member should be required (#320) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] The origin restrictions in the PaymentRequest are not nearly strong enough (#332) (Thursday, 1 December)

Dave Longley

• Re: [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Saturday, 10 December)
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Saturday, 10 December)
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Saturday, 10 December)
• [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Friday, 9 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Friday, 9 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)

Domenic Denicola

• [w3c/browser-payment-api] ReSpec error viewing the spec (#386) (Friday, 23 December)
• Re: [w3c/browser-payment-api] Serializer behavior (#385) (Friday, 23 December)
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) (Friday, 23 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Thursday, 22 December)
• Re: [w3c/browser-payment-api] Straighten out the payment method data flow (#382) (Friday, 16 December)
• Re: [w3c/browser-payment-api] Add canMakePayment() method (#380) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Straighten out the payment method data flow (#382) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) (Wednesday, 14 December)
• [w3c/browser-payment-api] Straighten out the payment method data flow (#382) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 14 December)
• Re: [w3c/webpayments-methods-card] Add validate payment method data algorithm (#21) (Wednesday, 14 December)
• Re: [w3c/webpayments-methods-card] Add validate payment method data algorithm (#21) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Validate payment method data (#381) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Validate payment method data (#381) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• [w3c/webpayments-methods-card] Add validate payment method data algorithm (#21) (Wednesday, 14 December)
• [w3c/browser-payment-api] Validate payment method data (#381) (Wednesday, 14 December)
• [w3c/browser-payment-api] Add canMakePayment() method (#380) (Wednesday, 14 December)
• [w3c/browser-payment-api] Editorial: introductory explanations of methods should be non-normative notes (#379) (Wednesday, 14 December)
• [w3c/browser-payment-api] Editorial: refer to methods with parentheses for clarity, and spell out their params in their definition (#378) (Wednesday, 14 December)
• [w3c/browser-payment-api] Editorial: don't capitalize RFC 2119 terms (#377) (Wednesday, 14 December)
• [w3c/browser-payment-api] Editorial: define and link to the different states (#376) (Wednesday, 14 December)
• [w3c/browser-payment-api] Editorial: use new language for DOMExceptions (#375) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The shippingOptions field is used in more cases than the spec claims, as far as I can tell (#345) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? (#337) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? (#337) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Why does PaymentRequest constructor throw on details.error (#302) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] PaymentDetails "total" member should be required (#320) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? (#337) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] The shippingOptions field is used in more cases than the spec claims, as far as I can tell (#345) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Minor typographical fixes (#368) (Tuesday, 13 December)
• [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) (Tuesday, 13 December)
• [w3c/browser-payment-api] PaymentRequest constructor validation ordering does not match Blink at all (#373) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] DOMStrings don't contain "characters" (#322) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] What is "the script calling the constructor"? (#323) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] updateWith will silently ignore data in hard-to-debug ways (#350) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] The "if d is resolved" section of updateWith needs to be more explicit about how it gets a PaymentDetails dictionary (#349) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] The "if d is resolved" section of updateWith needs to be more explicit about how it gets a PaymentDetails dictionary (#349) (Tuesday, 13 December)
• [w3c/browser-payment-api] Various fixes to updateWith (#372) (Tuesday, 13 December)
• [w3c/browser-payment-api] waitForUpdate is not defined (#371) (Tuesday, 13 December)
• [w3c/browser-payment-api] Switch internal slot notation to ., not @ (#370) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Setting internal slots of objects from asynchronous steps is not OK (#339) (Tuesday, 13 December)
• [w3c/browser-payment-api] In parallel (#369) (Tuesday, 13 December)
• [w3c/browser-payment-api] Minor typographical fixes (#368) (Tuesday, 13 December)

Ian Clelland

• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) (Thursday, 15 December)

ianbjacobs

• Re: [w3c/webpayments-payment-apps-api] Updated intro on display of apps and openWindow (#77) (Thursday, 15 December)
• [w3c/webpayments-payment-apps-api] (Deleted this edit by mistake before merged) (#78) (Thursday, 15 December)
• Re: [w3c/webpayments-payment-apps-api] Updated intro on display of apps and openWindow (#77) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] PaymentApp fails to abort payment flow (#384) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] What is the mechanism for limiting repeated calls to canMakePayments ? (#367) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] What is the mechanism for limiting repeated calls to canMakePayments ? (#367) (Thursday, 15 December)
• [w3c/webpayments-payment-apps-api] Updated intro on display of apps and openWindow (#77) (Wednesday, 14 December)
• Re: [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Monday, 12 December)
• Re: [w3c/webpayments-payment-apps-api] added link to issue 73 (#75) (Monday, 12 December)
• [w3c/webpayments-payment-apps-api] added link to issue 73 (#75) (Monday, 12 December)
• Re: [w3c/webpayments-payment-apps-api] Suggested apps (#74) (Monday, 12 December)
• Re: [w3c/browser-payment-api] Add canMakeActivePayment() function to PaymentRequest object. (#310) (Monday, 12 December)
• [w3c/browser-payment-api] What is the mechanism for limiting repeated calls to canMakePayments ? (#367) (Monday, 12 December)
• Re: [w3c/webpayments-method-identifiers] Resolve whether browsers need to police payment app claims of supported methods (#11) (Monday, 12 December)
• Re: [w3c/webpayments-method-identifiers] Should a payment method identifier that is a URL bind that payment method to a single payment app or origin? (#12) (Monday, 12 December)
• Re: [w3c/webpayments-method-identifiers] Schema.org PaymentMethod as namespace for short strings (#13) (Monday, 12 December)
• Re: [w3c/webpayments-method-identifiers] Should we define nesting/grouping semantics for payment method identifier matching? (#1) (Monday, 12 December)
• Re: [w3c/webpayments-method-identifiers] Should a payment method identifier (URL) resolve to a machine readable resource that describes it? (#3) (Monday, 12 December)
• Re: [w3c/webpayments-method-identifiers] Should a payment method identifier that is a URL bind that payment method to a single payment app or origin? (#12) (Monday, 12 December)
• Re: [w3c/webpayments-method-identifiers] Resolve whether browsers need to police payment app claims of supported methods (#11) (Monday, 12 December)
• [w3c/webpayments-method-identifiers] How should we address payment method manifest files? (#19) (Monday, 12 December)
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Monday, 12 December)
• Re: [w3c/webpayments-method-identifiers] Should we define nesting/grouping semantics for payment method identifier matching? (#1) (Monday, 12 December)
• Re: [w3c/webpayments-method-identifiers] Should a payment method identifier (URL) resolve to a machine readable resource that describes it? (#3) (Monday, 12 December)
• Re: [w3c/webpayments-method-identifiers] Schema.org PaymentMethod as namespace for short strings (#13) (Monday, 12 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 8 December)
• Re: [w3c/webpayments-payment-apps-api] Pass along a Transaction ID (#47) (Tuesday, 6 December)
• Re: [w3c/webpayments-payment-apps-api] Pass along a Transaction ID (#47) (Tuesday, 6 December)
• Re: [w3c/webpayments-payment-apps-api] Should payment instrument details be included at registration? (#12) (Tuesday, 6 December)
• Re: [w3c/webpayments-payment-apps-api] Should payment instrument details be included at registration? (#12) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Monday, 5 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentDetailsModifier doesn't seem to be used for anything (#346) (Monday, 5 December)
• Re: [w3c/webpayments-payment-apps-api] Edited specification to remove notions of open/proprietary (#70) (Friday, 2 December)
• Re: [w3c/webpayments-payment-apps-api] Edited specification to remove notions of open/proprietary (#70) (Thursday, 1 December)
• Re: [w3c/webpayments-payment-apps-api] Should payment apps implement payment method-specific filters? (#63) (Thursday, 1 December)
• Re: [w3c/webpayments-payment-apps-api] Edited specification to remove notions of open/proprietary (#70) (Thursday, 1 December)
• [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Thursday, 1 December)

Jeff Burdges

• Re: [w3c/browser-payment-api] Add canMakePayment() method (#380) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 8 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Monday, 5 December)

littledan

• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 7 December)

Mahesh Kulkarni

• [w3c/browser-payment-api] PaymentApp fails to abort payment flow (#384) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)

Manu Sporny

• Re: [w3c/browser-payment-api] How are digital signatures supported for Payment Requests? (#291) (Thursday, 15 December)

Marcos Cáceres

• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Friday, 23 December)
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) (Friday, 23 December)
• Re: [w3c/browser-payment-api] ReSpec error viewing the spec (#386) (Friday, 23 December)
• Re: [w3c/browser-payment-api] ReSpec error viewing the spec (#386) (Friday, 23 December)
• Re: [w3c/browser-payment-api] ReSpec error viewing the spec (#386) (Friday, 23 December)
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) (Friday, 23 December)
• Re: [w3c/browser-payment-api] Serializer behavior (#385) (Tuesday, 20 December)
• Re: [w3c/webpayments-method-identifiers] Support for PMI's with schemes other than https? (#17) (Tuesday, 20 December)
• Re: [w3c/webpayments-method-identifiers] Support for PMI's with schemes other than https? (#17) (Tuesday, 20 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Switch internal slot notation to ., not @ (#370) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Please define your internal slot notation before using it (#336) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Switch internal slot notation to ., not @ (#370) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Minor typographical fixes (#368) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] In parallel (#369) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] "asynchronously perform the remaining steps" is not defined (#341) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Minor typographical fixes (#368) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Minor typographical fixes (#368) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Minor typographical fixes (#368) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] "store" value in [[internalSlot]] (#353) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Friday, 9 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Friday, 9 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Thursday, 8 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Thursday, 8 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Friday, 2 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Friday, 2 December)
• Re: [w3c/browser-payment-api] editorial: clarify examples (#329) (Friday, 2 December)
• Re: [w3c/browser-payment-api] editorial: clarify examples (#329) (Friday, 2 December)
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Friday, 2 December)
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Friday, 2 December)
• [w3c/browser-payment-api] fix: don't validate display items (closes #344) (#357) (Friday, 2 December)
• Re: [w3c/browser-payment-api] What does it mean for a user agent to validate displayItems? (#344) (Friday, 2 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Friday, 2 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Friday, 2 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Friday, 2 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Friday, 2 December)
• Re: [w3c/browser-payment-api] PaymentOptions seems overly verbose/overlaps with HTML (#326) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] How are currency systems expected to be implemented in practice? (#343) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)

mattdevaney

• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Friday, 9 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Monday, 5 December)

Michael[tm] Smith

• Re: [w3c/browser-payment-api] What is "the script calling the constructor"? (#323) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] What is "the script calling the constructor"? (#323) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] "allowed to use" check is incorrect (#363) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] "allowed to use" check is incorrect (#363) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] Explicitly state any cases where an iframe with an allowpaymentrequest attribute is not allowed to make payment requests (#358) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] Explicitly state any cases where an iframe with an allowpaymentrequest attribute is not allowed to make payment requests (#358) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311) (Monday, 5 December)
• [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• [w3c/browser-payment-api] Explicitly state any cases where an iframe with an allowpaymentrequest is not allowed to make payment requests (#358) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311) (Friday, 2 December)
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) (Friday, 2 December)

Nick Shearer

• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Saturday, 10 December)
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Saturday, 10 December)
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Friday, 9 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentDetailsModifier doesn't seem to be used for anything (#346) (Sunday, 4 December)

ojan

• Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311) (Thursday, 1 December)

Philip Jägenstedt

• Re: [w3c/browser-payment-api] PaymentDetails "total" member should be required (#320) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] PaymentDetails "total" member should be required (#320) (Thursday, 1 December)

Rick Byers

• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Thursday, 22 December)

Rouslan Solomakhin

• Re: [w3c/browser-payment-api] Adding dialog close event (#387) (Wednesday, 28 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Thursday, 22 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Thursday, 22 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Thursday, 22 December)
• Re: [w3c/browser-payment-api] Serializer behavior (#385) (Tuesday, 20 December)
• [w3c/browser-payment-api] Serializer behavior (#385) (Tuesday, 20 December)
• Re: [w3c/browser-payment-api] Need to define the interaction of payment API with navigation and browsing context destruction (#360) (Tuesday, 20 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] PaymentApp fails to abort payment flow (#384) (Thursday, 15 December)
• Re: [w3c/webpayments-method-identifiers] Support for PMI's with schemes other than https? (#17) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Add canMakePayment() method (#380) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 14 December)
• Re: [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) (Wednesday, 14 December)
• Re: [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Monday, 12 December)
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) (Monday, 12 December)
• Re: [w3c/webpayments-payment-apps-api] Suggested apps (#74) (Monday, 12 December)
• [w3c/webpayments-payment-apps-api] Need to specify behavior for Clients.openWindow (#73) (Monday, 12 December)
• [w3c/webpayments-payment-apps-api] Suggested apps (#74) (Monday, 12 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Friday, 9 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Thursday, 8 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Wednesday, 7 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Monday, 5 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentDetailsModifier doesn't seem to be used for anything (#346) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Friday, 2 December)
• Re: [w3c/webpayments-payment-apps-api] Should payment apps implement payment method-specific filters? (#63) (Thursday, 1 December)
• Re: [w3c/webpayments-payment-apps-api] Should payment apps implement payment method-specific filters? (#63) (Thursday, 1 December)
• Re: [w3c/webpayments-payment-apps-api] Should payment apps implement payment method-specific filters? (#63) (Thursday, 1 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Thursday, 1 December)

rvm4

• Re: [w3c/browser-payment-api] Adding dialog close event (#387) (Wednesday, 28 December)
• Re: [w3c/browser-payment-api] Adding dialog close event (#387) (Wednesday, 28 December)
• Re: [w3c/browser-payment-api] Adding dialog close event (#387) (Wednesday, 28 December)
• [w3c/browser-payment-api] Adding dialog close event (#387) (Wednesday, 28 December)
• Re: [w3c/browser-payment-api] Introduce paymenRequestID (#292) (Thursday, 22 December)
• Re: [w3c/browser-payment-api] Introduce paymenRequestID (#292) (Thursday, 22 December)
• Re: [w3c/browser-payment-api] Introduce paymenRequestID (#292) (Thursday, 22 December)
• Re: [w3c/browser-payment-api] Introduce paymenRequestID (#292) (Thursday, 22 December)
• Re: [w3c/browser-payment-api] editorial: PaymentRequest ctor, describe errors (closes #290) (#355) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] PaymentRequest constructor errors should be properly annotated (#290) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] enum PaymentComplete's "" (#308) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] normative(PaymentComplete): replace '' with 'unknown' (closes #308) (#312) (Thursday, 1 December)

Salvador de la Puente González

• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) (Thursday, 15 December)

Shane McCarron

• Re: [w3c/webpayments-method-identifiers] How should we address payment method manifest files? (#19) (Thursday, 15 December)

Simon Pieters

• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) (Wednesday, 28 December)
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) (Thursday, 15 December)
• [w3c/browser-payment-api] Invoke "allowed to use" always (#383) (Thursday, 15 December)
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) (Thursday, 8 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) (Monday, 5 December)

Tommy Thorsen

• Re: [w3c/webpayments-payment-apps-api] Need to specify behavior for Clients.openWindow (#73) (Tuesday, 27 December)

Zach Koch

• Re: [w3c/webpayments-methods-card] Update spec to use 4-digit expirations (#22) (Tuesday, 20 December)
• [w3c/webpayments-methods-card] Update spec to use 4-digit expirations (#22) (Tuesday, 20 December)
• Re: [w3c/webpayments-method-identifiers] How should we address payment method manifest files? (#19) (Friday, 16 December)
• Re: [w3c/browser-payment-api] Add canMakePayment() method (#380) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] What is the mechanism for limiting repeated calls to canMakePayments ? (#367) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Add canMakePayment() function to PaymentRequest object. (#310) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The target of a PaymentRequestUpdateEvent may not be a PaymentRequest object (#347) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The shippingOptions field is used in more cases than the spec claims, as far as I can tell (#345) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] The "if d is resolved" section of updateWith needs to be more explicit about how it gets a PaymentDetails dictionary (#349) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] It's probably a good idea to use https://www.w3.org/2001/tag/doc/promises-guide#shorthand-reacting in updateWith (#348) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) (Wednesday, 14 December)
• Re: [w3c/browser-payment-api] Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? (#337) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] The shippingOptions field is used in more cases than the spec claims, as far as I can tell (#345) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? (#337) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Tuesday, 13 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Friday, 9 December)
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) (Thursday, 8 December)
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) (Tuesday, 6 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] What does it mean for a user agent to validate displayItems? (#344) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] fix: don't validate display items (closes #344) (#357) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] fix: don't validate display items (closes #344) (#357) (Tuesday, 6 December)
• Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311) (Friday, 2 December)
• Re: [w3c/browser-payment-api] PaymentOptions seems overly verbose/overlaps with HTML (#326) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] How are currency systems expected to be implemented in practice? (#343) (Thursday, 1 December)
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] How are currency systems expected to be implemented in practice? (#343) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] What does it mean for a user agent to validate displayItems? (#344) (Thursday, 1 December)
• Re: [w3c/browser-payment-api] PaymentOptions seems overly verbose/overlaps with HTML (#326) (Thursday, 1 December)

Last message date: Wednesday, 28 December 2016 23:05:09 UTC