Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Thu, May 15, 2014 at 6:12 PM, Peter Beverloo bever...@google.com wrote: For |notificationshow|, there is a worry here that if we decide to support delayed notifications, it would enable developers to use notifications to set precise timers: create a delayed notification to be displayed an hour from now, get the |notificationshow| event, and call |notification.close()|. This is something which I'd hope would only be possible through some kind of alarms API, which in itself may be undesirable to start with. Delayed notifications seems like a new feature of sorts we should probably discuss separately. Although now you can create Notification objects from a service worker you could get them as the result of e.g. a server push so maybe it's not so new as it could be polyfilled in that way... Service worker integration makes sense to me. I guess I'll wait with updating the Notifications API until that is further along. -- http://annevankesteren.nl/
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Fri, May 16, 2014 at 2:57 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 15, 2014 at 6:12 PM, Peter Beverloo bever...@google.com wrote: For |notificationshow|, there is a worry here that if we decide to support delayed notifications, it would enable developers to use notifications to set precise timers: create a delayed notification to be displayed an hour from now, get the |notificationshow| event, and call |notification.close()|. This is something which I'd hope would only be possible through some kind of alarms API, which in itself may be undesirable to start with. Delayed notifications seems like a new feature of sorts we should probably discuss separately. Although now you can create Notification objects from a service worker you could get them as the result of e.g. a server push so maybe it's not so new as it could be polyfilled in that way... Keeping possible future additions in mind allows us to avoid ending up with a precise alarms-like API if and when we decide to do so. Beyond that, the subject of delayed notifications indeed is a separate discussion. Service worker integration makes sense to me. I guess I'll wait with updating the Notifications API until that is further along. Do you have a specific milestone in mind? Thanks, Peter -- http://annevankesteren.nl/
Re: [whatwg] WebGL and ImageBitmaps
On Thu, May 15, 2014 at 12:27 AM, Rik Cabanier caban...@gmail.com wrote: On Wed, May 14, 2014 at 7:45 PM, Glenn Maynard gl...@zewt.org wrote: Yes, color correction from sRGB to your monitor should not affect drawing on canvas. (What if you had multiple monitors :-)) This is a longstanding issue with 2D canvas that several developers have complained about over the years. The color space of the canvas backing store is currently unspecified. Blink/WebKit uses output-referred color space, which is bad for some inter-op cases, but good for performance. Calling drawImage will produce inter-operable behavior as far as visual output is concerned, but getImageData will yield values that have the display color profile baked in. Some web developers have worked around this by reverse-engineering the client-specific canvas to sRGB colorspace transform by running a test pattern through drawImage+getImageData. It is horrible that we are making devs resort to this. Adding a colorspace option to createImageBitmap is not enough IMHO. I think we need a more global color-management approach for canvas. I commented on https://www.w3.org/Bugs/Public/show_bug.cgi?id=25643
Re: [whatwg] [Notifications] Persistent notifications depending on Service Workers
On Fri, May 16, 2014 at 4:02 PM, Peter Beverloo bever...@google.com wrote: On Fri, May 16, 2014 at 2:57 PM, Anne van Kesteren ann...@annevk.nl wrote: Service worker integration makes sense to me. I guess I'll wait with updating the Notifications API until that is further along. Do you have a specific milestone in mind? Probably once it exposes a stable hook for does the current global have an associated service worker. And if I am to define the service worker events I suppose some more hooks are needed. Having service workers in two implementations would also help, as at that point the stability is a lot less uncertain. -- http://annevankesteren.nl/
Re: [whatwg] WebGL and ImageBitmaps
On Fri, 16 May 2014, Justin Novosad wrote: This is a longstanding issue with 2D canvas that several developers have complained about over the years. The color space of the canvas backing store is currently unspecified. It's defined that the colour space must be the same as used for CSS and img, but yeah the final colour space is left up to the UA: http://whatwg.org/html#color-spaces-and-color-correction Blink/WebKit uses output-referred color space, which is bad for some inter-op cases, but good for performance. Calling drawImage will produce inter-operable behavior as far as visual output is concerned, but getImageData will yield values that have the display color profile baked in. I'm not quite sure what you mean here. If you mean that you can set 'fillStyle' to a colour, fillRect the canvas, and the get the data for that pixel and find that it's a different colour, then that's non-conforming. If you mean that you can take a bitmap image without colour-profile information and draw it on a canvas and then getImageData() will return different results, then again, that's non-conforming. If you mean that drawing an image with a color profile will result in getImageData() returning different colour pixels on different systems, then that's allowed, because the colour space of the canvas (and the rest of the Web platform, which must be the same colour space) is not defined. Some web developers have worked around this by reverse-engineering the client-specific canvas to sRGB colorspace transform by running a test pattern through drawImage+getImageData. It is horrible that we are making devs resort to this. I'm not really sure what this work around achieves. Can you elaborate? If you just want to do everything in sRGB, then putting all your images in sRGB but without giving color space information (or setting the option to 'strip', if we add these createImageBitmap() options) would result in what you want, no? You'd have to manually (or on the server) convert images that were in other colour spaces, though. Adding a colorspace option to createImageBitmap is not enough IMHO. I think we need a more global color-management approach for canvas. If we need colour management, we need it for the Web as a whole, not just for canvas. So far, though, implementations have not been implementing the features that have been proposed, so...: http://www.w3.org/TR/css3-color/#dropped -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] ImageBitmap feature requests
On Fri, May 9, 2014 at 5:51 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 18 Jul 2013, Justin Novosad wrote: However, one weakness of the current API is that upon construction of the ImageBitmap, the browser does not know whether the asset will be used with a GPU-accelerated rendering context or not. If this information were available, the asset could be pre-cached on the GPU when appropriate. Maybe something like ctx.prefetch(image) would be appropriate for warming up the caches. Is this a measurable performance problem currently? I'd hate to provide such an API, which could easily be misunderstood or misused, only to find that in practice things already work ok. Agreed. A slower first draw is often tolerable. And the performance hit of a GPU texture upload is usually quite small relative to decode, disk cache access and network access. On Fri, 19 Jul 2013, Justin Novosad wrote: A related issue we have now is with canvas backing stores. It is common for web apps to create temporary canvases to do some offscreen rendering. When the temporary canvas goes out of scope, it continues to consume RAM or GPU memory until it is garbage collected. Occasionally this results in memory-leak-like symptoms. The usual workaround is to use a single persistent global canvas for offscreen work instead of temporary ones (yuck). This could be handled in a cleaner way if there were a .discard() method on canvases elements too. Would setting the canvas dimensions to zero have the same effect? Absolutely. And I have given that tip to devs many times. It is just that finding that trick is non-obvious to a dev who is unaware of how the browser is implemented internally, which is usually the case. We could have a method that just sets the dimensions to zero, if so, and if this is common enough to warrant a convenience method. Yes. A dispose() would feel less hacky and developers would find it more easily. 5) Once a large image is decoded and downsampled into a smaller ImageBitmap, the only thing that we can do with that ImageBitmap is to copy it into a Canvas, either for display to the end user (as an alternative to an img) or for re-encoding with Canvas.toBlob() (when creating thumbnails for large images). The motivation for this downsampling feature is memory use. But having to copy an ImageBitmap into a canvas in order to use it immediately doubles the amount of memory required. So for this reason, I also want to propose that ImageBitmap have a transferToCanvas() method akin to the transferToImageBitmap() and transferToImage() methods proposed at http://wiki.whatwg.org/wiki/WorkerCanvas. transferToCanvas would transfer the image data into a new Canvas object and would neuter the ImageBitmap so that it could no longer be used. This is an interesting idea. I don't know what the state of the other methods discussed here is (see my comment at the top of the e-mail cited above). However, I've filed a bug for this too: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25647 I think what might make the most sense here is to have a way to destructively convert an ImageBitmap into an img, rather than doing anything with a canvas. What would go in the 'src' attribute of the image element? A a data URL? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebGL and ImageBitmaps
On Fri, May 16, 2014 at 9:27 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 16 May 2014, Justin Novosad wrote: This is a longstanding issue with 2D canvas that several developers have complained about over the years. The color space of the canvas backing store is currently unspecified. It's defined that the colour space must be the same as used for CSS and img, but yeah the final colour space is left up to the UA: http://whatwg.org/html#color-spaces-and-color-correction Blink/WebKit uses output-referred color space, which is bad for some inter-op cases, but good for performance. Calling drawImage will produce inter-operable behavior as far as visual output is concerned, but getImageData will yield values that have the display color profile baked in. I'm not quite sure what you mean here. If you mean that you can set 'fillStyle' to a colour, fillRect the canvas, and the get the data for that pixel and find that it's a different colour, then that's non-conforming. If you mean that you can take a bitmap image without colour-profile information and draw it on a canvas and then getImageData() will return different results, then again, that's non-conforming. If you mean that drawing an image with a color profile will result in getImageData() returning different colour pixels on different systems, then that's allowed, because the colour space of the canvas (and the rest of the Web platform, which must be the same colour space) is not defined. Some web developers have worked around this by reverse-engineering the client-specific canvas to sRGB colorspace transform by running a test pattern through drawImage+getImageData. It is horrible that we are making devs resort to this. I'm not really sure what this work around achieves. Can you elaborate? If you just want to do everything in sRGB, then putting all your images in sRGB but without giving color space information (or setting the option to 'strip', if we add these createImageBitmap() options) would result in what you want, no? You'd have to manually (or on the server) convert images that were in other colour spaces, though. Adding a colorspace option to createImageBitmap is not enough IMHO. I think we need a more global color-management approach for canvas. If we need colour management, we need it for the Web as a whole, not just for canvas. So far, though, implementations have not been implementing the features that have been proposed, so...: http://www.w3.org/TR/css3-color/#dropped Recently there has been activity in some implementations to finally solve the color management problem. I can't speak for Safari, but have heard that as of Mac OS X 10.9, that implementation is rendering web pages into the sRGB color space per the CSS spec, and converting to the display's color profile on the way to the screen. I was told that there was a concern there would be a compatibility impact with web apps implicitly expecting to work in the display's color space, but surprisingly, everything seemed to work during this transition. In Chrome there is also work ongoing to handle multiple monitors with different display color profiles. Noel Gordon (CC'd) is driving this and the list of active issues can be seen at https://code.google.com/p/chromium/issues/list?q=owner%3Anoel%40chromium.org . It's likely the implementation will be done in stages: first rendering images correctly when dragging windows from monitor to monitor, and then rendering all web page content correctly. In sum, while it has taken a while for implementations to finally start tackling the color management problem, it's happening now. -Ken
Re: [whatwg] WebGL and ImageBitmaps
On Fri, May 16, 2014 at 12:27 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 16 May 2014, Justin Novosad wrote Blink/WebKit uses output-referred color space, which is bad for some inter-op cases, but good for performance. Calling drawImage will produce inter-operable behavior as far as visual output is concerned, but getImageData will yield values that have the display color profile baked in. I'm not quite sure what you mean here. If you mean that you can set 'fillStyle' to a colour, fillRect the canvas, and the get the data for that pixel and find that it's a different colour, then that's non-conforming. If you mean that you can take a bitmap image without colour-profile information and draw it on a canvas and then getImageData() will return different results, then again, that's non-conforming. If you mean that drawing an image with a color profile will result in getImageData() returning different colour pixels on different systems, then that's allowed, because the colour space of the canvas (and the rest of the Web platform, which must be the same colour space) is not defined. Yes the later is what I mean. It is allowed, and it is causing headaches for many web developers. One possible solution would be to impose that ImageData be in sRGB color space. Unfortunately, that would imply loss of precision due to color space conversion rounding errors in a getImageData/putImageData round trip. But that is probably a lesser evil. I wonder if making this change would break anything on the web... Some web developers have worked around this by reverse-engineering the client-specific canvas to sRGB colorspace transform by running a test pattern through drawImage+getImageData. It is horrible that we are making devs resort to this. I'm not really sure what this work around achieves. Can you elaborate? For example, if a web app wants to apply an image processing algorithm, it would use getImageData to retrieve the original pixel values, process the data, and display the results using putImageData. The color space of the image data is undefined and it affects the behavior of the image processing algorithm. In order to standardize the behavior of the image processing algorithm, the image data must be converted to a known color space. The required color space transformation can not be queried but it can be determined experimentally by taking an img that is in a known color space and contains known color values. You draw that image to a canvas using drawImage, and read it back using getImageData. The color values returned by getImageData and the known corresponding color values of the original image provide a set of color-space correspondences that can be used to feed a curve fitting algorithm in order to reverse-engineer the parameters of the color space conversion that maps the unknown ImageData color space to the known color space of the test image. If you just want to do everything in sRGB, then putting all your images in sRGB but without giving color space information (or setting the option to 'strip', if we add these createImageBitmap() options) would result in what you want, no? Only if the canvas backing store is forced to be in sRGB. You'd have to manually (or on the server) convert images that were in other colour spaces, though. Adding a colorspace option to createImageBitmap is not enough IMHO. I think we need a more global color-management approach for canvas. If we need colour management, we need it for the Web as a whole, not just for canvas. So far, though, implementations have not been implementing the features that have been proposed, so...: http://www.w3.org/TR/css3-color/#dropped I think think CSS and HTML can survive well without color management features, as long as the color behavior is well defined, which seems to be the case except for canvas ImageData is problematic because it stores data that in an undefined color space. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] type=month-day
On Mon, 17 Mar 2014, Anne van Kesteren wrote: As a heads up, Mozilla is considering an experimental implementation of month-day (mobile only so far) for entering birthdays and such: https://bugzilla.mozilla.org/show_bug.cgi?id=974341 However, it might be even better for birthdays if the year part became optional rather than always omitted. Original motivation is here http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027725.html by Tantek Çelik. Relatedly, there was a suggestion filed on the spec once to introduce an input type that allowed users to enter date/time data where they could fill in either , -MM, -MM-DD, etc: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15114 This is not quite the same, but worth considering as well. I've filed this bug to track the spec side of MM-DD: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25742 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebGL and ImageBitmaps
On Fri, May 16, 2014 at 12:16 PM, Justin Novosad ju...@google.com wrote: On Fri, May 16, 2014 at 12:27 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 16 May 2014, Justin Novosad wrote Blink/WebKit uses output-referred color space, which is bad for some inter-op cases, but good for performance. Calling drawImage will produce inter-operable behavior as far as visual output is concerned, but getImageData will yield values that have the display color profile baked in. I'm not quite sure what you mean here. If you mean that you can set 'fillStyle' to a colour, fillRect the canvas, and the get the data for that pixel and find that it's a different colour, then that's non-conforming. If you mean that you can take a bitmap image without colour-profile information and draw it on a canvas and then getImageData() will return different results, then again, that's non-conforming. If you mean that drawing an image with a color profile will result in getImageData() returning different colour pixels on different systems, then that's allowed, because the colour space of the canvas (and the rest of the Web platform, which must be the same colour space) is not defined. Yes the later is what I mean. It is allowed, and it is causing headaches for many web developers. One possible solution would be to impose that ImageData be in sRGB color space. Unfortunately, that would imply loss of precision due to color space conversion rounding errors in a getImageData/putImageData round trip. Can you explain why that is? Presumably, the image data is converted to sRGB before you use it to composite its pixels. But that is probably a lesser evil. I wonder if making this change would break anything on the web... Some web developers have worked around this by reverse-engineering the client-specific canvas to sRGB colorspace transform by running a test pattern through drawImage+getImageData. It is horrible that we are making devs resort to this. I'm not really sure what this work around achieves. Can you elaborate? For example, if a web app wants to apply an image processing algorithm, it would use getImageData to retrieve the original pixel values, process the data, and display the results using putImageData. The color space of the image data is undefined and it affects the behavior of the image processing algorithm. In order to standardize the behavior of the image processing algorithm, the image data must be converted to a known color space. The required color space transformation can not be queried but it can be determined experimentally by taking an img that is in a known color space and contains known color values. You draw that image to a canvas using drawImage, and read it back using getImageData. The color values returned by getImageData and the known corresponding color values of the original image provide a set of color-space correspondences that can be used to feed a curve fitting algorithm in order to reverse-engineer the parameters of the color space conversion that maps the unknown ImageData color space to the known color space of the test image. I agree. That is horrible! If you just want to do everything in sRGB, then putting all your images in sRGB but without giving color space information (or setting the option to 'strip', if we add these createImageBitmap() options) would result in what you want, no? Only if the canvas backing store is forced to be in sRGB. Is the Web page not composited in sRGB? If so, it seems the backing store should be sRGB too. You'd have to manually (or on the server) convert images that were in other colour spaces, though. Adding a colorspace option to createImageBitmap is not enough IMHO. I think we need a more global color-management approach for canvas. If we need colour management, we need it for the Web as a whole, not just for canvas. So far, though, implementations have not been implementing the features that have been proposed, so...: http://www.w3.org/TR/css3-color/#dropped I think think CSS and HTML can survive well without color management features, as long as the color behavior is well defined, which seems to be the case except for canvas ImageData is problematic because it stores data that in an undefined color space. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebGL and ImageBitmaps
On Fri, May 16, 2014 at 5:42 PM, Rik Cabanier caban...@gmail.com wrote: Is the Web page not composited in sRGB? If so, it seems the backing store should be sRGB too. The web page is not composited in sRGB. It is composited in the output device's color space, which is often sRGB or close to sRGB, but not always. A notable significant exception is pre Snow Leopard Macs that use a gamma 1.8 transfer curve. By the way, sniffing the display color profile through getImageData is a known fingerprinting technique. This factor alone can be sufficient to fingerprint a user who has a calibrated monitor.
Re: [whatwg] Various autocomplete= topics
On Mon, May 5, 2014 at 10:38 PM, Matthew Noorenberghe mattn+wha...@mozilla.com wrote: On Fri, Apr 11, 2014 at 3:36 PM, Edward O'Connor eocon...@apple.com wrote: I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. In Firefox, we save the form values after validation but before the submit event is dispatched to content. This way we successfully save the form fields in form history when a script is handling the actual submission. This also helps against sites who try to manipulate the form fields upon submission to avoid having them saved (see https://bugzilla.mozilla.org/show_bug.cgi?id=257781 ). We've been doing this for a long time and I don't recall any complaints as long as I've been working on password and form manager for Firefox (since 2009). There are many websites that use click handlers on buttons outside forms instead of using form submission and those fields don't get saved in Firefox. I suspect web developers don't realize that they are losing out on form history and other benefits like being able to submit the form with the Enter key from a text input. I don't see sites that are not having their fields saved by not using form submission switching to calling a new API when they can instead use an onsubmit handler which has other benefits. Given that Firefox already saves values with preventDefault inside form submit handlers and click handlers on submit buttons, and the other benefits of sites using form submission, I don't think a new API is needed. The problem right now is that there are two legitimate reasons that a site may return false from the submit handler, either because the submission failed validation in some way or because submission is being handled via script. Browsers can either ignore this distinction (e.g. Firefox) or try and separate the two heuristically (e.g. Chrome). Both are reasonable approaches given the current state of the world, but neither are ideal. We should allow sites to make this distinction. I agree that we shouldn't necessarily add contortions for sites that don't use form submission, but currently there isn't a right way to do this even if the site wants to. For the pure JS case, an API (probably on the form itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 This case is pretty weird. Authors are going out of their way to avoid using the built in platform features that would get them autofill saving for free. In some cases, they might be doing this precisely because they want to prevent autofill but can't count on autocomplete=off anymore. It seems like more evangelism is needed to let authors know that preventDefault inside a form submission handler is the better way to handle forms where navigation isn't wanted. The benefits are: form history, password management, better UX (allowing submission via Enter when inputs are in a form), and possibly better accessibility(?). I've been thinking about cases where we could detect the pattern of fake forms (using text inputs and buttons with click handlers together without a form) and provide notices in developer tools to help evangelize but it's looking to be tricky. -- Matthew Noorenberghe
Re: [whatwg] WebGL and ImageBitmaps
On Fri, May 16, 2014 at 3:06 PM, Justin Novosad ju...@google.com wrote: On Fri, May 16, 2014 at 5:42 PM, Rik Cabanier caban...@gmail.com wrote: Is the Web page not composited in sRGB? If so, it seems the backing store should be sRGB too. The web page is not composited in sRGB. It is composited in the output device's color space, which is often sRGB or close to sRGB, but not always. A notable significant exception is pre Snow Leopard Macs that use a gamma 1.8 transfer curve. By the way, sniffing the display color profile through getImageData is a known fingerprinting technique. This factor alone can be sufficient to fingerprint a user who has a calibrated monitor. I'm unable to reproduce what you're describing. So, if I fill with a color and repeatedly do a getImageData/putImageData, should I see color shifts?
