public-webapps-github@w3.org from November 2014 by date

Sunday, 30 November 2014

• Re: [ServiceWorker] Backpressure on fetch integrated with Streams (#452) Ben Kelly
• Re: [ServiceWorker] Backpressure on fetch integrated with Streams (#452) Domenic Denicola

Saturday, 29 November 2014

• Re: [ServiceWorker] Backpressure on fetch integrated with Streams (#452) Ben Kelly
• Re: [ServiceWorker] Backpressure on fetch integrated with Streams (#452) Ben Kelly
• Re: [streams] Should we "lock" readable streams while piping? (#241) Domenic Denicola
• Re: [ServiceWorker] Backpressure on fetch integrated with Streams (#452) Domenic Denicola

Friday, 28 November 2014

• [permissions] A "dismissed" state (#4) Marcos Caceres
• [permissions] Permission states (#3) Marcos Caceres
• [permissions] Redundant assertion (#2) Marcos Caceres
• Re: [ServiceWorker] Controlling documents (#475) Jungkee Song
• Re: [ServiceWorker] Controlling documents (#475) Jungkee Song
• Re: [ServiceWorker] ServiceWorkerGlobalScope and service worker (#485) Jungkee Song
• Re: [ServiceWorker] ServiceWorkerGlobalScope and service worker (#485) Jungkee Song
• Re: [ServiceWorker] Worker navigator.serviceWorker and serviceWorkerGlobal.registration (#562) Jungkee Song
• Re: [ServiceWorker] Worker navigator.serviceWorker and serviceWorkerGlobal.registration (#562) Jungkee Song
• Re: [ServiceWorker] Expose ServiceWorkerContainer to Worker; Define service worker client as an environment settings object; Adding registration as a global; Moving .update() onto the registration object (ed665ba) Jungkee Song
• Re: [ServiceWorker] Should skipWaiting() wait for an "in-progress request" to finish? (#569) Matt Falkenhagen
• Re: [ServiceWorker] Backpressure on fetch integrated with Streams (#452) Yutaka Hirano
• Re: [ServiceWorker] Backpressure on fetch integrated with Streams (#452) Ben Kelly
• Re: [streams] Should we "lock" readable streams while piping? (#241) Yutaka Hirano
• Re: [streams] Should we "lock" readable streams while piping? (#241) Yutaka Hirano
• Re: [ServiceWorker] Changing ServiceWorkerClient.hidden to visibilityState (#498) Jungkee Song
• Re: [ServiceWorker] Changing ServiceWorkerClient.hidden to visibilityState (#498) Kenji Baheux

Thursday, 27 November 2014

• Re: [manifest] Unknown display value should produce a developer warning (#283) Marcos Caceres
• Re: [manifest] Unknown display value should produce a developer warning (#283) Marcos Caceres
• Re: [manifest] Manifest icon's 'type' should be a valid IMAGE mime type, not a valid mime type (#287) Marcos Caceres
• Re: [manifest] Manifest icon's 'type' should be a valid IMAGE mime type, not a valid mime type (#287) Marcos Caceres
• Re: [manifest] Manifest icon's 'type' should be a valid IMAGE mime type, not a valid mime type (#287) Kenneth Rohde Christiansen
• Re: [permissions] Add link to Moz's bugzilla bug to track this (#1) Marcos Caceres
• [permissions] Add link to Moz's bugzilla bug to track this (#1) Marcos Caceres
• Re: [ServiceWorker] Backpressure on fetch integrated with Streams (#452) Domenic Denicola
• [manifest] Manifest icon's 'type' should be a valid IMAGE mime type, not a valid mime type (#287) Mounir Lamouri
• Re: [manifest] Issue a developer warning if density is present but invalid. (#285) Kenneth Rohde Christiansen
• Re: [manifest] Issue a developer warning if the display mode is not a known value. (#286) Kenneth Rohde Christiansen
• Re: [ServiceWorker] Merge service worker client into "environment settings object" (#516) Anne van Kesteren
• Re: [ServiceWorker] Merge service worker client into "environment settings object" (#516) Jungkee Song
• Re: [ServiceWorker] Merge service worker client into "environment settings object" (#516) Jungkee Song
• [manifest] Issue a developer warning if the display mode is not a known value. (#286) Mounir Lamouri
• Re: [manifest] Issue a developer warning if density is present but invalid. (#285) Mounir Lamouri
• [manifest] Issue a developer warning if density is present but invalid. (#285) Mounir Lamouri
• Re: [manifest] Explicitely use https for respec link. (#284) Mounir Lamouri
• Re: [manifest] Unknown display value should produce a developer warning (#283) Kenneth Rohde Christiansen
• [manifest] Explicitely use https for respec link. (#284) Mounir Lamouri
• [manifest] Unknown display value should produce a developer warning (#283) Mounir Lamouri
• Re: [ServiceWorker] Merge service worker client into "environment settings object" (#516) Anne van Kesteren
• Re: [ServiceWorker] Backpressure on fetch integrated with Streams (#452) Anne van Kesteren
• [manifest] Icon density parsing should have a developer warning (#282) Mounir Lamouri
• Re: [ServiceWorker] Merge service worker client into "environment settings object" (#516) Jungkee Song
• Re: [ServiceWorker] Should skipWaiting() wait for an "in-progress request" to finish? (#569) Jungkee Song
• Re: [ServiceWorker] Backpressure on fetch integrated with Streams (#452) Takeshi Yoshino
• Re: [ServiceWorker] Merge service worker client into "environment settings object" (#516) Anne van Kesteren
• Re: [ServiceWorker] Should skipWaiting() wait for an "in-progress request" to finish? (#569) Matt Falkenhagen
• Re: [ServiceWorker] Should skipWaiting() wait for an "in-progress request" to finish? (#569) Matt Falkenhagen
• Re: [ServiceWorker] Should skipWaiting() wait for an "in-progress request" to finish? (#569) Jungkee Song
• Re: [ServiceWorker] Changing ServiceWorkerClient.hidden to visibilityState (#498) Jungkee Song
• [ServiceWorker] Should skipWaiting() wait for an "in-progress request" to finish? (#569) Matt Falkenhagen
• Re: [ServiceWorker] Merge service worker client into "environment settings object" (#516) Jungkee Song

Wednesday, 26 November 2014

• Re: [streams] Should we "lock" readable streams while piping? (#241) Domenic Denicola
• Re: [streams] Should we "lock" readable streams while piping? (#241) Domenic Denicola
• Re: [manifest] Expose the display mode in Javascript (#273) Mounir Lamouri
• [streams] Make .ready fulfill-only (#248) Domenic Denicola
• Re: [webidl] Grammar issues (#29) rainerschuster
• [webidl] Update index.xml (#32) rainerschuster
• [webidl] Update index.xml (#31) rainerschuster
• [webidl] Update index.xml (#30) rainerschuster
• Re: [manifest] Expose the display mode in Javascript (#273) Matthew Gaunt
• Re: [ServiceWorker] Make it clear that Cache and caches are to be available on page (#297) Ben Kelly
• Re: [ServiceWorker] Allowing multiple scopes (& should scopes be primary key?) (#566) Jake Archibald
• Re: [manifest] Cookies and data collection policies (#281) Craig Francis
• Re: [streams] Remove special handling for empty queue case in SyncWritableStreamStateW... (#247) Domenic Denicola
• Re: [streams] Remove special handling for empty queue case in SyncWritableStreamStateW... (#247) Domenic Denicola
• Re: [webidl] Grammar issues (#29) Marcos Caceres
• Re: [manifest] Cookies and data collection policies (#281) Marcos Caceres
• [manifest] Cookies and data collection policies (#281) Craig Francis
• [webidl] Grammar issues (#29) rainerschuster
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Michael van Ouwerkerk
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Michael van Ouwerkerk
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) John Mellor
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) John Mellor
• Re: [ServiceWorker] Batch Cache Operations does not use QueryCache correctly after #545 (#565) Ben Kelly
• Re: [ServiceWorker] Batch Cache Operations does not use QueryCache correctly after #545 (#565) Ben Kelly
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) John Mellor
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) John Mellor
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) John Mellor
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) John Mellor
• Re: [ServiceWorker] Merge service worker client into "environment settings object" (#516) Anne van Kesteren
• Re: [ServiceWorker] Changing ServiceWorkerClient.hidden to visibilityState (#498) Kunihiko Sakamoto
• Re: [streams] Make initial state of writable stream consult the strategy (06a0302) Takeshi Yoshino
• [streams] Remove special handling for empty queue case in SyncWritableStreamStateW... (#247) Takeshi Yoshino
• Re: [ServiceWorker] Spec'ing the "secure origin" restriction (#385) Jungkee Song
• Re: [ServiceWorker] Spec'ing the "secure origin" restriction (#385) Jungkee Song
• Re: [ServiceWorker] Merge service worker client into "environment settings object" (#516) Jungkee Song
• Re: [streams] Make .ready fulfill-only? (#245) Takeshi Yoshino
• Re: [streams] Make .ready fulfill-only? (#245) Domenic Denicola
• Re: [streams] Should we "lock" readable streams while piping? (#241) Yutaka Hirano
• Re: [ServiceWorker] IDL: Define Promise type for ServiceWorkerClient's ready attribute (#563) Jungkee Song
• Re: [ServiceWorker] IDL: Define Promise type for ServiceWorkerClient's ready attribute (#563) Jungkee Song
• Re: [ServiceWorker] Batch Cache Operations does not use QueryCache correctly after #545 (#565) Jungkee Song
• Re: [ServiceWorker] FetchEvent.respondWith() should check the used flag of the response (#567) Jungkee Song
• Re: [streams] Make .ready fulfill-only? (#245) Takeshi Yoshino
• Re: [ServiceWorker] Multi-author sites (#468) Kenji Baheux
• Re: [streams] Allow filing an issue from the spec directly (#222) Domenic Denicola

Tuesday, 25 November 2014

• Re: [ServiceWorker] 304 handling for fetch() (#412) Mark Nottingham
• Re: [dom] Link Element.setAttributeNodeNS() to the correct definition (#13) Philip Jägenstedt
• Re: [streams] Initial state of WritableStream (#242) Domenic Denicola
• Re: [streams] Initial state of WritableStream (#242) Domenic Denicola
• Re: [push-api] Add and Encryption Key array to the PushRegistration interface (#89) Martin Thomson
• Re: [push-api] Add and Encryption Key array to the PushRegistration interface (#89) Martin Thomson
• Re: [streams] Should we "lock" readable streams while piping? (#241) Domenic Denicola
• Re: [streams] Should we "lock" readable streams while piping? (#241) Domenic Denicola
• Re: [streams] Should we "lock" readable streams while piping? (#241) Mikeal Rogers
• Re: [streams] Should we "lock" readable streams while piping? (#241) Domenic Denicola
• Re: [streams] Should we "lock" readable streams while piping? (#241) Domenic Denicola
• Re: [ServiceWorker] 304 handling for fetch() (#412) Honza Bambas
• Re: [ServiceWorker] 304 handling for fetch() (#412) Anne van Kesteren
• Re: [streams] Rename .wait() to .ready step 2 (#246) Domenic Denicola
• Re: [streams] Rename .wait() to .ready step 2 (#246) Domenic Denicola
• Re: [ServiceWorker] 304 handling for fetch() (#412) Honza Bambas
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Michael van Ouwerkerk
• Re: [ServiceWorker] What should happen when we call response.text() and response.clone()? (#568) Anne van Kesteren
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Michael van Ouwerkerk
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Michael van Ouwerkerk
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Michael van Ouwerkerk
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Michael van Ouwerkerk
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Michael van Ouwerkerk
• Re: [ServiceWorker] What should happen when we call response.text() and response.clone()? (#568) Ben Kelly
• Re: [streams] Should we "lock" readable streams while piping? (#241) Yutaka Hirano
• Re: [ServiceWorker] What should happen when we call response.text() and response.clone()? (#568) Anne van Kesteren
• [ServiceWorker] What should happen when we call response.text() and response.clone()? (#568) Tsuyoshi Horo
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Anne van Kesteren
• Re: [ServiceWorker] Spec'ing the "secure origin" restriction (#385) Mike West
• Re: [manifest] HTTP-based solution for loading manifests (#98) Mark Nottingham
• Re: [ServiceWorker] 304 handling for fetch() (#412) Mark Nottingham
• [streams] Rename .wait() to .ready step 2 (#246) Takeshi Yoshino
• Re: [streams] Rename .wait() to .ready (6eb872b) Takeshi Yoshino
• [ServiceWorker] FetchEvent.respondWith() should check the used flag of the response (#567) Tsuyoshi Horo

Monday, 24 November 2014

• Re: [streams] Should we "lock" readable streams while piping? (#241) Domenic Denicola
• [streams] Make .ready fulfill-only? (#245) Domenic Denicola
• Re: [streams] Move from .wait() to .ready (#243) Domenic Denicola
• Re: [streams] Move from .wait() to .ready (#243) Domenic Denicola
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) John Mellor
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) John Mellor
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) John Mellor
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Peter Beverloo
• Re: [push-api] Make PushEvent's data payload binary instead of just a string (#88) Peter Beverloo
• Re: [push-api] Add and Encryption Key array to the PushRegistration interface (#89) ShijunS
• Re: [webidl] Make the DOMException constructor accept a name (#22) Domenic Denicola
• Re: [manifest] HTTP-based solution for loading manifests (#98) Marcos Caceres
• Re: [manifest] HTTP-based solution for loading manifests (#98) Marcos Caceres
• Re: [manifest] Capability to check already installed web app (#280) Marcos Caceres
• Re: [manifest] Capability to check already installed web app (#280) Marcos Caceres
• Re: [manifest] Capability to check already installed web app (#280) Marcos Caceres
• Re: [ServiceWorker] 304 handling for fetch() (#412) Anne van Kesteren

Last message date: Sunday, 30 November 2014 14:41:19 UTC