Re: [whatwg] Prioritizing subresources (Was Script preloading)
On Sep 3, 2013 8:00 PM, "Ryosuke Niwa" wrote: > > On Sep 3, 2013, at 5:01 PM, William Chan (陈智昌) wrote: > > > Hello folks. Sorry for the late response to several comments in this > > mega-thread, I've mostly been traveling/vacationing for the past 2 months. > > A teammate asked me to look at this in case I had comments. I don't know > > web dev issues very well, so I'm going to restrain myself from offering > > many opinions about the new proposals other than wow, all this dependency > > stuff looks complicated, but maybe it's worth it? I'll keep to some > > observations from a networking performance perspective, in case it's > > relevant to the discussion: > > > > * Any advantages the preloader currently gives is probably only going to be > > magnified with HTTP/2. Browsers today will in key situations hold back > > lower priority resource loads, even after the resource has been discovered > > by the parser/preloader, in order to reduce network contention and > > prioritize resources. But with HTTP/2, the browser almost never has to do > > this since it can express the request priority in the HTTP/2 protocol > > itself, and let the server order responses appropriately. > > * is great for resource discovery. Given the above > > observation, note that it has some deficiencies. Most obviously, it does > > not indicate the resource type. Browsers today can heuristically assign a > > priority based on the resource type (script/image/stylesheet/etc). > > Arguably, browsers could just use the filename extension as a hint to the > > resource type, and that'd get us most of the way there. In any case, > > Chromium, when it encounters is going to assign the > > resource load the lowest priority level, and only when the parser > > encounters the actual resource via a
Re: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption
2013-09-04 0:09, Ian Hickson wrote: To a user, even “(an image)” is better than lack of alt attribute I disagree. The lack of an alt attribute can be used by user agents to substitute the string "(an image)", in which case it is the same, or it can be used to do far more, e.g. image recognition, OCR, etc. This isn't academic, these technologies exist today. There is nothing that makes that makes that impossible, or more difficult, if the element has an alt attribute. If you mean that programs would actually do such things if and only if the alt attribute is absent, then this is very speculative. Let’s worry about that when browsers are actually capable and willing to do such things at all. There is an essential difference between lack of an alt attribute and a more or less generic value used for it, as in alt="(an image)" or in alt="(image: horse5)" (automatically generated e.g. from an image URL that ends with horse5.png) or in alt="(photo of Hixie)". Lack of the alt attribute says absolutely nothing about the image; it might represent a word as an image, or be pure decoration, or be so complicated that writing a textual alternative would be major challenge in content production. Someone who hears, says “image – horse five” at least gets some idea of what the image is about, and even “an image” as opposite to whatever a speech browsers says about is an improvement: the user can know that the author tried to find a textual replacement for the image but couldn't. To the non-validator user agent, that attribute means nothing. It's a non-conforming attribute with no semantics to any software outside content generators and conformance checkers. It is presented as a non-conforming attribute that can be used to get a clean validation report, i.e. to make a validator report a document as valid, as conforming. This is grossly illogical and misleading. Anyone who uses a validator has the right to know whether the document is valid or not, to the extent that this can be programmatically determined. And it is, if the attribute is not valid. Here's a proposal: The character U+FFFC OBJECT REPLACEMENT CHARACTER, which is “used as placeholder in text for an otherwise unspecified object” [the quote is from the code chart entry in the Unicode Standard] be used as the value of an alt attribute to indicate that it was not possible to write an adequate alternate text for the image. This typically means that the image comes from a source external to the system that generates the HTML document and the system cannot analyze it or otherwise find a suitable text replacement. You could even add a statement like this: User agents that present the value of an alt attribute to the user may express the value of U+FFFC using a generic expression like “some image”. They may also apply technologies that process the image trying to recognize its content and then express the result suitably, e.g. “an unrecognizable image” or “an image of a horse” or (in the case of having recognized that the content is scannable as text) “Hello”. – It’s of course possible that people would then use alt="&#fffc;" to silence validators even when they could easily write real text there. But they can anyway use alt="" for such purposes if they want to. Yucca
[whatwg] Prioritizing subresources (Was Script preloading)
On Sep 3, 2013, at 5:01 PM, William Chan (陈智昌) wrote: > Hello folks. Sorry for the late response to several comments in this > mega-thread, I've mostly been traveling/vacationing for the past 2 months. > A teammate asked me to look at this in case I had comments. I don't know > web dev issues very well, so I'm going to restrain myself from offering > many opinions about the new proposals other than wow, all this dependency > stuff looks complicated, but maybe it's worth it? I'll keep to some > observations from a networking performance perspective, in case it's > relevant to the discussion: > > * Any advantages the preloader currently gives is probably only going to be > magnified with HTTP/2. Browsers today will in key situations hold back > lower priority resource loads, even after the resource has been discovered > by the parser/preloader, in order to reduce network contention and > prioritize resources. But with HTTP/2, the browser almost never has to do > this since it can express the request priority in the HTTP/2 protocol > itself, and let the server order responses appropriately. > * is great for resource discovery. Given the above > observation, note that it has some deficiencies. Most obviously, it does > not indicate the resource type. Browsers today can heuristically assign a > priority based on the resource type (script/image/stylesheet/etc). > Arguably, browsers could just use the filename extension as a hint to the > resource type, and that'd get us most of the way there. In any case, > Chromium, when it encounters is going to assign the > resource load the lowest priority level, and only when the parser > encounters the actual resource via a
Re: [whatwg] Challenging canvas.supportsContext
On 9/3/13 7:13 PM, Ian Hickson wrote: Wouldn't checking for window.WebGLRenderingContext be just as unreliable then? I don't understand why it's ok to be able to test that, but why probablySupportsContext() wouldn't be ok. I'm a lot more OK with the "probablySupportsContext" naming than "supportsContext" here. -Boris
Re: [whatwg] Script preloading
Hello folks. Sorry for the late response to several comments in this mega-thread, I've mostly been traveling/vacationing for the past 2 months. A teammate asked me to look at this in case I had comments. I don't know web dev issues very well, so I'm going to restrain myself from offering many opinions about the new proposals other than wow, all this dependency stuff looks complicated, but maybe it's worth it? I'll keep to some observations from a networking performance perspective, in case it's relevant to the discussion: * Any advantages the preloader currently gives is probably only going to be magnified with HTTP/2. Browsers today will in key situations hold back lower priority resource loads, even after the resource has been discovered by the parser/preloader, in order to reduce network contention and prioritize resources. But with HTTP/2, the browser almost never has to do this since it can express the request priority in the HTTP/2 protocol itself, and let the server order responses appropriately. * is great for resource discovery. Given the above observation, note that it has some deficiencies. Most obviously, it does not indicate the resource type. Browsers today can heuristically assign a priority based on the resource type (script/image/stylesheet/etc). Arguably, browsers could just use the filename extension as a hint to the resource type, and that'd get us most of the way there. In any case, Chromium, when it encounters is going to assign the resource load the lowest priority level, and only when the parser encounters the actual resource via a tag or something, will another resource load be issued with the "appropriate" priority. Almost all modern browsers will hold back low priority resource loads before first paint in order to get critical scripts and stylesheets in ASAP without contention. Anything marked with will be considered low priority and in all likelihood not requested early. Note that HTTP/2 currently does not support re-prioritization (and that feature is being debated), so that means that when the resource load for gets issued over an HTTP/2 connection, it will have the lowest priority, which is probably undesirable. FWIW, I think was a good initial start, but suffers from key weaknesses and should be thrown out and replaced. * Given current browser heuristics for resource prioritization based on resource type, all