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

Wednesday, 28 December 2016

• Re: [w3c/browser-payment-api] Adding dialog close event (#387) rvm4
• Re: [w3c/browser-payment-api] Adding dialog close event (#387) rvm4
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) Simon Pieters
• Re: [w3c/browser-payment-api] Adding dialog close event (#387) rvm4
• Re: [w3c/browser-payment-api] Adding dialog close event (#387) Rouslan Solomakhin
• [w3c/browser-payment-api] Adding dialog close event (#387) rvm4

Tuesday, 27 December 2016

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

Friday, 23 December 2016

• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Marcos Cáceres
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) Marcos Cáceres
• Re: [w3c/browser-payment-api] ReSpec error viewing the spec (#386) Marcos Cáceres
• Re: [w3c/browser-payment-api] ReSpec error viewing the spec (#386) Marcos Cáceres
• Re: [w3c/browser-payment-api] ReSpec error viewing the spec (#386) Marcos Cáceres
• [w3c/browser-payment-api] ReSpec error viewing the spec (#386) Domenic Denicola
• Re: [w3c/browser-payment-api] Serializer behavior (#385) Domenic Denicola
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) Domenic Denicola
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) Marcos Cáceres

Thursday, 22 December 2016

• Re: [w3c/browser-payment-api] Introduce paymenRequestID (#292) rvm4
• Re: [w3c/browser-payment-api] Introduce paymenRequestID (#292) rvm4
• Re: [w3c/browser-payment-api] Introduce paymenRequestID (#292) rvm4
• Re: [w3c/browser-payment-api] Introduce paymenRequestID (#292) rvm4
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Rick Byers
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Rouslan Solomakhin
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Rouslan Solomakhin
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Domenic Denicola
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] How are digital signatures supported for Payment Requests? (#291) Adrian Hope-Bailie

Tuesday, 20 December 2016

• Re: [w3c/webpayments-methods-card] Update spec to use 4-digit expirations (#22) Zach Koch
• Re: [w3c/webpayments-methods-card] Update spec to use 4-digit expirations (#22) Ade Bateman
• [w3c/webpayments-methods-card] Update spec to use 4-digit expirations (#22) Zach Koch
• Re: [w3c/browser-payment-api] Serializer behavior (#385) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Serializer behavior (#385) Marcos Cáceres
• [w3c/browser-payment-api] Serializer behavior (#385) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Need to define the interaction of payment API with navigation and browsing context destruction (#360) Boris Zbarsky
• Re: [w3c/browser-payment-api] Need to define the interaction of payment API with navigation and browsing context destruction (#360) Rouslan Solomakhin
• Re: [w3c/webpayments-method-identifiers] Support for PMI's with schemes other than https? (#17) Marcos Cáceres
• Re: [w3c/webpayments-method-identifiers] Support for PMI's with schemes other than https? (#17) Marcos Cáceres

Monday, 19 December 2016

• Re: [w3c/webpayments-method-identifiers] How should we address payment method manifest files? (#19) Adrian Hope-Bailie

Friday, 16 December 2016

• Re: [w3c/browser-payment-api] Straighten out the payment method data flow (#382) Domenic Denicola
• Re: [w3c/browser-payment-api] Straighten out the payment method data flow (#382) Ade Bateman
• Re: [w3c/webpayments-method-identifiers] How should we address payment method manifest files? (#19) Zach Koch

Thursday, 15 December 2016

• Re: [w3c/webpayments-payment-apps-api] Updated intro on display of apps and openWindow (#77) ianbjacobs
• [w3c/webpayments-payment-apps-api] (Deleted this edit by mistake before merged) (#78) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Updated intro on display of apps and openWindow (#77) ianbjacobs
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Add canMakePayment() method (#380) Domenic Denicola
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Salvador de la Puente González
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) Ian Clelland
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) Simon Pieters
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Salvador de la Puente González
• Re: [w3c/browser-payment-api] PaymentApp fails to abort payment flow (#384) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] PaymentApp fails to abort payment flow (#384) ianbjacobs
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) Boris Zbarsky
• Re: [w3c/webpayments-method-identifiers] How should we address payment method manifest files? (#19) Shane McCarron
• Re: [w3c/webpayments-method-identifiers] How should we address payment method manifest files? (#19) adamroach
• [w3c/browser-payment-api] PaymentApp fails to abort payment flow (#384) Mahesh Kulkarni
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) Boris Zbarsky
• Re: [w3c/webpayments-method-identifiers] Support for PMI's with schemes other than https? (#17) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] How are digital signatures supported for Payment Requests? (#291) Manu Sporny
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) Simon Pieters
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) Simon Pieters
• Re: [w3c/browser-payment-api] Invoke "allowed to use" always (#383) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) Simon Pieters
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) Simon Pieters
• [w3c/browser-payment-api] Invoke "allowed to use" always (#383) Simon Pieters
• Re: [w3c/browser-payment-api] Add canMakePayment() method (#380) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Salvador de la Puente González
• Re: [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) Dave Longley
• Re: [w3c/browser-payment-api] What is the mechanism for limiting repeated calls to canMakePayments ? (#367) ianbjacobs
• Re: [w3c/browser-payment-api] What is the mechanism for limiting repeated calls to canMakePayments ? (#367) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] Add canMakePayment() method (#380) Jeff Burdges

Wednesday, 14 December 2016

• Re: [w3c/browser-payment-api] Add canMakePayment() method (#380) Zach Koch
• Re: [w3c/browser-payment-api] What is the mechanism for limiting repeated calls to canMakePayments ? (#367) Zach Koch
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Zach Koch
• Re: [w3c/browser-payment-api] Add canMakePayment() function to PaymentRequest object. (#310) Zach Koch
• Re: [w3c/browser-payment-api] Add canMakePayment() method (#380) Ade Bateman
• Re: [w3c/browser-payment-api] Straighten out the payment method data flow (#382) Domenic Denicola
• Re: [w3c/browser-payment-api] The shippingOptions field is used in more cases than the spec claims, as far as I can tell (#345) Zach Koch
• Re: [w3c/browser-payment-api] The target of a PaymentRequestUpdateEvent may not be a PaymentRequest object (#347) Zach Koch
• 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) Zach Koch
• 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) Zach Koch
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) Zach Koch
• Re: [w3c/browser-payment-api] Straighten out the payment method data flow (#382) Ade Bateman
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) Domenic Denicola
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) Ade Bateman
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) Zach Koch
• [w3c/browser-payment-api] Straighten out the payment method data flow (#382) Domenic Denicola
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Domenic Denicola
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Domenic Denicola
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Domenic Denicola
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Dave Longley
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Dave Longley
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Domenic Denicola
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Domenic Denicola
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Dave Longley
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Dave Longley
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Domenic Denicola
• Re: [w3c/webpayments-methods-card] Add validate payment method data algorithm (#21) Domenic Denicola
• Re: [w3c/webpayments-methods-card] Add validate payment method data algorithm (#21) Domenic Denicola
• Re: [w3c/browser-payment-api] Validate payment method data (#381) Domenic Denicola
• Re: [w3c/browser-payment-api] Validate payment method data (#381) Domenic Denicola
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Domenic Denicola
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Domenic Denicola
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Domenic Denicola
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Dave Longley
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Domenic Denicola
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Domenic Denicola
• Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338) Domenic Denicola
• [w3c/webpayments-methods-card] Add validate payment method data algorithm (#21) Domenic Denicola
• [w3c/browser-payment-api] Validate payment method data (#381) Domenic Denicola
• [w3c/browser-payment-api] Add canMakePayment() method (#380) Domenic Denicola
• [w3c/browser-payment-api] Editorial: introductory explanations of methods should be non-normative notes (#379) Domenic Denicola
• [w3c/browser-payment-api] Editorial: refer to methods with parentheses for clarity, and spell out their params in their definition (#378) Domenic Denicola
• [w3c/browser-payment-api] Editorial: don't capitalize RFC 2119 terms (#377) Domenic Denicola
• [w3c/browser-payment-api] Editorial: define and link to the different states (#376) Domenic Denicola
• [w3c/browser-payment-api] Editorial: use new language for DOMExceptions (#375) Domenic Denicola
• [w3c/webpayments-payment-apps-api] Updated intro on display of apps and openWindow (#77) ianbjacobs
• Re: [w3c/browser-payment-api] The shippingOptions field is used in more cases than the spec claims, as far as I can tell (#345) Domenic Denicola
• Re: [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The shippingOptions field is used in more cases than the spec claims, as far as I can tell (#345) Boris Zbarsky
• [w3c/webpayments-payment-apps-api] Lambda functions for app matching (#76) adamroach

Tuesday, 13 December 2016

• Re: [w3c/browser-payment-api] Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? (#337) Domenic Denicola
• Re: [w3c/browser-payment-api] Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? (#337) Zach Koch
• Re: [w3c/browser-payment-api] Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? (#337) Domenic Denicola
• Re: [w3c/browser-payment-api] The shippingOptions field is used in more cases than the spec claims, as far as I can tell (#345) Zach Koch
• Re: [w3c/browser-payment-api] Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? (#337) Zach Koch
• Re: [w3c/browser-payment-api] PaymentDetails "total" member should be required (#320) Philip Jägenstedt
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Zach Koch
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Domenic Denicola
• Re: [w3c/browser-payment-api] Why does PaymentRequest constructor throw on details.error (#302) Domenic Denicola
• Re: [w3c/browser-payment-api] PaymentDetails "total" member should be required (#320) Domenic Denicola
• Re: [w3c/browser-payment-api] Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? (#337) Domenic Denicola
• Re: [w3c/browser-payment-api] The shippingOptions field is used in more cases than the spec claims, as far as I can tell (#345) Domenic Denicola
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Marcos Cáceres
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Marcos Cáceres
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) Marcos Cáceres
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) Marcos Cáceres
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) Domenic Denicola
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) Marcos Cáceres
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) Marcos Cáceres
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) Domenic Denicola
• Re: [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) Marcos Cáceres
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) Domenic Denicola
• Re: [w3c/browser-payment-api] Various fixes to updateWith (#372) Marcos Cáceres
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) Marcos Cáceres
• Re: [w3c/browser-payment-api] Switch internal slot notation to ., not @ (#370) Marcos Cáceres
• Re: [w3c/browser-payment-api] Please define your internal slot notation before using it (#336) Marcos Cáceres
• Re: [w3c/browser-payment-api] Switch internal slot notation to ., not @ (#370) Marcos Cáceres
• Re: [w3c/browser-payment-api] Minor typographical fixes (#368) Marcos Cáceres
• Re: [w3c/browser-payment-api] In parallel (#369) Marcos Cáceres
• Re: [w3c/browser-payment-api] Minor typographical fixes (#368) Domenic Denicola
• Re: [w3c/browser-payment-api] "asynchronously perform the remaining steps" is not defined (#341) Marcos Cáceres
• Re: [w3c/browser-payment-api] Minor typographical fixes (#368) Marcos Cáceres
• Re: [w3c/browser-payment-api] Minor typographical fixes (#368) Marcos Cáceres
• Re: [w3c/browser-payment-api] Minor typographical fixes (#368) Marcos Cáceres
• Re: [w3c/browser-payment-api] "store" value in [[internalSlot]] (#353) Marcos Cáceres
• [w3c/browser-payment-api] Various fixes to the PaymentRequest constructor (#374) Domenic Denicola
• [w3c/browser-payment-api] PaymentRequest constructor validation ordering does not match Blink at all (#373) Domenic Denicola
• Re: [w3c/browser-payment-api] What is "the script calling the constructor"? (#323) Michael[tm] Smith
• Re: [w3c/browser-payment-api] What is "the script calling the constructor"? (#323) Michael[tm] Smith
• Re: [w3c/browser-payment-api] DOMStrings don't contain "characters" (#322) Boris Zbarsky
• Re: [w3c/browser-payment-api] DOMStrings don't contain "characters" (#322) Domenic Denicola
• Re: [w3c/browser-payment-api] What is "the script calling the constructor"? (#323) Domenic Denicola
• Re: [w3c/browser-payment-api] updateWith will silently ignore data in hard-to-debug ways (#350) Domenic Denicola
• 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) Domenic Denicola
• 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) Boris Zbarsky
• 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) Domenic Denicola
• [w3c/browser-payment-api] Various fixes to updateWith (#372) Domenic Denicola
• [w3c/browser-payment-api] waitForUpdate is not defined (#371) Domenic Denicola
• [w3c/browser-payment-api] Switch internal slot notation to ., not @ (#370) Domenic Denicola
• Re: [w3c/browser-payment-api] Setting internal slots of objects from asynchronous steps is not OK (#339) Domenic Denicola
• [w3c/browser-payment-api] In parallel (#369) Domenic Denicola
• [w3c/browser-payment-api] Minor typographical fixes (#368) Domenic Denicola
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) ianbjacobs
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) Michael[tm] Smith

Monday, 12 December 2016

• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] added link to issue 73 (#75) ianbjacobs
• [w3c/webpayments-payment-apps-api] added link to issue 73 (#75) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Suggested apps (#74) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Suggested apps (#74) ianbjacobs
• Re: [w3c/browser-payment-api] Add canMakeActivePayment() function to PaymentRequest object. (#310) ianbjacobs
• [w3c/browser-payment-api] What is the mechanism for limiting repeated calls to canMakePayments ? (#367) ianbjacobs
• Re: [w3c/webpayments-method-identifiers] Resolve whether browsers need to police payment app claims of supported methods (#11) ianbjacobs
• 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) ianbjacobs
• Re: [w3c/webpayments-method-identifiers] Schema.org PaymentMethod as namespace for short strings (#13) ianbjacobs
• Re: [w3c/webpayments-method-identifiers] Should we define nesting/grouping semantics for payment method identifier matching? (#1) ianbjacobs
• Re: [w3c/webpayments-method-identifiers] Should a payment method identifier (URL) resolve to a machine readable resource that describes it? (#3) ianbjacobs
• 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) ianbjacobs
• Re: [w3c/webpayments-method-identifiers] Resolve whether browsers need to police payment app claims of supported methods (#11) ianbjacobs
• [w3c/webpayments-method-identifiers] How should we address payment method manifest files? (#19) ianbjacobs
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) ianbjacobs
• [w3c/webpayments-payment-apps-api] Need to specify behavior for Clients.openWindow (#73) Rouslan Solomakhin
• Re: [w3c/webpayments-method-identifiers] Should we define nesting/grouping semantics for payment method identifier matching? (#1) ianbjacobs
• Re: [w3c/webpayments-method-identifiers] Should a payment method identifier (URL) resolve to a machine readable resource that describes it? (#3) ianbjacobs
• Re: [w3c/webpayments-method-identifiers] Schema.org PaymentMethod as namespace for short strings (#13) ianbjacobs
• [w3c/webpayments-payment-apps-api] Suggested apps (#74) Rouslan Solomakhin

Saturday, 10 December 2016

• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Dave Longley
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Nick Shearer
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Andre Lyver
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Dave Longley
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Nick Shearer
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Dave Longley
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) Boris Zbarsky

Friday, 9 December 2016

• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) Ade Bateman
• Re: [w3c/browser-payment-api] Use current settings object. (#366) Ade Bateman
• [w3c/browser-payment-api] Use current settings object. (#366) Ade Bateman
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) Ade Bateman
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Zach Koch
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Marcos Cáceres
• Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Nick Shearer
• [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365) Dave Longley
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Dave Longley
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) mattdevaney
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) Boris Zbarsky
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) Anne van Kesteren
• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) Boris Zbarsky
• Re: [w3c/browser-payment-api] Update allowed to use check. (#364) (2893862) Boris Zbarsky
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Marcos Cáceres

Thursday, 8 December 2016

• Re: [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) Ade Bateman
• Re: [w3c/browser-payment-api] "allowed to use" check is incorrect (#363) Ade Bateman
• Re: [w3c/browser-payment-api] Update allowed to use check. (#364) Ade Bateman
• [w3c/browser-payment-api] Update allowed to use check. (#364) Ade Bateman
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) ianbjacobs
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Jeff Burdges
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) Boris Zbarsky
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Andre Lyver
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) Simon Pieters
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Marcos Cáceres
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Zach Koch
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Marcos Cáceres

Wednesday, 7 December 2016

• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) littledan
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Boris Zbarsky
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) Boris Zbarsky
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Boris Zbarsky
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) littledan
• Re: [w3c/browser-payment-api] "allowed to use" check is incorrect (#363) Michael[tm] Smith
• Re: [w3c/browser-payment-api] "allowed to use" check is incorrect (#363) Michael[tm] Smith
• [w3c/browser-payment-api] "allowed to use" check is incorrect (#363) Boris Zbarsky
• Re: [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) Boris Zbarsky
• [w3c/browser-payment-api] There is no concept of "called from" some browsing context (#362) Boris Zbarsky
• [w3c/browser-payment-api] Security hole in payment API when a constructor from a no longer active document is invoked (#361) Boris Zbarsky
• Re: [w3c/browser-payment-api] editorial: clarify examples (#329) Ade Bateman
• Re: [w3c/browser-payment-api] The origin restrictions in the PaymentRequest are not nearly strong enough (#332) Ade Bateman
• Re: [w3c/browser-payment-api] Browsing contexts don't have an "origin" (#324) Ade Bateman
• Re: [w3c/browser-payment-api] Reference W3C HTML for allowpaymentrequest definition (#359) Ade Bateman
• Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311) Ade Bateman

Tuesday, 6 December 2016

• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Boris Zbarsky
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Boris Zbarsky
• Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307) Zach Koch
• [w3c/browser-payment-api] Need to define the interaction of payment API with navigation and browsing context destruction (#360) Boris Zbarsky
• Re: [w3c/webpayments-payment-apps-api] Pass along a Transaction ID (#47) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Pass along a Transaction ID (#47) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Should payment instrument details be included at registration? (#12) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Should payment instrument details be included at registration? (#12) ianbjacobs
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Zach Koch
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Dave Longley
• Re: [w3c/browser-payment-api] What does it mean for a user agent to validate displayItems? (#344) Zach Koch
• Re: [w3c/browser-payment-api] fix: don't validate display items (closes #344) (#357) Zach Koch
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) mattdevaney
• Re: [w3c/browser-payment-api] fix: don't validate display items (closes #344) (#357) Zach Koch
• Re: [w3c/browser-payment-api] Explicitly state any cases where an iframe with an allowpaymentrequest attribute is not allowed to make payment requests (#358) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Explicitly state any cases where an iframe with an allowpaymentrequest attribute is not allowed to make payment requests (#358) Michael[tm] Smith

Monday, 5 December 2016

• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) ianbjacobs
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Ade Bateman
• Re: [w3c/browser-payment-api] The "data" member of PaymentDetailsModifier doesn't seem to be used for anything (#346) Boris Zbarsky
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Simon Pieters
• Re: [w3c/browser-payment-api] The "data" member of PaymentDetailsModifier doesn't seem to be used for anything (#346) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] The "data" member of PaymentDetailsModifier doesn't seem to be used for anything (#346) Boris Zbarsky
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Jeff Burdges
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Simon Pieters
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Simon Pieters
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) mattdevaney
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Simon Pieters
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Simon Pieters
• Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311) Michael[tm] Smith
• [w3c/browser-payment-api] Reference HTML for allowpaymentrequest definition (#359) Michael[tm] Smith
• [w3c/browser-payment-api] Explicitly state any cases where an iframe with an allowpaymentrequest is not allowed to make payment requests (#358) Michael[tm] Smith
• Re: [w3c/browser-payment-api] The "data" member of PaymentDetailsModifier doesn't seem to be used for anything (#346) ianbjacobs

Sunday, 4 December 2016

• Re: [w3c/browser-payment-api] The "data" member of PaymentDetailsModifier doesn't seem to be used for anything (#346) Nick Shearer

Friday, 2 December 2016

• Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311) Zach Koch
• Re: [w3c/webpayments-payment-apps-api] Edited specification to remove notions of open/proprietary (#70) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Edited specification to remove notions of open/proprietary (#70) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] The origin restrictions in the PaymentRequest are not nearly strong enough (#332) Boris Zbarsky
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Marcos Cáceres
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Marcos Cáceres
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] The origin restrictions in the PaymentRequest are not nearly strong enough (#332) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) Michael[tm] Smith
• Re: [w3c/browser-payment-api] editorial: clarify examples (#329) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: clarify examples (#329) Marcos Cáceres
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) Marcos Cáceres
• Re: [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) Marcos Cáceres
• [w3c/browser-payment-api] fix: don't validate display items (closes #344) (#357) Marcos Cáceres
• Re: [w3c/browser-payment-api] What does it mean for a user agent to validate displayItems? (#344) Marcos Cáceres
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Marcos Cáceres
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Marcos Cáceres
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Marcos Cáceres
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Marcos Cáceres

Thursday, 1 December 2016

• Re: [w3c/webpayments-payment-apps-api] Edited specification to remove notions of open/proprietary (#70) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Should payment apps implement payment method-specific filters? (#63) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Should payment apps implement payment method-specific filters? (#63) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Should payment apps implement payment method-specific filters? (#63) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Should payment apps implement payment method-specific filters? (#63) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Edited specification to remove notions of open/proprietary (#70) ianbjacobs
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Mahesh Kulkarni
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Dave Longley
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Dave Longley
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) adamroach
• Re: [w3c/browser-payment-api] PaymentDetails "total" member should be required (#320) Boris Zbarsky
• Re: [w3c/browser-payment-api] PaymentDetails "total" member should be required (#320) Philip Jägenstedt
• Re: [w3c/browser-payment-api] The origin restrictions in the PaymentRequest are not nearly strong enough (#332) Boris Zbarsky
• Re: [w3c/browser-payment-api] Making this API work with HTML Forms (#330) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] The origin restrictions in the PaymentRequest are not nearly strong enough (#332) Adrian Hope-Bailie
• [w3c/browser-payment-api] Change "SHOULD NEVER" to "MUST NOT" (#356) ianbjacobs
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Mahesh Kulkarni
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Mahesh Kulkarni
• Re: [w3c/browser-payment-api] PaymentOptions seems overly verbose/overlaps with HTML (#326) Zach Koch
• Re: [w3c/browser-payment-api] PaymentOptions seems overly verbose/overlaps with HTML (#326) Marcos Cáceres
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Mahesh Kulkarni
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Mahesh Kulkarni
• Re: [w3c/browser-payment-api] editorial: PaymentRequest ctor, describe errors (closes #290) (#355) rvm4
• Re: [w3c/browser-payment-api] PaymentRequest constructor errors should be properly annotated (#290) rvm4
• Re: [w3c/browser-payment-api] enum PaymentComplete's "" (#308) rvm4
• Re: [w3c/browser-payment-api] normative(PaymentComplete): replace '' with 'unknown' (closes #308) (#312) rvm4
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Zach Koch
• Re: [w3c/browser-payment-api] How are currency systems expected to be implemented in practice? (#343) Zach Koch
• Re: [w3c/browser-payment-api] How are currency systems expected to be implemented in practice? (#343) Marcos Cáceres
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Marcos Cáceres
• Re: [w3c/browser-payment-api] Detecting Payment Method Availability (#316) Mahesh Kulkarni
• Re: [w3c/webpayments-methods-card] Behavior when method-specific data is invalid (#20) Zach Koch
• Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311) ojan
• Re: [w3c/browser-payment-api] How are currency systems expected to be implemented in practice? (#343) Zach Koch
• Re: [w3c/browser-payment-api] What does it mean for a user agent to validate displayItems? (#344) Zach Koch
• Re: [w3c/browser-payment-api] PaymentOptions seems overly verbose/overlaps with HTML (#326) Zach Koch

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