Re: [whatwg] HTTP status code from JavaScript
On 2014-05-23 06:53, Michael Heuberger wrote: Hi James Single page apps! These become more and more popular with frameworks like RactiveJS or AngularJS. There the first request is a HTTP request, for any subsequent requests an AJAX one is generated. The problem is the first HTTP AJAX requests are HTTP requests. I assume you mean the distinction between page navigation and using XMLHTTPRequest? request. The framework is unable to detect 404s with the first request because the status code cannot be obtained via JavaScript, hence a second request is made. If the initial page load yields a 404 will there be any scripts to execute at all? In my eyes, a waste of bandwidth. Cheers Michael Best regards, Julian
Re: [whatwg] HTTP status code from JavaScript
Hi Julian Yes, with AJAX requests I meant using XMLHTTPRequest. If the initial page load yields a 404 will there be any scripts to execute at all? Oh yes, absolutely. Have you ever written a single page app? There is lots of logic to execute when a 404 occurs. I could count plenty of use cases and functions that make sense. Here some examples: - Notify the administrator about a 404 by email with a response back to the server - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more ... All these above examples run on JavaScript. Because there is currently no way for JavaScript to determine if the page load yielded a 404, a subsequent request, namely a XMLHTTPRequest one is often added. In my professional opinion a bad solution. Again, I strongly believe that this would be a huge improvement and avoids unnecessary network traffic. Cheers Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
- Notify the administrator about a 404 by email with a response back to the server But the server already knows about the 404, JS shouldn’t be needed/used to re-inform the server of the status it’s already sent. - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more … I agree with those entirely but couldn’t they also be achieved by including the correct scripts on the 404 page issued from the server? (I’m not against the original suggestion, I just don’t think these particular use-cases demand a new feature) Mat Carey 07952258096 On 23 May 2014, at 07:52, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hi Julian Yes, with AJAX requests I meant using XMLHTTPRequest. If the initial page load yields a 404 will there be any scripts to execute at all? Oh yes, absolutely. Have you ever written a single page app? There is lots of logic to execute when a 404 occurs. I could count plenty of use cases and functions that make sense. Here some examples: - Notify the administrator about a 404 by email with a response back to the server - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more ... All these above examples run on JavaScript. Because there is currently no way for JavaScript to determine if the page load yielded a 404, a subsequent request, namely a XMLHTTPRequest one is often added. In my professional opinion a bad solution. Again, I strongly believe that this would be a huge improvement and avoids unnecessary network traffic. Cheers Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
Good points Mat In theory you have good points but in the real world it is more complicated than that. See my comments below: On 23/05/14 19:49, Mat Carey wrote: - Notify the administrator about a 404 by email with a response back to the server But the server already knows about the 404, JS shouldn’t be needed/used to re-inform the server of the status it’s already sent. Nowadays you can access other entities directly, i.E. a RIAK Database server which returns a 404 if the ID in the query does not exist which can be a raw HTTP request. This without any app logic in-between. ... or you have a cloud with multiple servers but only one of them is responsible for error reporting. It is just an example. I could count more use cases where the feature is really needed. - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more … I agree with those entirely but couldn’t they also be achieved by including the correct scripts on the 404 page issued from the server? No, it is a single page app. All the HTML templates are on the client side and loaded once during page load. And everything happens dynamically. In other words: You load everything once, then there is no further interaction with the server unless it's a specific query for data or alters data in the database. Furthermore you can convert a whole single page app into an iPhone app with PhoneGap. All the HTML resides in the app, not on the server. That's a very different approach and a good reason why JavaScript has the right to know if the HTTP request resulted into a 200 or a 404. Cheers Michael (I’m not against the original suggestion, I just don’t think these particular use-cases demand a new feature) Mat Carey 07952258096 On 23 May 2014, at 07:52, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hi Julian Yes, with AJAX requests I meant using XMLHTTPRequest. If the initial page load yields a 404 will there be any scripts to execute at all? Oh yes, absolutely. Have you ever written a single page app? There is lots of logic to execute when a 404 occurs. I could count plenty of use cases and functions that make sense. Here some examples: - Notify the administrator about a 404 by email with a response back to the server - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more ... All these above examples run on JavaScript. Because there is currently no way for JavaScript to determine if the page load yielded a 404, a subsequent request, namely a XMLHTTPRequest one is often added. In my professional opinion a bad solution. Again, I strongly believe that this would be a huge improvement and avoids unnecessary network traffic. Cheers Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] HTTP status code from JavaScript
I had to deal with this on a script created IMG element the other day. I used onerror to deal with it. For xmlhttprequest you can use the status field. Why is that not enough? Silvia. On 23 May 2014 18:06, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Good points Mat In theory you have good points but in the real world it is more complicated than that. See my comments below: On 23/05/14 19:49, Mat Carey wrote: - Notify the administrator about a 404 by email with a response back to the server But the server already knows about the 404, JS shouldn’t be needed/used to re-inform the server of the status it’s already sent. Nowadays you can access other entities directly, i.E. a RIAK Database server which returns a 404 if the ID in the query does not exist which can be a raw HTTP request. This without any app logic in-between. ... or you have a cloud with multiple servers but only one of them is responsible for error reporting. It is just an example. I could count more use cases where the feature is really needed. - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more … I agree with those entirely but couldn’t they also be achieved by including the correct scripts on the 404 page issued from the server? No, it is a single page app. All the HTML templates are on the client side and loaded once during page load. And everything happens dynamically. In other words: You load everything once, then there is no further interaction with the server unless it's a specific query for data or alters data in the database. Furthermore you can convert a whole single page app into an iPhone app with PhoneGap. All the HTML resides in the app, not on the server. That's a very different approach and a good reason why JavaScript has the right to know if the HTTP request resulted into a 200 or a 404. Cheers Michael (I’m not against the original suggestion, I just don’t think these particular use-cases demand a new feature) Mat Carey 07952258096 On 23 May 2014, at 07:52, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hi Julian Yes, with AJAX requests I meant using XMLHTTPRequest. If the initial page load yields a 404 will there be any scripts to execute at all? Oh yes, absolutely. Have you ever written a single page app? There is lots of logic to execute when a 404 occurs. I could count plenty of use cases and functions that make sense. Here some examples: - Notify the administrator about a 404 by email with a response back to the server - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more ... All these above examples run on JavaScript. Because there is currently no way for JavaScript to determine if the page load yielded a 404, a subsequent request, namely a XMLHTTPRequest one is often added. In my professional opinion a bad solution. Again, I strongly believe that this would be a huge improvement and avoids unnecessary network traffic. Cheers Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] Canvas and color colorspaces (was: WebGL and ImageBitmaps)
On Thu, May 22, 2014 at 4:09 PM, Rik Cabanier caban...@gmail.com wrote: Well, the issue with not having a standardized intermediate colorspace, is that output will look different on different devices. I theory, that should only be the case when drawing raw values through putImageData. Everything else (fill styles, stroke styles, images) could be color-managed and mapped from CSS (sRGB) to the canvas's color space when drawing to a canvas. Right now, this is not the case in Chrome, which is a bug. IMHO. For most cases, people don't really care about that and are happy will vibrant colors and deep blacks. Worse, if you limit the gamut to sRGB on wide gamut devices, you lose gray values which will result in banding (unless you have a high bit monitor) [1] However there are use cases where it is certainly important that what you see on screen reflects the actual color. I've certainly try to order clothes, paint and furniture online where I did care about the exact color. There's currently no way to accomplish this. It may seem that a proper color managed pipeline may solve that problem, but it will not. we cannot solve the problem completely through web standards for many reasons: * Most people do not have calibrated monitors, or have only coarsely calibrated monitors. * A textile or paint sample viewed on screen will have been photographed or rendered under illumination conditions that are most likely very different from the lighting where the output device is located, making it almost impossible to match colors even with perfectly calibrated devices. * There is inter-human variability in color perception. The primary colors we use were chosen based on the average human's perception of color. Even with perfectly matched illumination conditions and calibrated devices, many humans will perceive noticeable differences because the models used to represent colors in computers is not a perfect match for each individual. In particular tetrachromats and certain types of color blinds have color responses that poorly match standard primary colors. The best we can do is minimize differences caused by inter-device variability. How well we can do that depends on how well the devices are calibrated. Rik: to answer your question about your experiment: there is no issue with a put/getImageData round trip. You will get back the same color you put in (at least for opaque colors, but that is another story). The issue is with a drawImage/getImageData round trip. For the same source image, getImageData will return different values depending on the display profile of the system you are running on. I still am not able to reproduce: http://jsfiddle.net/Dghuh/14/ Is it just when you have a tagged image that is drawn and is then color mapped to the device profile? Yes exactly, you will only see the problem with a tagged image. When drawing from a canvas to a canvas, there are no color space conversions in play. Similarly, there are no color space conversion at play in a getImageData+putImageData round trip.
Re: [whatwg] HTTP status code from JavaScript
I think he wants to be able to serve the exact same single page no matter what the status code is (i.e. including `404`s) and then be able to react to the initial page status code on the client-side. A bit of an edge case as most people serve different pages with HTTP errors but it is a logical use case. Sincerely, James Greene On Fri, May 23, 2014 at 3:33 AM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: I had to deal with this on a script created IMG element the other day. I used onerror to deal with it. For xmlhttprequest you can use the status field. Why is that not enough? Silvia. On 23 May 2014 18:06, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Good points Mat In theory you have good points but in the real world it is more complicated than that. See my comments below: On 23/05/14 19:49, Mat Carey wrote: - Notify the administrator about a 404 by email with a response back to the server But the server already knows about the 404, JS shouldn’t be needed/used to re-inform the server of the status it’s already sent. Nowadays you can access other entities directly, i.E. a RIAK Database server which returns a 404 if the ID in the query does not exist which can be a raw HTTP request. This without any app logic in-between. ... or you have a cloud with multiple servers but only one of them is responsible for error reporting. It is just an example. I could count more use cases where the feature is really needed. - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more … I agree with those entirely but couldn’t they also be achieved by including the correct scripts on the 404 page issued from the server? No, it is a single page app. All the HTML templates are on the client side and loaded once during page load. And everything happens dynamically. In other words: You load everything once, then there is no further interaction with the server unless it's a specific query for data or alters data in the database. Furthermore you can convert a whole single page app into an iPhone app with PhoneGap. All the HTML resides in the app, not on the server. That's a very different approach and a good reason why JavaScript has the right to know if the HTTP request resulted into a 200 or a 404. Cheers Michael (I’m not against the original suggestion, I just don’t think these particular use-cases demand a new feature) Mat Carey 07952258096 On 23 May 2014, at 07:52, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hi Julian Yes, with AJAX requests I meant using XMLHTTPRequest. If the initial page load yields a 404 will there be any scripts to execute at all? Oh yes, absolutely. Have you ever written a single page app? There is lots of logic to execute when a 404 occurs. I could count plenty of use cases and functions that make sense. Here some examples: - Notify the administrator about a 404 by email with a response back to the server - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more ... All these above examples run on JavaScript. Because there is currently no way for JavaScript to determine if the page load yielded a 404, a subsequent request, namely a XMLHTTPRequest one is often added. In my professional opinion a bad solution. Again, I strongly believe that this would be a huge improvement and avoids unnecessary network traffic. Cheers Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
[whatwg] BroadcastChannel memory leak
When is it safe for a user agent to garbage collect a BroadcastChannel instance? http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts Given that another document might create a new BroadcastChannel instance at any time, the |message| event of the object might fire any time its responsible document is fully active. For web application that have long-lived documents, the BroadcastChannel might not be eligible for garbage collection for a long time. Proposal: Add a |close| method to the BroadcastChannel interface similar to the |close| method on MessagePort. The |close| method would just neuter the instance of the channel and prevent it from receiving further messages. Adam
Re: [whatwg] BroadcastChannel memory leak
When is it safe for a user agent to garbage collect a BroadcastChannel instance? When there's no direct reference to the object and no onmessage handler attached to it. (?) On Fri, May 23, 2014 at 5:23 PM, Adam Barth w...@adambarth.com wrote: When is it safe for a user agent to garbage collect a BroadcastChannel instance? http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts Given that another document might create a new BroadcastChannel instance at any time, the |message| event of the object might fire any time its responsible document is fully active. For web application that have long-lived documents, the BroadcastChannel might not be eligible for garbage collection for a long time. Proposal: Add a |close| method to the BroadcastChannel interface similar to the |close| method on MessagePort. The |close| method would just neuter the instance of the channel and prevent it from receiving further messages. Adam
Re: [whatwg] BroadcastChannel memory leak
On Fri, May 23, 2014 at 5:54 PM, Michael Nordman micha...@google.com wrote: When is it safe for a user agent to garbage collect a BroadcastChannel instance? When there's no direct reference to the object and no onmessage handler attached to it. (?) That doesn't play nicely with anonymous JavaScript functions that can't ever be removed as event listeners... Adam On Fri, May 23, 2014 at 5:23 PM, Adam Barth w...@adambarth.com wrote: When is it safe for a user agent to garbage collect a BroadcastChannel instance? http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts Given that another document might create a new BroadcastChannel instance at any time, the |message| event of the object might fire any time its responsible document is fully active. For web application that have long-lived documents, the BroadcastChannel might not be eligible for garbage collection for a long time. Proposal: Add a |close| method to the BroadcastChannel interface similar to the |close| method on MessagePort. The |close| method would just neuter the instance of the channel and prevent it from receiving further messages. Adam
Re: [whatwg] HTTP status code from JavaScript
Hi Silvia Yes, I know this trick but in my opinion it's a waste of bandwidth (a small one I know but multiply this with thousands of calls worldwide every hour ...) If we could obtain the status code from the first, raw HTTP request, then there is no need for this IMG trick anymore. Michael On 23/05/14 20:33, Silvia Pfeiffer wrote: I had to deal with this on a script created IMG element the other day. I used onerror to deal with it. For xmlhttprequest you can use the status field. Why is that not enough? Silvia. On 23 May 2014 18:06, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Good points Mat In theory you have good points but in the real world it is more complicated than that. See my comments below: On 23/05/14 19:49, Mat Carey wrote: - Notify the administrator about a 404 by email with a response back to the server But the server already knows about the 404, JS shouldn’t be needed/used to re-inform the server of the status it’s already sent. Nowadays you can access other entities directly, i.E. a RIAK Database server which returns a 404 if the ID in the query does not exist which can be a raw HTTP request. This without any app logic in-between. ... or you have a cloud with multiple servers but only one of them is responsible for error reporting. It is just an example. I could count more use cases where the feature is really needed. - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more … I agree with those entirely but couldn’t they also be achieved by including the correct scripts on the 404 page issued from the server? No, it is a single page app. All the HTML templates are on the client side and loaded once during page load. And everything happens dynamically. In other words: You load everything once, then there is no further interaction with the server unless it's a specific query for data or alters data in the database. Furthermore you can convert a whole single page app into an iPhone app with PhoneGap. All the HTML resides in the app, not on the server. That's a very different approach and a good reason why JavaScript has the right to know if the HTTP request resulted into a 200 or a 404. Cheers Michael (I’m not against the original suggestion, I just don’t think these particular use-cases demand a new feature) Mat Carey 07952258096 On 23 May 2014, at 07:52, Michael Heuberger michael.heuber...@binarykitchen.com wrote: Hi Julian Yes, with AJAX requests I meant using XMLHTTPRequest. If the initial page load yields a 404 will there be any scripts to execute at all? Oh yes, absolutely. Have you ever written a single page app? There is lots of logic to execute when a 404 occurs. I could count plenty of use cases and functions that make sense. Here some examples: - Notify the administrator about a 404 by email with a response back to the server - Display a beautiful 404 page and hide parts of the navigation - Reveal navigation history to give users a better usability experience during 404s - And many more ... All these above examples run on JavaScript. Because there is currently no way for JavaScript to determine if the page load yielded a 404, a subsequent request, namely a XMLHTTPRequest one is often added. In my professional opinion a bad solution. Again, I strongly believe that this would be a huge improvement and avoids unnecessary network traffic. Cheers Michael -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com -- Binary Kitchen Michael Heuberger 4c Dunbar Road Mt Eden Auckland 1024 (New Zealand) Mobile (text only) ... +64 21 261 89 81 Email mich...@binarykitchen.com Website .. http://www.binarykitchen.com
Re: [whatwg] BroadcastChannel memory leak
On Fri, May 23, 2014 at 5:23 PM, Adam Barth w...@adambarth.com wrote: When is it safe for a user agent to garbage collect a BroadcastChannel instance? http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts Given that another document might create a new BroadcastChannel instance at any time, the |message| event of the object might fire any time its responsible document is fully active. For web application that have long-lived documents, the BroadcastChannel might not be eligible for garbage collection for a long time. Proposal: Add a |close| method to the BroadcastChannel interface similar to the |close| method on MessagePort. The |close| method would just neuter the instance of the channel and prevent it from receiving further messages. Sounds good to me. / Jonas
