Re: [whatwg] Notifications and service workers
On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: Another thing we could do here is to simply not address this use case. Does gmail for android do the same thing? I wasn't able to reproduce it though I might have done something wrong. AFAICT, no - gmail for android doesn't use web notifications. In general the mobile versions of gmail are kind of bare-boned fallbacks in favor of the native apps. I'm not sure that we should pay too much attention to the use case of apps like gmail that want to do lots of hands-on control of their notifications - I think that's pretty much a rare case. I do think it's useful to have some guidelines for how platforms handle notifications, though, just to make sure that some web developer doesn't just test on one platform, and get unexpected behavior on others. So, trying to encourage auto-close behavior (maybe via SHOULD language in the spec) would be good for consistency's sake. Clarifying what should happen when the user clicks on a notification would also be good (should it bring the tab to the foreground? Should it leave it up to the app? Should it provide a default, but allow apps to override it?) - I think all three of these behaviors are currently implemented (or have been in the past) by different UAs.
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 12:05 AM, Andrew Wilson atwil...@google.com wrote: On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: Another thing we could do here is to simply not address this use case. Does gmail for android do the same thing? I wasn't able to reproduce it though I might have done something wrong. AFAICT, no - gmail for android doesn't use web notifications. In general the mobile versions of gmail are kind of bare-boned fallbacks in favor of the native apps. Actually, my question was in regards to the native gmail app. Not web content of any sort. I'm not sure that we should pay too much attention to the use case of apps like gmail that want to do lots of hands-on control of their notifications - I think that's pretty much a rare case. I do think it's useful to have some guidelines for how platforms handle notifications, though, just to make sure that some web developer doesn't just test on one platform, and get unexpected behavior on others. So, trying to encourage auto-close behavior (maybe via SHOULD language in the spec) would be good for consistency's sake. Clarifying what should happen when the user clicks on a notification would also be good (should it bring the tab to the foreground? Should it leave it up to the app? Should it provide a default, but allow apps to override it?) - I think all three of these behaviors are currently implemented (or have been in the past) by different UAs. I agree with this. Generally speaking we tend to leave UI up to browsers and avoid speccing it. However given that notifications is all about UI I think doing so effectively makes the feature untrustable for authors. We don't need to define exact pixels etc, but I think we need to define some semantics in the form of expected behavior of UI. / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 9:15 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Oct 6, 2014 at 12:05 AM, Andrew Wilson atwil...@google.com wrote: On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: Another thing we could do here is to simply not address this use case. Does gmail for android do the same thing? I wasn't able to reproduce it though I might have done something wrong. AFAICT, no - gmail for android doesn't use web notifications. In general the mobile versions of gmail are kind of bare-boned fallbacks in favor of the native apps. Actually, my question was in regards to the native gmail app. Not web content of any sort. Ah, sorry, didn't understand. From what I can tell, gmail on android aggregates multiple messages into a single notification (like the list notification type you suggested). I'm assuming this is done by gmail itself and not the OS, but my Android-fu is a bit limited so I'm not positive. I note that the native gmail app does different things depending on what type of notification is visible. If there's just one new email in the notification, the notification lets you archive/reply to the email right from the notification, and just clicking the notification brings up the email in the native app. If there are more than one email in the notification (list notification) then there are no extra UI options, and clicking the notification just launches the app and brings up your inbox.
Re: [whatwg] Notifications and service workers
On Oct 1, 2014 4:31 AM, Anne van Kesteren ann...@annevk.nl wrote: Combined with dropping the open event, I think I have enough to rework the current Notifications API. Is there anything I'm missing? I just remembered that another thing that came up was the ability to remove a notification bases on tag. I.e. without having to get a reference to the notification instance. This is probably extra helpful if .get() doesn't return non-persistent notifications. For example to simplify the case when one tab creates a notification, but then the user opens the same app in another tab. The newly opened window might want to close any notifications about pending messages. This could be accomplished using BroadcastChannel, but would be much simpler if we had the ability to close directly using a tag. In fact, the common case when wanting to close a notification is likely one where you know which tag you want to close, but don't have a reference to a Notification instance. / Jonas
Re: [whatwg] Notifications and service workers
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas Sicking Generally speaking we tend to leave UI up to browsers and avoid speccing it. However given that notifications is all about UI I think doing so effectively makes the feature untrustable for authors. We don't need to define exact pixels etc, but I think we need to define some semantics in the form of expected behavior of UI. I just wanted to pop in and say I agree with this effort. It is exploring new territory, and it's going to be a bit tricky. E.g. can you even write tests for this kind of thing? How specific is this kind of UI-speccing to today's UI patterns, versus those of five years from now? But the overriding point about this being necessary to give authors something worthwhile is very strong.
Re: [whatwg] Notifications and service workers
On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: I agree. One of the big shortcomings of the current spec is that it leaves UI too undefined. This is particularly problematic given that notifications is all about using UI to get certain types of user attention. I'm willing to try making more specific UI recommendations. Have any in mind? -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Sat, Oct 4, 2014 at 4:59 AM, Jonas Sicking jo...@sicking.cc wrote: While JS running in the page can't tell a difference, the user certainly can so it can still be perceived as a breaking change. Yeah, we'll need to see if new Notification() can be changed enough or whether we need three types of notifications... Yeah, it seems like we need to keep this. Through opt-in works. It seems like if we keep this event it should at the very least be possible to tell closed because of user action from closed because of timeout or other platform policy. And maybe also closed because of application calling .close(). Otherwise it doesn't seem like it meets Andrew's use case or the use case above. I added the service worker API now, but have not addressed this particular point yet. Does anyone have a good idea of what should be done here? Note that I don't actually think that we need to even return a Notification instance when a persistent notification is created. Fair, I return undefined now. -- https://annevankesteren.nl/
Re: [whatwg] Notifications: remove show event?
On Wed, Oct 1, 2014 at 1:09 PM, Anne van Kesteren ann...@annevk.nl wrote: Per http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0100.html and other emails in that thread it seems like the show event can be removed from notifications altogether. I will remove it. Done. -- https://annevankesteren.nl/
Re: [whatwg] URL: test case review
On Mon, Oct 6, 2014 at 3:13 AM, Sam Ruby ru...@intertwingly.net wrote: http://intertwingly.net/stories/2014/10/05/urltest-results/24f081633d This does not match what I find in browsers. (I did not look through the list exhaustively, see below, but since this was the first one...) I also found out today that https://github.com/w3c/web-platform-tests/commit/2712b5611a4e048e04a7dc814a7a31413d2d367a has not been checked against the specification. So all those tests are likely wrong. File URLs differ per browser and per platform so there will always be differences there. I tried to come up with a sensible algorithm, but it might need checking again. Overall, the URL specification could likely use another month of serious work on the parser side. It is not clear to me now would be good to invest that time. I would like to see some more interest from implementers first. -- https://annevankesteren.nl/
Re: [whatwg] URL: test case review
On 10/06/2014 12:42 PM, Anne van Kesteren wrote: On Mon, Oct 6, 2014 at 3:13 AM, Sam Ruby ru...@intertwingly.net wrote: http://intertwingly.net/stories/2014/10/05/urltest-results/24f081633d This does not match what I find in browsers. (I did not look through the list exhaustively, see below, but since this was the first one...) Can you explain the methodology you used? The method I used can be found via: wget http://intertwingly.net/stories/2014/10/05/urltest wget http://intertwingly.net/stories/2014/10/05/urltestdata.json TL:DR; I created a page with a script that (a) fetches input data using XHR; (b) updates an a and a base element and then captures various properties for each test, and (c) posts the result using XHR. - Sam Ruby
Re: [whatwg] URL: test case review
On Mon, Oct 6, 2014 at 6:54 PM, Sam Ruby ru...@intertwingly.net wrote: On 10/06/2014 12:42 PM, Anne van Kesteren wrote: On Mon, Oct 6, 2014 at 3:13 AM, Sam Ruby ru...@intertwingly.net wrote: http://intertwingly.net/stories/2014/10/05/urltest-results/24f081633d This does not match what I find in browsers. (I did not look through the list exhaustively, see below, but since this was the first one...) Can you explain the methodology you used? Sure, I gave ? as input and then checked the serialized URL (since you can't trust the search property). https://dump.testsuite.org/url/inspect.html works for this. wget http://intertwingly.net/stories/2014/10/05/urltest wget http://intertwingly.net/stories/2014/10/05/urltestdata.json TL:DR; I created a page with a script that (a) fetches input data using XHR; (b) updates an a and a base element and then captures various properties for each test, and (c) posts the result using XHR. Is there a chance that the library on the server does not pick up on a lone ?? -- https://annevankesteren.nl/
Re: [whatwg] URL: test case review
On 10/06/2014 12:59 PM, Anne van Kesteren wrote: On Mon, Oct 6, 2014 at 6:54 PM, Sam Ruby ru...@intertwingly.net wrote: On 10/06/2014 12:42 PM, Anne van Kesteren wrote: On Mon, Oct 6, 2014 at 3:13 AM, Sam Ruby ru...@intertwingly.net wrote: http://intertwingly.net/stories/2014/10/05/urltest-results/24f081633d This does not match what I find in browsers. (I did not look through the list exhaustively, see below, but since this was the first one...) Can you explain the methodology you used? Sure, I gave ? as input and then checked the serialized URL (since you can't trust the search property). https://dump.testsuite.org/url/inspect.html works for this. wget http://intertwingly.net/stories/2014/10/05/urltest wget http://intertwingly.net/stories/2014/10/05/urltestdata.json TL:DR; I created a page with a script that (a) fetches input data using XHR; (b) updates an a and a base element and then captures various properties for each test, and (c) posts the result using XHR. Is there a chance that the library on the server does not pick up on a lone ?? I found the bug, thanks for reporting it. The problem is that the following properties are not defined as 'enumerable', so are not picked up when I serialize the tests as JSON: https://github.com/w3c/web-platform-tests/blob/master/url/urltestparser.js#L17 - Sam Ruby
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 9:26 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: I agree. One of the big shortcomings of the current spec is that it leaves UI too undefined. This is particularly problematic given that notifications is all about using UI to get certain types of user attention. I'm willing to try making more specific UI recommendations. Have any in mind? I think we should define that non-persistent notifications disappear after a timeout. And define that on mobile platforms with notification centers, that these notifications are *not* added there, but rather is just displayed on screen for a short period of time. I also think that we should define that for persistent notifications, that these *are* added to mobile notification centers. I also think that we should define that clicking a non-permanent should as default action focus the window which created the notification. We should also define that during the click event the browser is encouraged to allow calls to window.focus() to, work. Even in UAs which have restrictive policies about when window.focus() is honored. Though some care needs to be taken to not enable pop-unders, but as long as we don't require that UAs honor window.focus() and instead just encourage it, I think that's covered. / Jonas
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 9:29 AM, Anne van Kesteren ann...@annevk.nl wrote: Yeah, it seems like we need to keep this. Through opt-in works. It seems like if we keep this event it should at the very least be possible to tell closed because of user action from closed because of timeout or other platform policy. And maybe also closed because of application calling .close(). Otherwise it doesn't seem like it meets Andrew's use case or the use case above. I added the service worker API now, but have not addressed this particular point yet. Does anyone have a good idea of what should be done here? If we keep the close event, then I think adding a .reason property to the event object, which can be set to user, platform or api should work. Though based on Andrew's latest comments, I don't know that anyone strongly feels that we need to keep the event? / Jonas
