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
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 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 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. In my eyes, a waste of bandwidth. Cheers Michael On 23/05/14 16:39, James Greene wrote: > I'm not opposed to this idea but... what Is a realistic use case for this? > > Sincerely, > James Greene > > > > On Thu, May 22, 2014 at 10:36 PM, Michael Heuberger < > michael.heuber...@binarykitchen.com> wrote: > >> Hello WhatWG >> >> There is a need to obtain the HTTP status code for the page itself from >> JavaScript: >> https://bugzilla.mozilla.org/show_bug.cgi?id=999886 >> >> I think this would be a great feature to save additional traffic in an >> already congested internet. Because I see lots of queries made by >> XMLHttpRequest solely to obtain the HTTP status code of the same URL. >> >> If the global browser variable (JavaScript) would already hold the >> status code, then these queries would become obsolete and the internet >> becomes a bit less blocked. >> >> Let me know how to proceed with my proposal within WhatWG. >> >> Greetings from Auckland, >> 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'm not opposed to this idea but... what Is a realistic use case for this? Sincerely, James Greene On Thu, May 22, 2014 at 10:36 PM, Michael Heuberger < michael.heuber...@binarykitchen.com> wrote: > Hello WhatWG > > There is a need to obtain the HTTP status code for the page itself from > JavaScript: > https://bugzilla.mozilla.org/show_bug.cgi?id=999886 > > I think this would be a great feature to save additional traffic in an > already congested internet. Because I see lots of queries made by > XMLHttpRequest solely to obtain the HTTP status code of the same URL. > > If the global browser variable (JavaScript) would already hold the > status code, then these queries would become obsolete and the internet > becomes a bit less blocked. > > Let me know how to proceed with my proposal within WhatWG. > > Greetings from Auckland, > 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 > >
[whatwg] HTTP status code from JavaScript
Hello WhatWG There is a need to obtain the HTTP status code for the page itself from JavaScript: https://bugzilla.mozilla.org/show_bug.cgi?id=999886 I think this would be a great feature to save additional traffic in an already congested internet. Because I see lots of queries made by XMLHttpRequest solely to obtain the HTTP status code of the same URL. If the global browser variable (JavaScript) would already hold the status code, then these queries would become obsolete and the internet becomes a bit less blocked. Let me know how to proceed with my proposal within WhatWG. Greetings from Auckland, 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] Canvas and color colorspaces (was: WebGL and ImageBitmaps)
Hi justin, thanks for this explanation! On Thu, May 22, 2014 at 12:21 PM, Justin Novosad wrote: > tl;dr: The color space of canvas backing stores is undefined, which causes > problems for many web devs, but also has non-negligible advantages. So be > careful what you wish for. > > I saw some confusion and questions needing answers in the "WebGL and > ImageBitmaps" thread regarding color management. I will attempt to clarify > to the best of my abilities. Though I am knowledgeable on the subject, I am > not an absolute authority, so others are welcome to correct me if I am > wrong about anything. > > Color management... To make a long story short, there are two types of > color profiles : input profiles and output profiles for characterizing > input devices (cameras, scanners) and output devices (displays, printers) > respectively. > Image files will usually encode their color information in a standard > color space or in a an input device dependent space. If colors are encoded > in a color space that is different from the format's default, then a color > profile or a color space identifier must be encoded into the image > resource's metadata. > > To present color-managed image content on screen, the image needs to be > converted from whatever color space the image was encoded into into a > standard "connection space" using the color profile or color space metadata > from the image resource. Then the colors need to be converted from the > profile connection space to the output space, which is provided by the > OS/display driver. Depending on the OS and hardware configuration, the > output space may be a standard color space (like sRGB), or a > device-specific color profile. > > Currently, many color-managed software applications rely on the codec to > take care of the entire color-management process for image and video > content, meaning that the decoded image data is in output-referred color > space (i.e. the display's profile was applied). There are practical > reasons for this, the most important ones being color fidelity and memory > consumption. Let me explain. The profile connection space is typically CIE > XYZ or CIE L*a*b. I wont get into the technical details of how these work > except to say that they are device independent and allow for an accurate > representation of the whole spectrum of human-visible colors. This makes it > possible to map colors from a wide gamut camera to a wide gamut display > with high color fidelity for all the colors that are located in the > intersection of the color gamuts of both the input and output devices. If > we were forced to convert the image to an intermediate sRGB representation, > the colors in the image would be clamped to the sRGB gamut (which is > narrower than the gamuts of many devices). Currently, most browsers avoid > doing that for , and therefore provide (more or less) optimal image > and video color fidelity for users of wide gamut devices. Also, an > intermediate representation in 8-bit sRGB means loss of precision due to > rounding errors, as opposed to the profile connection space which uses > higher precision registers for intermediate color values to avoid precision > issues caused by rounding. To avoid perceptible precision issues in an > intermediate sRGB representation, we'd have to increase the bit depth and > therefore use more RAM for storing decoded image data. > > All of this is to say that there are good reasons for the current > situation where we deal with decoded images that have the output device's > color profile pre-applied: color fidelity and memory consumption. > > In the case of 2D canvas, the color space for the backing store is > unspecified, and many implementations have chosen to use the output > device's color space, which has many advantages: > * images and videos are already decoded directly into that space > * no color conversion is necessary when presenting the canvas on screen > (good for performance) > * there is no loss of precision due the use of a limited-precision > intermediate color space. > * the color gamut is not constrained by an intermediate color space (like > sRGB). > And disadvantages: > * Compositing operations produce incorrect results because most of them > (including source-over) are affected by the color space. > * direct pixel manipulation using put/getImageData exposes data in a color > space that is undefined, making it extremely challenging to perform many > types of image processing and image generation tasks in a > device-independent way. > * The device-dependent behavior of a drawImage/getImageData round trip is > a known fingerprinting vector. > > Right now, I am hearing a lot of complaints regarding the lack of a > standardized color space for canvases, and in particular the impact this > has on applications that try to do cool things with put/getImageData, or > generate images procedurally. I want to make sure everyone understands > there is a trade-off to fixing this, so be ca
[whatwg] Canvas and color colorspaces (was: WebGL and ImageBitmaps)
tl;dr: The color space of canvas backing stores is undefined, which causes problems for many web devs, but also has non-negligible advantages. So be careful what you wish for. I saw some confusion and questions needing answers in the "WebGL and ImageBitmaps" thread regarding color management. I will attempt to clarify to the best of my abilities. Though I am knowledgeable on the subject, I am not an absolute authority, so others are welcome to correct me if I am wrong about anything. Color management... To make a long story short, there are two types of color profiles : input profiles and output profiles for characterizing input devices (cameras, scanners) and output devices (displays, printers) respectively. Image files will usually encode their color information in a standard color space or in a an input device dependent space. If colors are encoded in a color space that is different from the format's default, then a color profile or a color space identifier must be encoded into the image resource's metadata. To present color-managed image content on screen, the image needs to be converted from whatever color space the image was encoded into into a standard "connection space" using the color profile or color space metadata from the image resource. Then the colors need to be converted from the profile connection space to the output space, which is provided by the OS/display driver. Depending on the OS and hardware configuration, the output space may be a standard color space (like sRGB), or a device-specific color profile. Currently, many color-managed software applications rely on the codec to take care of the entire color-management process for image and video content, meaning that the decoded image data is in output-referred color space (i.e. the display's profile was applied). There are practical reasons for this, the most important ones being color fidelity and memory consumption. Let me explain. The profile connection space is typically CIE XYZ or CIE L*a*b. I wont get into the technical details of how these work except to say that they are device independent and allow for an accurate representation of the whole spectrum of human-visible colors. This makes it possible to map colors from a wide gamut camera to a wide gamut display with high color fidelity for all the colors that are located in the intersection of the color gamuts of both the input and output devices. If we were forced to convert the image to an intermediate sRGB representation, the colors in the image would be clamped to the sRGB gamut (which is narrower than the gamuts of many devices). Currently, most browsers avoid doing that for , and therefore provide (more or less) optimal image and video color fidelity for users of wide gamut devices. Also, an intermediate representation in 8-bit sRGB means loss of precision due to rounding errors, as opposed to the profile connection space which uses higher precision registers for intermediate color values to avoid precision issues caused by rounding. To avoid perceptible precision issues in an intermediate sRGB representation, we'd have to increase the bit depth and therefore use more RAM for storing decoded image data. All of this is to say that there are good reasons for the current situation where we deal with decoded images that have the output device's color profile pre-applied: color fidelity and memory consumption. In the case of 2D canvas, the color space for the backing store is unspecified, and many implementations have chosen to use the output device's color space, which has many advantages: * images and videos are already decoded directly into that space * no color conversion is necessary when presenting the canvas on screen (good for performance) * there is no loss of precision due the use of a limited-precision intermediate color space. * the color gamut is not constrained by an intermediate color space (like sRGB). And disadvantages: * Compositing operations produce incorrect results because most of them (including source-over) are affected by the color space. * direct pixel manipulation using put/getImageData exposes data in a color space that is undefined, making it extremely challenging to perform many types of image processing and image generation tasks in a device-independent way. * The device-dependent behavior of a drawImage/getImageData round trip is a known fingerprinting vector. Right now, I am hearing a lot of complaints regarding the lack of a standardized color space for canvases, and in particular the impact this has on applications that try to do cool things with put/getImageData, or generate images procedurally. I want to make sure everyone understands there is a trade-off to fixing this, so be careful what you wish for. I am especially concerned about the issue of color gamut clamping, which will increase in relevance as wide gamut devices become more widespread. If we were to decide that canvas backing stores had to be in sRGB, that would mean th
Re: [whatwg] @autocomplete sections
On Tue, 13 May 2014, Matthew Noorenberghe wrote: > > While looking at implementing the new autocomplete attribute syntax, I > was wondering about the driver for section-* tokens. The example in the > spec[1] with multiple shipping addresses for one checkout isn't > something I've seen done in the wild in one flow. In the example, how > did the website know that the two items should be in different sections > in the first place? > [1] > http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete Presumably the site asked who the items were for in an earlier flow. For example, when purchasing flowers online it's common for sites to let you pick the recipient of the flower when you pick the flower, and then later they ask for all the addresses at once. If they used autocomplete="", they'd want each recipient to have their own section-* marker. > Also, why is sectioning better than using two forms for the example in > the spec? Well if they're going to be submitted all together, they're one form. I don't really understand how it would work to have two forms if you need to fill them both in and have one submit button. > One of the complexities with arbitrary sectioning is how to display the > multiple sections in the browser's rAc UI. If rAc() is faced with something it can't work out how to display, it can just return "disabled". That occurs with far more than just "section-*". For example, what would you do if the form had just a bday-day, cc-type, and a tel-local-suffix field? It's hard to imagine that rAc() could do anything useful with that. > Choosing multiple sets of information for different sections at once can > be overwhelming/confusing. How are UAs expected to communicate what > section goes with each profile? Surely UAs aren't going to show "red" > and "blue" for the example in the spec but it's not so straightforward > to find an appropriate label/heading. The section-* labels certainly shouldn't be used, agreed. It's a good point that there isn't a good way to label the different sections in rAc(). Note that section-* long predates rAc() in the spec. It's also useful for non-rAc() autofill. For example, if a browser lets you pick an address from an address-line1 field's autofill dropdown, and then autofills all the other fields (address-line2, postal-code, etc), the section-* keywords lets it know that it should only do so within one region of the form, and that the other address-line2 fields are for another address. Same with e.g. if the form asks for names and birthdays of everyone in one's family: the UA would let you pick a name for the "name" field, and could autofill the "bday" field, but without the section-* labels it would have no way to know that the second name field is related to the second bday field and not the first bday field. On Wed, 14 May 2014, Ilya Sherman wrote: > > That's a good question. Initially, sections were motivated by the > desire to distinguish between "shipping" and "billing", i.e. the > recommendation was to use "section-shipping" and "section-billing". We > eventually realized that "shipping" and "billing" are so commonly used > that they merited having their own unique tokens. Now that those are > separately canonicalized, the motivation for section-* tokens is much > less clear. The examples above, as well as the Japanese vs Romanised name example in the spec, all seem like pretty strong use cases to me. > For example, a social network might ask for multiple points of contact > info, e.g. a home address and also a work address. There are other > types of addresses as well: For example, not all mailing addresses, such > as P.O. boxes, are shipping addresses to which packages can be > delivered. The idea is that section-* tokens allow a website to ask for > multiple addresses of types that are not necessarily billing or > shipping. > > It's certainly possible to use multiple forms, or to use a , > to describe such a form. Using a single form can be more convenient for > the user, as there's just a single submit button. Using a > can be inconvenient for the developer, as fields belonging to the same > section might not be listed adjacent to one another in an HTML file. > (Most commonly, this occurs when a developer is allowing presentation to > guide their HTML structure, so perhaps we should actively discourage > this as an anti-pattern.) > > Section tokens were designed before rAc was a consideration. In Chrome, > we use them for the "Autofill" feature (which presents a helpful popup > as the user interacts with a regular ol' visible form), but not for rAc. > It's possible that the use case for section-* tokens is so marginal that > it would be better to simply remove them, since "billing" and "shipping" > cover the common case. Right. On Wed, 14 May 2014, Matthew Noorenberghe wrote: > > OK, that makes sense. If
