Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review
I am fine with adding it (as CSP), but like Marcos, it would be great to know the plans for IE and Safari regarding ServiceWorker. Would it be an option to immediately work on L2 in parallel with L1 being moved to LC? Kenneth On Sun, Feb 16, 2014 at 11:16 AM, Marcos Caceres mar...@marcosc.com wrote: On Sunday, February 16, 2014, Alex Russell slightly...@google.com wrote: On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres w...@marcosc.com wrote: tl;dr: I strongly agree (and data below shows) that installable web apps without offline capabilities are essentially useless. Things currently specified in the manifest are supposed to help make these apps less useless (as I said in the original email, they by no means give us the dream of installable web apps, just one little step closer) - even if we had SW tomorrow, we would still need orientation, display mode, start URL, etc. So yes, SW and manifest will converge... questions for us to decide on is when? And if appcache can see us through this transitional period to having SW support in browsers? I believe we can initially standardize a limited set of functionality, while we continue to wait for SW to come into fruition which could take another year or two. SW will becoming to chrome ASAP. We're actively implementing. Jonas or Nikhil can probably provide more Mozilla context. I'm also interested in the WebKit and Microsoft context. I just don't know who to ask there. Have their been any public signals of their level of interest in SW? My personal view is that isn't not a good user experience to offer the affordance if the resulting system can't be trusted. That is to say, if we plow on with V1 without a (required) offline story, I'm not sure what we've really won. Happy for this to go to LC, but wouldn't recommend that Chrome For Android implement. I think this is good feedback. I'm happy to add (or for you to add;)) SW support to the manifest format. At least from Moz perspective it's fine as we are doing SW already. Anyone object to adding SW support to V1 of the manifest spec? Anything else that should be prioritized for V1? On Saturday, February 15, 2014 at 1:37 AM, Alex Russell wrote: I further think that the marginal utility in bookmarking something to the homescreen (sorry, yes, I'm focusing on mobile first) is low if it doesn't have a Service Worker / Appcache associated. Although I've not published this research yet, this is strongly backed by evidence. Nearly all applications in the top 78,000 websites that opt. into being standalone applications via apple-mobile-web-app-capable do not, in fact, work as standalone applications. If anyone is interested to try this for themselves, here is the raw dataset listing all the sites [1] - you will need an iPhone to test them. The data set is from Oct. 2013, but should still be relevant. Just pick some at random and add to homescreen; it makes for depressing viewing. There are a few exceptions (listed below) - but those are the exceptions, not the rule. It's strictly second-class-citizen territory to have web bookmarks that routinely don't do anything meaningful when offline. Yes, but there are a number of factors that contribute to this: not just offline (e.g., flexbox support is still fairly limited, dev tools still suck, cross-browser is a nightmare, even how navigation works differs across UAs!, limited orientation-locking support, etc.). However, to your point the data we have shows that about 50 sites in the top 78K declare an appcache [2], while there are 1163 sites that declare apple-mobile-web-app-capable. So yeah, appcache, as we all know, is a bit of a failure. Some of the sites that declare it actually have it commented out... like they tried it and just gave up. Interestingly, only 10 sites in the dataset are both capable of running standalone AND declare offline: 1. forecast.io 2. timer-tab.com 3. capitalone.com 4. rachaelrayshow.com 5. delicious.com 6. forbesmiddleeast.com 7. shopfato.com.br 8. ptable.com 9 authenticjobs.com 10. swedenabroad.com So, yeah... 10 / 1163 = 0.0085... or, :_(. Anyway... do you think it's ok for us to just standardize the limited things in the manifest? We could have those at LC like in 2 weeks and then spin up V2 to have convergence with SW. Better still, the SW spec can just specify how it wants to work with manifests. [1] https://gist.github.com/marcoscaceres/7419589 [2] https://gist.github.com/marcoscaceres/9018819 -- Marcos Caceres -- Kenneth Rohde Christiansen Web Platform Architect, Intel Corporation. Phone +45 4294 9458 ﹆﹆﹆
[XHR2] anonymous same-origin requests (alter withCredentials)
There used to be an anon flag that allows users to make anonymous requests. 4 months ago, it was dropped [1] (lack of followers? [2], [3]) Why is withCredentials not supported for same-origin requests? Presumably because its default value is false, and changing such behavior would break backwards-compatibility? If so, I request to allow it to have three values: - null (default, semantics of current false for backwards-compatibility) - false (new meaning: do NOT add cookies) - true ( note that I interpret same origin request as CORS-free request, because Chrome extensions can make cross-origin requests without CORS when it specifies the host permissions in a manifest file. However, due to the lack of support for anonymous requests, there is an unsurmountable privacy issue (see [4]), which I want to fix ). Thoughts? -- https://robwu.nl [1]: https://github.com/whatwg/xhr/commit/7c4b8cb0 [2]: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-March/039104.html). [3]: http://crbug.com/113920 [4]: http://crbug.com/48118
[Bug 24610] What happens when unlockOrientation() is called but no orientation is locked?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24610 Mounir Lamouri mou...@lamouri.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Mounir Lamouri mou...@lamouri.fr --- The specification says: The unlockOrientation() method, when invoked, must disable the current lock applied on the screen with lockOrientation. There is obviously nothing to do if the screen orientation was not locked using lockOrientation(). Please reopen if you think this is not correct. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [XHR2] anonymous same-origin requests (alter withCredentials)
Why is withCredentials not supported for same-origin requests? Presumably because its default value is false, and changing such behavior would break backwards-compatibility? If so, I request to allow it to have three values: Hi Rob, I already suggested pretty much exactly this in http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0766.html and follow-up mails like http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0729.html - apparently, the consensus was that it was too late to redefine withCredentials at that point. Regrettably. Now, if it's a requirement or considered a very good idea for Chrome extension use cases perhaps you can push back against those arguments - a tri-state withCredentials would certainly be my favoured outcome if we can get the implementors onboard and avoid breaking existing content ;-) -Hallvord
WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On Feb 16, 2014, at 2:16 AM, Marcos Caceres mar...@marcosc.com wrote: On Sunday, February 16, 2014, Alex Russell slightly...@google.com wrote: On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres w...@marcosc.com wrote: tl;dr: I strongly agree (and data below shows) that installable web apps without offline capabilities are essentially useless. Things currently specified in the manifest are supposed to help make these apps less useless (as I said in the original email, they by no means give us the dream of installable web apps, just one little step closer) - even if we had SW tomorrow, we would still need orientation, display mode, start URL, etc. So yes, SW and manifest will converge... questions for us to decide on is when? And if appcache can see us through this transitional period to having SW support in browsers? I believe we can initially standardize a limited set of functionality, while we continue to wait for SW to come into fruition which could take another year or two. SW will becoming to chrome ASAP. We're actively implementing. Jonas or Nikhil can probably provide more Mozilla context. I'm also interested in the WebKit and Microsoft context. I just don't know who to ask there. Have their been any public signals of their level of interest in SW? In general I think it's a good idea and I bet many other WebKit folks do too. We haven't yet had a chance to review thoroughly but I expect we'll like the general principles. I personally would like to see it become an official draft of the Working Group if it isn't already (the Publication Status page implies not, but perhaps I have missed something). If it is being actively implemented, it would be great to publish it as a Working Draft also, so we can get the IPR disclosures out of the way. Regards, Maciej
[push-api] No clear mention of privacy implication of sending data through push service
Hi, Was just skimming through the Push API spec. I'm aware that no payload is sent with push message for privacy reasons (as push service is most certainly a third party), but that isn't mentioned in the spec. I suggest adding a non-normative note that: 1. describes the reasons of this architectural decision (the privacy concern), 2. describes a possible work-around (xhr request to App Server to get the data), 3. eventually mentions some of the benefits (e.g. payload can be always up to date even if notification is stale). Secondly, the very helpful sequence diagram contained in the spec could be amended like so (to hint at this work-around): ++ ++ ++ ++ | webapp | | user | | push | | app | || | agent | | server | | server | ++ ++ ++ ++ || | | |-register--| | | || | | | (user accepts) | | || | | ||-setup push service-| | || | | |---success-| | | || | | |--activate service with PushService attributes-| || | | || |--push notification-| || | per service API | || | | || (match to user agent) | || | | ||--push notification--| | || per service protocol | | || | | |(match to webapp) | | || | | |---system message--| | | || | | |--XHR GET Request---| || | | |---Payload--| || | | Best, --tobie
[Bug 24691] New: Allow shared Web workers to persist across page loads from same origin
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24691 Bug ID: 24691 Summary: Allow shared Web workers to persist across page loads from same origin Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P2 Component: Web Workers (editor: Ian Hickson) Assignee: i...@hixie.ch Reporter: alexander.goe...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org The problem: With classic, multi-page Web sites, processing of data and network events are limited in their lifetime by the lifetime of the single page. There is no persistence across pages on the same site. Example use case: A user on a Web site which has user profiles uploads a profile image. He cannot browse to another page before the image upload has been finished. At a first glance, shared Web workers seem to provide a solution, see e.g. comments at - http://stackoverflow.com/questions/10886910/how-to-maintain-a-websockets-connection-between-pages/10889098#10889098 - http://stackoverflow.com/questions/14583812/how-to-keep-pusher-client-objects-persistent-across-pages/14601415#14601415http://stackoverflow.com/questions/9336774/do-shared-web-workers-persist-across-a-single-page-reload-link-navigation According to the spec, with only a single browser tab, the unload/load must lead to the Web worker's closing flag being set to 'true'. In a sample current implementation (Chrome 34.0.1843.0), it is possible to produce cases where the shared Web worker persists - but these lie outside of normal use parameters. In any case, there can be no assurance for persistence. Proposed solution: When a browser determines that the page to load has the same origin as the present page which instantiated a shared Web worker, then it persists this Web worker. Persistence could be until a defined event has passed without the new page instantiating the shared Web worker. This could e.g. be the parsing of the document, without any inline script or synchronously loaded script having made the request. -- You are receiving this mail because: You are on the CC list for the bug.
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On Feb 17, 2014 8:02 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2014, at 2:16 AM, Marcos Caceres mar...@marcosc.com wrote: On Sunday, February 16, 2014, Alex Russell slightly...@google.com wrote: On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres w...@marcosc.com wrote: tl;dr: I strongly agree (and data below shows) that installable web apps without offline capabilities are essentially useless. Things currently specified in the manifest are supposed to help make these apps less useless (as I said in the original email, they by no means give us the dream of installable web apps, just one little step closer) - even if we had SW tomorrow, we would still need orientation, display mode, start URL, etc. So yes, SW and manifest will converge... questions for us to decide on is when? And if appcache can see us through this transitional period to having SW support in browsers? I believe we can initially standardize a limited set of functionality, while we continue to wait for SW to come into fruition which could take another year or two. SW will becoming to chrome ASAP. We're actively implementing. Jonas or Nikhil can probably provide more Mozilla context. I'm also interested in the WebKit and Microsoft context. I just don't know who to ask there. Have their been any public signals of their level of interest in SW? In general I think it's a good idea and I bet many other WebKit folks do too. We haven't yet had a chance to review thoroughly but I expect we'll like the general principles. I personally would like to see it become an official draft of the Working Group if it isn't already (the Publication Status page implies not, but perhaps I have missed something). If it is being actively implemented, it would be great to publish it as a Working Draft also, so we can get the IPR disclosures out of the way. Regards, Maciej Great to hear that. The standard track document is being drafted here. [1] It'll be nicer if WebKit folks have a chance to review the ongoing work [2] and join the iteration at this time. [1] http://rawgithub.com/slightlyoff/ServiceWorker/master/spec/service_worker/index.html [2] https://github.com/slightlyoff/ServiceWorker
[Bug 24692] New: Define 'default orientation'
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24692 Bug ID: 24692 Summary: Define 'default orientation' Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: ASSIGNED Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: mou...@lamouri.fr QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org, w...@marcosc.com Currently default orientation is mentioned in the unlockOrientation description but isn't defined properly. -- You are receiving this mail because: You are on the CC list for the bug.
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On 2/17/14 6:47 AM, ext Jungkee Song wrote: On Feb 17, 2014 8:02 PM, Maciej Stachowiak m...@apple.com mailto:m...@apple.com wrote: I personally would like to see it become an official draft of the Working Group if it isn't already Yes, me too. (the Publication Status page implies not, but perhaps I have missed something). (The data for the AppCache/ServiceWorkers row wasn't accurate, pending an update from the Editors. I just replaced that row with a single entry for Service Workers and included a link to the ED that Jungkee provided below.) If it is being actively implemented, it would be great to publish it as a Working Draft also, so we can get the IPR disclosures out of the way. Regards, Maciej Great to hear that. The standard track document is being drafted here. [1] It'll be nicer if WebKit folks have a chance to review the ongoing work [2] and join the iteration at this time. Jungkee, Alex - what needs to be done before Service Workers is ready for FPWD? The only process requirement for a FPWD is that the group record consensus to publish it. However, it's usually helpful if the FPWD is feature complete from a breadth perspective but there is no expectation the FPWD is complete from a depth perspective. As such, if there are missing features, it would be good to mention that in the ED and/or file related bugs. BTW, I noticed there is no Bugzilla component for Service Workers so I will ask Mike Smith to create one). -Thanks, AB [1] http://rawgithub.com/slightlyoff/ServiceWorker/master/spec/service_worker/index.html [2] https://github.com/slightlyoff/ServiceWorker
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On Monday, February 17, 2014 at 12:38 PM, Arthur Barstow wrote: BTW, I noticed there is no Bugzilla component for Service Workers so I will ask Mike Smith to create one). I think they bug tracker on GH is being used instead. It's already very active and it would be a shame to have to move to Bugzilla.
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On 2/17/14 8:03 AM, ext Marcos Caceres wrote: On Monday, February 17, 2014 at 12:38 PM, Arthur Barstow wrote: BTW, I noticed there is no Bugzilla component for Service Workers so I will ask Mike Smith to create one). I think they bug tracker on GH is being used instead. It's already very active and it would be a shame to have to move to Bugzilla. I don't have a strong preference (Bugzilla vs. GH Issues) but I do think only one should be used and supported. Note the ED includes the following: [[ Participate File bugs https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=blocked=14968short_desc=%5BCustom%5D%3A%20product=WebAppsWGcomponent=Service%20Workers(w3.org'sBugzilla https://www.w3.org/Bugs/Public/) ]] So I naturally assumed Bugzilla would be used (and if this isn't the case the above should be fixed/clarified). -Thanks, AB
[admin] Please register for WebApps 10-11 April 2014 f2f meeting; deadline March 28
Hi All, The registration page for the WebApps' 10-11 April f2f meeting in San Jose CA US is now open: https://www.w3.org/2002/09/wbs/42538/WebApps-April2004-f2f/ Please register for the meeting by March 28. The meeting page follows. Please feel free to directly add proposed topics or propose them on the list: https://www.w3.org/wiki/Webapps/April2014Meeting Thanks to Daniel Austin and eBay for hosting the meeting! -AB On 2/11/14 7:49 AM, ext Arthur Barstow wrote: Hi All - as mentioned last month, we are organizing a f2f meeting for this coming Spring and the dates are April 10-11 in San Jose CA US. WebApps' Thurs/Friday meeting will follow an April 8-9 meeting of the HTMLWG at the same location. If April 10-11 causes any major and non-resolvable issue, please speak up immediately. -Thanks, Art, Chaals, Yves and Cindy
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On Mon, Feb 17, 2014 at 10:26 PM, Arthur Barstow art.bars...@nokia.comwrote: On 2/17/14 8:03 AM, ext Marcos Caceres wrote: On Monday, February 17, 2014 at 12:38 PM, Arthur Barstow wrote: BTW, I noticed there is no Bugzilla component for Service Workers so I will ask Mike Smith to create one). I think they bug tracker on GH is being used instead. It's already very active and it would be a shame to have to move to Bugzilla. I don't have a strong preference (Bugzilla vs. GH Issues) but I do think only one should be used and supported. Note the ED includes the following: [[ Participate File bugs https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=; blocked=14968short_desc=%5BCustom%5D%3A%20product= WebAppsWGcomponent=Service%20Workers(w3.org'sBugzilla https://www.w3.org/Bugs/Public/) ]] So I naturally assumed Bugzilla would be used (and if this isn't the case the above should be fixed/clarified). The work has been done in the GH repo and all the actual players are actively collaborating there using the GH issues. I think we should keep using it unless otherwise determined by the contributors. I'll fix the above text to point to the GH issues. -Thanks, AB -- Jungkee Song
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On Mon, Feb 17, 2014 at 9:38 PM, Arthur Barstow art.bars...@nokia.comwrote: On 2/17/14 6:47 AM, ext Jungkee Song wrote: On Feb 17, 2014 8:02 PM, Maciej Stachowiak m...@apple.com mailto: m...@apple.com wrote: I personally would like to see it become an official draft of the Working Group if it isn't already Yes, me too. (the Publication Status page implies not, but perhaps I have missed something). (The data for the AppCache/ServiceWorkers row wasn't accurate, pending an update from the Editors. I just replaced that row with a single entry for Service Workers and included a link to the ED that Jungkee provided below.) Thanks for the update. If it is being actively implemented, it would be great to publish it as a Working Draft also, so we can get the IPR disclosures out of the way. Regards, Maciej Great to hear that. The standard track document is being drafted here. [1] It'll be nicer if WebKit folks have a chance to review the ongoing work [2] and join the iteration at this time. Jungkee, Alex - what needs to be done before Service Workers is ready for FPWD? The only process requirement for a FPWD is that the group record consensus to publish it. However, it's usually helpful if the FPWD is feature complete from a breadth perspective but there is no expectation the FPWD is complete from a depth perspective. As such, if there are missing features, it would be good to mention that in the ED and/or file related bugs. I believe things are mostly addressed in a breadth perspective albeit quite a few issues are still being discussed and sorted out. We are currently drafting the ED and thought the F2F is sort of a right time to have a consensus for FPWD but think it'll be nicer if we can make it even before that to get a wider review as soon as possible. BTW, I noticed there is no Bugzilla component for Service Workers so I will ask Mike Smith to create one). -Thanks, AB [1] http://rawgithub.com/slightlyoff/ServiceWorker/ master/spec/service_worker/index.html [2] https://github.com/slightlyoff/ServiceWorker -- Jungkee Song
[Bug 24692] Define 'default orientation'
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24692 Mounir Lamouri mou...@lamouri.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Mounir Lamouri mou...@lamouri.fr --- https://dvcs.w3.org/hg/screen-orientation/rev/4d342638567d -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24614] Should the screen orientation be unlocked asynchronously
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24614 Mounir Lamouri mou...@lamouri.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Mounir Lamouri mou...@lamouri.fr --- https://dvcs.w3.org/hg/screen-orientation/rev/6a96b33b1c3a -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24612] Should Screen locking work only in full screen mode?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24612 Mounir Lamouri mou...@lamouri.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Mounir Lamouri mou...@lamouri.fr --- https://dvcs.w3.org/hg/screen-orientation/rev/2368be00b852 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24609] Can unlockOrientation() cause an orientationchange event to be fired?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24609 Mounir Lamouri mou...@lamouri.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Mounir Lamouri mou...@lamouri.fr --- https://dvcs.w3.org/hg/screen-orientation/rev/db6f46ecb3c6 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24608] What happens when calling lockOrientation() and already locked?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24608 Mounir Lamouri mou...@lamouri.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Mounir Lamouri mou...@lamouri.fr --- https://dvcs.w3.org/hg/screen-orientation/rev/c15263216fa2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24695] New: Allowed orientations should be an enum
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24695 Bug ID: 24695 Summary: Allowed orientations should be an enum Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: mou...@lamouri.fr QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org, w...@marcosc.com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24697] New: Use Promises for lockOrientation and unlockOrientation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24697 Bug ID: 24697 Summary: Use Promises for lockOrientation and unlockOrientation Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: mou...@lamouri.fr QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org, w...@marcosc.com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24698] New: Expose/lock to the screen orientation angle
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24698 Bug ID: 24698 Summary: Expose/lock to the screen orientation angle Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: mou...@lamouri.fr QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org, w...@marcosc.com The API exposes only the screen orientation name but not the actual angle compared to the device natural orientation. Knowing that can be useful for different reasons. For example, in combination with the device orientation events, it would make possible to write a reliable compass app. The details are not yet clear but we might want to expose 0/90/180/270 in something like screen.orientationAngle and maybe allow lockOrientation() to take those values too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24699] New: Reconsider -primary and -secondary orientations
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24699 Bug ID: 24699 Summary: Reconsider -primary and -secondary orientations Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: mou...@lamouri.fr QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org The relation between primary and secondary is currently based on the angle between both. We might want to change it to be less strict. -primary could be the preferred orientation of that type. For example, on a phone, landscape-primary would be the landscape orientation the user prefer (for a right-handed user, likely 90 degree anti-clockwise and 90 degree clockwise for a left-handed person). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24700] New: Should 'foo' be entirely equivalent to [ 'foo-primary', 'foo-secondary' ]
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24700 Bug ID: 24700 Summary: Should 'foo' be entirely equivalent to [ 'foo-primary', 'foo-secondary' ] Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: mou...@lamouri.fr QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org In other words, if the UA does not allow to lock to portrait-secondary, should a lock to 'portrait' fail or succeed? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24701] New: Apply Marcos' comments
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24701 Bug ID: 24701 Summary: Apply Marcos' comments Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: mou...@lamouri.fr QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Marcos sent me an email with some comments and changes. This bug is to keep track of that. This only contains editorial issues. The resulting diff will be made public here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24702] New: Apply Anne's comments sent in public-webapps
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24702 Bug ID: 24702 Summary: Apply Anne's comments sent in public-webapps Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: mou...@lamouri.fr QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org See: http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0055.html and the following thread. Some comments have already been applied. Some have not. This bug is to keep track of the thread. -- You are receiving this mail because: You are on the CC list for the bug.
PSA: new Screen Orientation WD
Hi, Arthur pointed out that the Screen Orientation API WD was not updated since a long time. However, the ED got a few updates so we would like to refresh the WD to have a better reflection of the current state of the implementation. You can find the current specification at: http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html Also, have a look at the commits in the mercurial repository if you want to know what happened since the last WD: https://dvcs.w3.org/hg/screen-orientation/shortlog Any change in the last 12 months would be new to this WD (20-25 changes). The target date for the new WD is the 20th of February. Thanks, -- Mounir
[Bug 24703] New: No easy way to lock to a set of accepted orientations if one UA doesnt support one of them
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24703 Bug ID: 24703 Summary: No easy way to lock to a set of accepted orientations if one UA doesnt support one of them Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: kenneth.christian...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Some apps and games might work fine in a set of orientation and thus try to lock to the accepted set or orientations. That might be [portrait-primary, portrait-secondary], unfortunate that lock will fail for UAs disabling portrait-secondary due to: For each orientation in the orientations list, run the following sub steps: If orientation isn't part of the allowed orientations, the steps must stop here and return false. Which means that the app will have to try to relock to any kind of subset of the decided allowed orientations. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents] Imperative API for Insertion Points
Hi Alex, You wrote: This doesn't seem like progress. I'd hope an imperative API would, instead, be used to explain how the existing system works and then propose layering that both accommodates the existing system and opens new areas for programmatic use. I think Ryosuke's content.add/remove are a better base layer than content select. In fact, content select is straightforwardly implementable / explainable on top of MO + content.add/remove, but there are several use cases that content.add/remove address that are difficult or impossible with content select (as described in Maciej's recent email on this thread). Ted
RE: [push-api] No clear mention of privacy implication of sending data through push service
Thanks for the comments, Tobie. I will provide an update draft proposal soon to address them. Note also that I'm preparing a proposal to actually include a message body, and other enhancements to the current API to broaden support among browsers. I should have a draft for review in the next couple of weeks. Given that such a body would be optional, it would be good in any event to include a flow as you propose. Thanks, Bryan Sullivan From: Tobie Langel [mailto:tobie.lan...@gmail.com] Sent: Monday, February 17, 2014 4:02 AM To: public-webapps@w3.org Subject: [push-api] No clear mention of privacy implication of sending data through push service Hi, Was just skimming through the Push API spec. I'm aware that no payload is sent with push message for privacy reasons (as push service is most certainly a third party), but that isn't mentioned in the spec. I suggest adding a non-normative note that: 1. describes the reasons of this architectural decision (the privacy concern), 2. describes a possible work-around (xhr request to App Server to get the data), 3. eventually mentions some of the benefits (e.g. payload can be always up to date even if notification is stale). Secondly, the very helpful sequence diagram contained in the spec could be amended like so (to hint at this work-around): ++ ++ ++ ++ | webapp | | user | | push | | app | || | agent | | server | | server | ++ ++ ++ ++ || | | |-register--| | | || | | | (user accepts) | | || | | ||-setup push service-| | || | | |---success-| | | || | | |--activate service with PushService attributes-| || | | || |--push notification-| || | per service API | || | | || (match to user agent) | || | | ||--push notification--| | || per service protocol | | || | | |(match to webapp) | | || | | |---system message--| | | || | | |--XHR GET Request---| || | | |---Payload--| || | | Best, --tobie
