Re: [whatwg] Notifications improvements
On Tue, Aug 5, 2014 at 11:44 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson atwil...@google.com wrote: On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson atwil...@google.com wrote: On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, We've on and off discussed various features added to notifications. It'd be great to move forward with some of these improvements. I think the most low hanging fruit would be to add the following as data that can be displayed in a notification: * Progress bar * Lists of title/body pairs * Date (for things like event will happen in 10 minutes) So, many of these cases were what the original HTMLNotification API was supposed to address. This was eventually shot down for a number of (good) reasons: too much complexity on the implementation side, and more importantly, the fact that these more complex notifications aren't compatible with various platform notification frameworks and so this would be a source of platform/UA incompatibility. It's not clear to me that re-adding support for these use cases one at a time as distinct notification types is really a good path forward, or that it's necessarily low-hanging fruit unless we have a good idea for how to deal with the platform-compatibility issue. Actually, given that the UA has a very high degree of semantic understanding of these properties, I think it should be doable to implement on top of all existing platform notification systems. In all of the above cases you can come up with a reasonable string to add to the end to render the content. This is what pages have to do right now anyway. I had assumed from the examples you gave that the goal of these new notification types was to have dynamically updating notifications (progress bar, timestamps that update with a countdown to an event, etc), which it wasn't clear could be cleanly implemented across all platform notification systems without significant jank. For dates the idea is definitely to enable the notifications to be dynamically updated by the platform. For progress bars my expectation was not that it would be automatically updated. Instead it would be updated using the exact same mechanism that we have for notifications today, i.e. using the tag mechanism. So the jank would be the same whether OS notifications supports rendering progress bars or if they are just able to render text. OK, so the idea is that you'd display a new progress bar notification with the same tag as an existing progress bar notification, and the browser would see that they are the same and just update the progress bar? Or would we pull down and re-display a new progress bar? If we're just updating the existing progress bar, then I guess for compatibility, the old notification would still get the normal events as if it had been replaced? For lists the idea is not to update them any more or less than for plain text content. Just like with text content pages will likely want to update them occasionally, but that's not a core aspect of the feature. The intent for things like progress bars would be that they have greater visibility than your typical 5 seconds and then hidden email notification, which also may not be doable with many notification frameworks. This is a quite interesting idea. I hadn't thought of that. I'm slightly dubious about adding new semantic notification types (I'd still rather give app developers the tools to build their own richer notifications instead of giving them a canned set), but it's definitely worth discussing further. I'm not sure I understand this argument. If you are concerned about having poor fallback on platforms that can't render the UI components discussed above, then surely that concern is even greater if we enable pages to build their own rich notifications? I have a couple of concerns: 1) Anything more than plain text + icon notifications won't map well to native notification platforms. If we're going to build support in the API for something that isn't well supported by native notification platforms, then we should get the most bang for our buck and build something that's flexible enough to meet many use cases. 2) I don't feel like the limitations with the current API are addressed by adding 3-4 pre-canned notification types. I feel like the current notification API addresses a broad swath of use cases, and there's a long tail of unaddressed cases that we can't serve well with any pre-canned notification types - if we want to try to address those long-tail cases, then I'd rather have us address them with a flexible API that gives developers more control over the notification content rather than cherry-picking individual use cases. I understand your concern that is driving this proposal: you don't want to provide
Re: [whatwg] Fetch Objects and scripts/stylesheets
On Mon, Jul 28, 2014 at 7:24 PM, Ian Hickson i...@hixie.ch wrote: It would presumably return the same object that was being proposed for the other way around (the proposal where you call as_stylesheet or whatever). I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533 on investigating whether we can reuse the Request object (which is passed to fetch(), and used in service workers to expose requests from a window or worker). There are some complications given what can be set through HTML and what could be set through script and how to keep those best synchronized. We should be able to figure something out I think. Not sure how high of a priority this is though. -- http://annevankesteren.nl/
Re: [whatwg] Notifications improvements
On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com wrote: I understand your concern that is driving this proposal: you don't want to provide rich APIs that can't be well implemented on every platform, and thereby fragment the web platform. I just don't want to see us go down this path of adding these new notification types that are so limited in ability that people will just keep using general notifications anyway - I'd rather just stick with the existing API. Are you unenthusiastic about any of the proposed additions (what about those already added?) or is this more about the more complex features such as indication of progress? Having a new field timestamp that carries a particular point in time related to the message seems quite useful for instance and not very intrusive. -- http://annevankesteren.nl/
Re: [whatwg] Notifications improvements
For what it's worth. I'm not actively working on notifications at the moment. If anything is about to be implemented please ping the relevant issue and I'll try to prioritize it somehow. More detailed design sketches appreciated. On Wed, Aug 6, 2014 at 12:16 AM, Jonas Sicking jo...@sicking.cc wrote: The place that this has come up in FirefoxOS is when notifying about incoming emails. We would like to display the sender and the subject for each newly arrived email. At first this seemed like a pretty unusual edge case, but after looking at chrome-apps notification API they had this exact feature. So it seemed like this has come up elsewhere too. This is now https://github.com/whatwg/notifications/issues/21 The goal of a Date field for notifications is quite different. It's to enable a notification that's associated with an event that happend, or is going to happen, at a different time than when the notification API JS call happened. Ah yes, we discussed this but I forgot to track it somewhere: https://github.com/whatwg/notifications/issues/20 We also need to keep state on the Notification object if the user has clicked the notification or not. Why is that? Relying on the application to track this perfectly has two problems. First off it means that applications has to register a ServiceWorker handler for all notification objects and run any logic related to handling a click right away. Rather than simply handle it next time the application is started, which would save on both CPU and battery. The current service worker proposal does not have a feature of having a handler per notification. Rather, you register for notificationclick and get an event for each such thing. Up to the discretion of the user agent of course. Second, it's much more error prone to track this in application space given potential for bugs, crashes and IO errors. If we do this it would be the first thing that would actually require changing a Notification object instance. At the moment the whole thing is static. -- http://annevankesteren.nl/
Re: [whatwg] Notifications improvements
On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com wrote: I understand your concern that is driving this proposal: you don't want to provide rich APIs that can't be well implemented on every platform, and thereby fragment the web platform. I just don't want to see us go down this path of adding these new notification types that are so limited in ability that people will just keep using general notifications anyway - I'd rather just stick with the existing API. Are you unenthusiastic about any of the proposed additions (what about those already added?) or is this more about the more complex features such as indication of progress? I'm (somewhat) unenthusiastic about the new semantic types, because I'm not sure they'd get enough uptake to be worth the effort to implement (note that this is just my personal opinion - I'm no longer as heavily involved in the notification work within Chromium, so Peter B's opinion carries much more weight than mine when it comes to determining what we'd implement). I am quite enthusiastic about adding support in the API around allowing users to interact with notifications after the parent page has closed, however. Having a new field timestamp that carries a particular point in time related to the message seems quite useful for instance and not very intrusive. Perhaps I'm not understanding how this would be used. What would such a notification look like for (say) a calendar event (Your 1PM meeting starts in 5 minutes) versus a countdown timer (In 73 seconds, your hard boiled egg will be done cooking)? Would we have to provide a format string so the UA knows where to inject the time remaining, or would it always have to be put at the end? Do we need to specify granularity of updates (i.e. if I have a stopwatch app, I probably want to update every second, but for a calendar app, updating every 5 minutes is probably sufficient, until we get down to the last 5 minutes)? At least for me, a calendar notification that is constantly updating its countdown every minute but has no snooze functionality is actually a mis-feature, because it's distracting. Again, I don't want to be overly negative about this - maybe there are use cases like list notifications where the new API would be really useful, but as soon as I start thinking about more complex display scenarios, I immediately want to start having more control over the formatting of the text being displayed, and i wouldn't get that with this proposal.
Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage
On Tue, Aug 5, 2014 at 10:04 AM, Brian Blakely anewpage.me...@gmail.com wrote: On Tue, Aug 5, 2014 at 11:21 AM, Justin Novosad ju...@google.com wrote: On Tue, Aug 5, 2014 at 7:47 AM, Ashley Gullen ash...@scirra.com wrote: I am against this suggestion. If you are serious about performance then you should use WebGL and implement your own batching system, which is what every major 2D HTML5 game framework I'm aware of does already. Adding batching features to canvas2d has three disadvantages in my view: 1. Major 2D engines already support WebGL, so even if this new feature was supported, in practice it would not be used. 2. There is opportunity cost in speccing something that is unlikely to be used and already well-covered by another part of the web platform. We could be speccing something else more useful. 3. canvas2d should not end up being specced closer and closer to WebGL: canvas2d should be kept as a high-level easy-to-use API even with performance cost, whereas WebGL is the low-level high-performance API. These are two different use cases and it's good to have two different APIs to cover them. If you want to keep improving canvas2d performance I would worry you will simply end up reinventing WebGL. These are good points. The only counter argument I have to that is that a fallback from WebGL to canvas2d is unfortunately necessary for a significant fraction of users. Even on web-browsers that do support WebGL, gl may be emulated in software, which can be detected by web apps and warrants falling back to canvas2d (approx. 20% of Chrome users, for example). I realize that there is currently a clear ease of use vs. performance dichotomy between 2d and webgl, and this proposal blurs that boundary. Nonetheless, there is developer-driven demand for this based on a real-world problem. Also, if 2D canvas had better performance characteristics, it would not be necessary for some game engines to have dual (2d/webgl) implementations. -Justin My take is similar to Ashley's, and I wonder how buffing up the toy API (2D) compensates for the fact that the performance API (GL) has compatibility problems, even on platforms that support it. If the goal is to solve the latter, why not introduce more direct proposals? Can you explain what you're asking for? Are you asking for a proposal that fixes compatibility?
Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage
On Tue, Aug 5, 2014 at 5:55 PM, Ashley Gullen ash...@scirra.com wrote: If your argument is that WebGL sometimes falls back to canvas2d, this generally only happens when the system has crappy drivers that are blacklisted for being insecure/unstable. The solution to this is to develop and distribute better drivers that are not blacklisted. This is already happening and making good progress - according to Mozilla's stats, Firefox users who get WebGL support has increased from 33% in 2011 to 85% in 2014 ( http://people.mozilla.org/~bjacob/gfx_features_stats/). As Justin stated, 20% of current Chrome users currently fall back to canvas 2d. This is a large chunk of the market. Small developers that don't have the resources to develop for concurrent WebGL and Canvas2D code paths will certainly code for just Canvas since that will give them close to 100%. I feel it is likely to continue to approach ubiquitous WebGL support, making fallbacks unnecessary. This also solves the problem of having to have dual renderer implementations: only the WebGL renderer will be necessary, and this is far more compelling than a souped-up canvas2d, since WebGL can use shader effects, have advanced control over textures and co-ordinates, also do 3D, and so on. This cannot all be brought to canvas2d without simply reinventing WebGL. Further, crappy drivers can also cause software-rendered canvas2d as well, which is likely so slow to begin with that batching will have no important performance improvement. Software-rendered WebGL is just another workaround to crappy drivers (or in rare cases systems without GPUs, but then who's going to be gunning for high performance there?) and there is still no guarantee falling back to canvas2d will be GPU-accelerated, especially since the system already has such poor drivers that the browser has blacklisted it for WebGL support. The real problem is that there is not 100% WebGL support everywhere, but with drivers improving and Apple and Microsoft on board I'm sure that will fix itself eventually. Please don't spec features to improve canvas2d performance in the mean time; I don't see it having any long-term utility for the web platform. When do you envision that OpenGL drivers are bug free everywhere? History is not on your side here... I would much rather have something short term that can be implemented with low effort and improves performance. I don't really understand why you and Brian are so opposed to improving the performance of canvas 2D. There are a lot of people that use and like its API. WebGL on the other hand, has a very steep learning curve and problems are not always obvious. Following your logic, why work on new canvas or SVG features as they can theoretically be emulated in WebGL? Or now that we have asm.js, why even bother with new JavaScript features? On 5 August 2014 16:21, Justin Novosad ju...@google.com wrote: On Mon, Aug 4, 2014 at 6:39 PM, Robert O'Callahan rob...@ocallahan.org wrote: It looks reasonable to me. How do these calls interact with globalAlpha etc? You talk about decomposing them to individual drawImage calls; does that mean each image draw is treated as a separate composite operation? Composited separately is the intent. A possible internal optimization: the implementation could group non-overlapping draw and composite them together. Currently you have to choose between using a single image or passing an array with one element per image-draw. It seems to me it would be more flexible to always pass an array but allow the parameters array to refer to an image by index. Did you consider that approach? Had not thought of that. Good idea. On Mon, Aug 4, 2014 at 7:35 PM, Katelyn Gadd k...@luminance.org wrote: I'd suggest that this needs to at least handle globalAlpha. It would be trivial to add a an addition format that includes alpha. Replacing the overloading with individual named methods is something I'm also in favor of. That's something I pondered and was not sure about. Eliminating the parameter format argument would be nice. Your feature-detection argument is a really good reason. I get the impression that ordering is implicit for this call - the batch's drawing operations occur in exact order. It might be worthwhile to have a way to indicate to the implementation that you don't care about order, so that it is free to rearrange the draw operations by image and reduce state changes. Doing that in userspace js is made difficult since you can't easily do efficient table lookup for images. I am not sure exposing that in the API is a good idea because it opens the door to undefined behavior. It could result in different implementations producing drastically different yet compliant results. Perhaps implementations could auto-detect draw operations that are commutative based on a quick
