Service worker popup (rich notification)
I wonder how much thought has been given to creating a popup (rich notification if you will) from a service worker. Combined with the push API this is what will enable e.g. Skype to cease being a native application. There's also some potential other uses for this. -- https://annevankesteren.nl/
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
Can we at least publish a new WD so people stop referring to the old TR/? -- Mounir On Wed, 1 Oct 2014, at 20:36, Arthur Barstow wrote: On 9/25/14 9:26 AM, Mounir Lamouri wrote: On Thu, 25 Sep 2014, at 21:52, Arthur Barstow wrote: On 9/25/14 6:36 AM, Anne van Kesteren wrote: It effectively comes down to the fact that the specification describes something, but Chrome implements it in another way per how I suggested it should work (using animation frame tasks). So this appears to be [Issue-40] and I think a one-line summary is the Editors consider this something that can be deferred to the next version and Anne considers it something that should be addressed before LC is published. Vis-a-vis this CfC, it seems the main options are: 1. Continue to work on this issue with the goal of getting broader consensus on the resolution 2. Publish the LC as is 3. Publish the LC as is but explicitly highlight this Issue and ask for Implementer/Developer feedback 4. Other options? Of course, I'd like to hear from others but I tend to think we should first try #1 (especially since Anne indicates the spec and at least one implementations are currently not aligned). Mounir, Marcos - would you please work with Anne on a mutually agreeable solution? Last I checked, animation frame task was still underdefined. This is what you can read in the WHATWG's fullscreen specification: Animation frame task is not really defined yet, including relative order within that task, see bug 26440. In my opinion, if the spec is changed to use animation frame task, it would not change much in the current state of things. Well, perhaps this would be true but the devil's in the details and the details do matter (see below). Also, I'm not entirely sure why Anne is so loudly complaining about that issue. The issue was not closed or waived but postponed until we can properly hooked to the thing. LC doesn't freeze the specification and we could definitely get this fixed before moving to CR. What I suggested to him on IRC and what I believe is the best approach to reconcile the two worlds (WHATWG live standards and W3C snapshots) is to take the current version of the spec to LC and update the ED to use animation frame task and mark it as a WIP feature. I opened issue 75 last week as a reminder to do that. Arthur, what do you think of that solution? We can certainly publish a LC with open issues (as was explicitly noted in the original CfC [1]). However, I do want to emphasize that if any substantive issue is filed after the LC is published, and the group agrees to address any such issue(s), the group must publish another LC before the spec can move to CR. I mention this because LC-LC loops are time consuming for the group, implementers and developers and thus should be avoided if possible. As such, it seems like pursuing #1 should be the next step. -Thanks, AB
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
Please please do. That's a useful thing to do regularly… 02.10.2014, 13:17, Mounir Lamouri mou...@lamouri.fr: Can we at least publish a new WD so people stop referring to the old TR/? -- Mounir On Wed, 1 Oct 2014, at 20:36, Arthur Barstow wrote: On 9/25/14 9:26 AM, Mounir Lamouri wrote: On Thu, 25 Sep 2014, at 21:52, Arthur Barstow wrote: On 9/25/14 6:36 AM, Anne van Kesteren wrote: It effectively comes down to the fact that the specification describes something, but Chrome implements it in another way per how I suggested it should work (using animation frame tasks). So this appears to be [Issue-40] and I think a one-line summary is the Editors consider this something that can be deferred to the next version and Anne considers it something that should be addressed before LC is published. Vis-a-vis this CfC, it seems the main options are: 1. Continue to work on this issue with the goal of getting broader consensus on the resolution 2. Publish the LC as is 3. Publish the LC as is but explicitly highlight this Issue and ask for Implementer/Developer feedback 4. Other options? Of course, I'd like to hear from others but I tend to think we should first try #1 (especially since Anne indicates the spec and at least one implementations are currently not aligned). Mounir, Marcos - would you please work with Anne on a mutually agreeable solution? Last I checked, animation frame task was still underdefined. This is what you can read in the WHATWG's fullscreen specification: Animation frame task is not really defined yet, including relative order within that task, see bug 26440. In my opinion, if the spec is changed to use animation frame task, it would not change much in the current state of things. Well, perhaps this would be true but the devil's in the details and the details do matter (see below). Also, I'm not entirely sure why Anne is so loudly complaining about that issue. The issue was not closed or waived but postponed until we can properly hooked to the thing. LC doesn't freeze the specification and we could definitely get this fixed before moving to CR. What I suggested to him on IRC and what I believe is the best approach to reconcile the two worlds (WHATWG live standards and W3C snapshots) is to take the current version of the spec to LC and update the ED to use animation frame task and mark it as a WIP feature. I opened issue 75 last week as a reminder to do that. Arthur, what do you think of that solution? We can certainly publish a LC with open issues (as was explicitly noted in the original CfC [1]). However, I do want to emphasize that if any substantive issue is filed after the LC is published, and the group agrees to address any such issue(s), the group must publish another LC before the spec can move to CR. I mention this because LC-LC loops are time consuming for the group, implementers and developers and thus should be avoided if possible. As such, it seems like pursuing #1 should be the next step. -Thanks, AB -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
On 10/2/14 7:15 AM, Mounir Lamouri wrote: Can we at least publish a new WD so people stop referring to the old TR/? Yes of course. (And certainly continue to work with Anne, Marcos, etc. on a mutually agreeable way forward for Issue 75.) And speaking of Issue 75: On 9/25/14 9:26 AM, Mounir Lamouri wrote: What I suggested to him on IRC and what I believe is the best approach to reconcile the two worlds (WHATWG live standards and W3C snapshots) is to take the current version of the spec to LC and update the ED to use animation frame task and mark it as a WIP feature. I opened issue 75 last week as a reminder to do that. I just checked the ED and didn't notice Issue 75 mentioned. Are you planning to do what you say above before a new WD is published? -Thanks, ArtB
Re: Service worker popup (rich notification)
On the one hand, there are some great use cases for this (video calls, alarm clocks, two-factor authentication, sending a map from desktop to mobile before you leave the house, etc). On the other hand, browsers have traditionally had to block popups except following a user gesture, and it's easy to imagine that an API for showing popups from the background after some time delay (e.g. push or background sync) would be abused (for spam or even phishing). So I guess this is something we'll want to support eventually, but it's blocked on coming up with clear UI for safely granting and revoking permission to show popups from the background. API-wise, you probably know that the ServiceWorkerClient interface https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-client lets a SW focus existing same-origin tabs or open new ones (by constructing a client; perhaps confusingly). But at least in the short term, we've been planning to only allow that from a notificationclick event (i.e. following a user gesture). --John On 2 October 2014 09:04, Anne van Kesteren ann...@annevk.nl wrote: I wonder how much thought has been given to creating a popup (rich notification if you will) from a service worker. Combined with the push API this is what will enable e.g. Skype to cease being a native application. There's also some potential other uses for this. -- https://annevankesteren.nl/
Relative URLs in Web Components
Consider a packaged (possibly third-party) web component you would like to use on your site. Using your favorite package manager, you install the component into a dependencies folder. Ideally you can now consume it just by `link rel=import`ing the component into your pages, without having to make any changes to the third-party code. Unfortunately this is not true for components that use relative URLs to refer to resources that are packaged and installed along with the component. To help illustrate this, I’ve created a simple example component that uses CSS to apply a green background image. Code: https://github.com/mathiasbynens/relative-urls-in-web-components/tree/gh-pages/packaged-web-component Here’s an example (included in the component’s package) showing the component in action: https://mathiasbynens.github.io/relative-urls-in-web-components/packaged-web-component/example.html It loads [the `main.css` file](https://mathiasbynens.github.io/relative-urls-in-web-components/packaged-web-component/main.css) which in turn fetches [`background.png`](https://mathiasbynens.github.io/relative-urls-in-web-components/packaged-web-component/background.png). So far, everything works fine. But if the component gets `link rel=import`ed from any other directory (as in the above scenario), the relative reference to `main.css` won’t normalize to the expected URL. Example: https://mathiasbynens.github.io/relative-urls-in-web-components/example.html (Note the lack of green background.) Can this be fixed, somehow? Doing so would make it possible to use third-party web components without having to edit them just to make the URLs match your setup. Possible solutions (just brainstorming here): * Make relative URLs within a `template` within an HTML-Import’ed document resolve using the imported document’s URL (rather than the parent document’s URL) as the base URL. * Make `link` not inert in `template`. Thoughts?
Re: Relative URLs in Web Components
On Thu, Oct 2, 2014 at 2:59 PM, Mathias Bynens math...@qiwi.be wrote: Thoughts? This is a hard problem: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c8 -- https://annevankesteren.nl/
Re: Service worker popup (rich notification)
On 2 October 2014 05:48, John Mellor joh...@google.com wrote: So I guess this is something we'll want to support eventually, but it's blocked on coming up with clear UI for safely granting and revoking permission to show popups from the background. Doesn't this already exist, at least in some form? Gecko already has permissions management functions for Show Notifications.
[Bug 14086] When performing AJAX type queries, they are already asynchronous and already occur in another thread. However, I have found that parsing the XML reply and converting that to a represent
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14086 brunoais brunoa...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||brunoa...@gmail.com Resolution|WONTFIX |--- --- Comment #16 from brunoais brunoa...@gmail.com --- I'd like to revive this bug and ask for a minor alternative that might be possible and OK to go for. The idea is to allow passing document fragments to worker threads (document fragments only). The main idea is that, sometimes, a large amount of changes or analysis are required to be made to the DOM. By allowing sending a fragment to a worker thread, the overhead required to translate all the DOM send into an analyzable format. You may even require http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode Or some work adapting the content to the worker. As long as that is made in the other thread, there's no issue on my end. The requirements for my use-case are: --- Having a nearly complete document DOM --- This document is not connected to any interface. In other words, it acts the same way as a documentFragment towards everything (heck, it can even be an actual documentFragment, if possible). Any changes to it only changes that DOM tree inside the worker thread. --- You can pass DOM objects --- A passed DOM object is read-only on the destination until http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode is called. OR Passing a DOM is made by cloning it to the document that resides in the worker thread. The result of that clone is equivalent of passing it through the importNode() method. (I prefer the 2nd one) If this is enabled, when the parsing work on the js side is more complicated, it may be sent to the worker thread to deal with the specifics and still have tree-like operations with Nodes that look like the interface's DOM. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Service worker popup (rich notification)
Notifications tend to be relatively unobtrusive and sit in a UA/OS-specific notification tray, usually in a corner of the screen; what we're talking about here (at least on mobile) would be launching a maximised (or possibly fullscreen) browser window on top of whatever the user is currently doing. This seems to either require a somewhat stronger trust signal from the user, or a very easy mechanism for revoking the permission if the website does spam you; and probably in either case showing the url bar should be compulsory to prevent phishing. But this isn't something we've thought about deeply yet. On 2 October 2014 17:47, Martin Thomson martin.thom...@gmail.com wrote: On 2 October 2014 05:48, John Mellor joh...@google.com wrote: So I guess this is something we'll want to support eventually, but it's blocked on coming up with clear UI for safely granting and revoking permission to show popups from the background. Doesn't this already exist, at least in some form? Gecko already has permissions management functions for Show Notifications.
Re: CfC: publish LCWD of Screen Orientation API; deadline September 18
Though I also agree with Mounir. Changing the event source doesn't seem like a change that's substantial enough that we'd need to go back to WD/LCWD. Does any implementation actually feel that it would be? / Jonas On Thu, Oct 2, 2014 at 4:15 AM, Mounir Lamouri mou...@lamouri.fr wrote: Can we at least publish a new WD so people stop referring to the old TR/? -- Mounir On Wed, 1 Oct 2014, at 20:36, Arthur Barstow wrote: On 9/25/14 9:26 AM, Mounir Lamouri wrote: On Thu, 25 Sep 2014, at 21:52, Arthur Barstow wrote: On 9/25/14 6:36 AM, Anne van Kesteren wrote: It effectively comes down to the fact that the specification describes something, but Chrome implements it in another way per how I suggested it should work (using animation frame tasks). So this appears to be [Issue-40] and I think a one-line summary is the Editors consider this something that can be deferred to the next version and Anne considers it something that should be addressed before LC is published. Vis-a-vis this CfC, it seems the main options are: 1. Continue to work on this issue with the goal of getting broader consensus on the resolution 2. Publish the LC as is 3. Publish the LC as is but explicitly highlight this Issue and ask for Implementer/Developer feedback 4. Other options? Of course, I'd like to hear from others but I tend to think we should first try #1 (especially since Anne indicates the spec and at least one implementations are currently not aligned). Mounir, Marcos - would you please work with Anne on a mutually agreeable solution? Last I checked, animation frame task was still underdefined. This is what you can read in the WHATWG's fullscreen specification: Animation frame task is not really defined yet, including relative order within that task, see bug 26440. In my opinion, if the spec is changed to use animation frame task, it would not change much in the current state of things. Well, perhaps this would be true but the devil's in the details and the details do matter (see below). Also, I'm not entirely sure why Anne is so loudly complaining about that issue. The issue was not closed or waived but postponed until we can properly hooked to the thing. LC doesn't freeze the specification and we could definitely get this fixed before moving to CR. What I suggested to him on IRC and what I believe is the best approach to reconcile the two worlds (WHATWG live standards and W3C snapshots) is to take the current version of the spec to LC and update the ED to use animation frame task and mark it as a WIP feature. I opened issue 75 last week as a reminder to do that. Arthur, what do you think of that solution? We can certainly publish a LC with open issues (as was explicitly noted in the original CfC [1]). However, I do want to emphasize that if any substantive issue is filed after the LC is published, and the group agrees to address any such issue(s), the group must publish another LC before the spec can move to CR. I mention this because LC-LC loops are time consuming for the group, implementers and developers and thus should be avoided if possible. As such, it seems like pursuing #1 should be the next step. -Thanks, AB
[Bug 14086] When performing AJAX type queries, they are already asynchronous and already occur in another thread. However, I have found that parsing the XML reply and converting that to a represent
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14086 brunoais brunoa...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #19 from brunoais brunoa...@gmail.com --- I'll open a new bug -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26957] New: Allow sending DOM objects to Workers and expose a DOM (or DOM-like) interface to workers
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26957 Bug ID: 26957 Summary: Allow sending DOM objects to Workers and expose a DOM (or DOM-like) interface to workers Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Web Workers (editor: Ian Hickson) Assignee: i...@hixie.ch Reporter: brunoa...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org I'd like to revive this bug and ask for a minor alternative that might be possible and OK to go for. The idea is to allow passing document fragments to worker threads (document fragments only). The main idea is that, sometimes, a large amount of changes or analysis are required to be made to the DOM. By allowing sending a fragment to a worker thread, the overhead required to translate all the DOM send into an analyzable format. You may even require http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode Or some work adapting the content to the worker. As long as that is made in the other thread, there's no issue on my end. The main use case here is: Extensive work is required to be made on a subtree of a page's DOM. Here's an example generic use-case. 1. The main thread splits the DOM tree into parts and then it sends those parts to the worker threads. 2. The worker threads do the DOM changes. 3. The worker threads send the changed DOM to the original thread. 4. The original thread integrates the changed DOM nodes from the workers into it's own DOM. The requirements for my use-case are: --- Worker having a nearly complete document DOM --- This document is not connected to any interface. In other words, it acts the same way as a documentFragment towards everything (actually, it can even be an actual documentFragment, if possible). Any changes to it only changes that DOM tree inside the worker thread. --- You can pass DOM objects --- A passed DOM object is read-only on the destination until http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode (or equivalent) is called. This one may be harder to do because there's no synchronization and implementing a copy-on-write may just be too much. OR Passing a DOM is made by cloning it to the document that resides in the worker thread. The result of that clone is equivalent of passing it through the importNode() method. This one should be the easiest to implement. It may be slower, but then it should only affect performance for the first send (considering that there are multiple workers). There can be optimizations here such as for documentFragment. If transfering a documentFragment it could behave just like a Transferable such as ArrayBuffer (once transfered, it cannot be accessed from the source thread). As far as I know, there's no way for a change in a documentFragment to be reflected in the interface's document and vice-versa but there can be internal code requirements that make this optimization impossible. If this is enabled, when the parsing work on the js side is more complicated, it may be sent to the worker thread to deal with the specifics and still have tree-like operations with Nodes that look like the interface's DOM. Just to keep it clear: - This is still not memory sharing, just memory transfer or memory ownership transfer. - All changes inside the worker do not reflect on any other thread. I.E. changes on a specific thread's DOM documents do not reflect on any other thread's DOM documents. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Service worker popup (rich notification)
On Thu, Oct 2, 2014 at 11:31 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 2, 2014 at 8:27 PM, John Mellor joh...@google.com wrote: This seems to either require a somewhat stronger trust signal from the user, or a very easy mechanism for revoking the permission if the website does spam you; and probably in either case showing the url bar should be compulsory to prevent phishing. But this isn't something we've thought about deeply yet. Indeed. The Notifications API is nice, but it's not suitable for this. You need a browsing context of sorts so you can show images, video, buttons, etc. Indeed. I wouldn't call these notifications at all. What's needed here is to launch full browser windows so that we can display full-screen or full-window UIs to the user. To make matters even more complicated, generally speaking you want to be able to do this on a mobile device, even if it's locked. I.e. an alarm clock app wouldn't be terribly useful if it only worked when the device was unlocked. And a skype app wouldn't be terribly useful if you could only receive calls when the device was unlocked. Fortunately, while this goes outside the browser window, it doesn't break the same-origin boundary. So it should be quite possible to solve this the same way we're planning on solving other such APIs, like storage, indexedDB and notifications. I.e. make the API async and then leave it up to UAs to implement policies. / Jonas
PSA: publishing a new WD of Push API on October 7
Michael and the other Push API Editors intend to publish a new WD of Push API on or about October 7: https://w3c.github.io/push-api/ If anyone has any major concerns about this plan, please reply as such right away. -Thanks, AB
