- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sat, 18 Dec 2010 18:12:48 -0500
- To: Getify <getify@gmail.com>
- Cc: public html <public-html@w3.org>
On Fri, Dec 17, 2010 at 7:18 PM, Getify <getify@gmail.com> wrote: > I'm also trying to interpret the "spirit" of the spec with respect to how > the user-agent should behave if it actually requests a resource (because > let's say the author omits the `type` attribute on the container) and the > container which receives it cannot validly process the type. For instance, > if `new Image()` (in JavaScript) is used to fetch a URL, or if <object> does > the same, and the resource that's returned is actually a script (or CSS > file), it seems clear that the spec says the element should be ignored. That depends on exactly what context it's used in. The spec is meant to be written so you can figure out what the letter of the spec means, without having to interpret the "spirit". If it doesn't explicitly say something, that behavior is undefined. > But I'm curious if that means (or *should* mean) that the resource is > discarded/purged from the cache (if it was cached)? Or should that element > be left alone in the cache? Some browsers are in the habit of "marking" such > "ignored" resources with the invalid type, thus tainting that resource from > being properly used with its correct type at a later time in the page > life-time. > > In other words, what is the full intent of "ignored"? Should the spec be > clear about how such an element should be treated in the cache? The spec is deliberately not specific about exactly how resources are loaded and cached, because it's good for browsers to be able to innovate and compete on the algorithms they use for this. The difference should not be black-box-detectable -- except for performance, of course. > I ask because many different "loaders" (both CSS and JavaScript) attempt to > use <object> and `new Image()` to "preload" (that is, load into cache, but > not parse/execute) such content. > > Is this a "safe" hack, or is it likely that such "preloading" will > eventually (or is intended to be) prevented? It sounds like a dedicated feature would be the desired way to solve this. I'm not sure offhand if one exists. What's the reason for using tricks to preload CSS or JS instead of just going ahead and loading it normally? Is it because of some inherent limitation, or just because of poor existing implementations? Recent browser versions have gotten much smarter about fetching things in parallel and so on -- is this stuff still needed for the latest browsers?
Received on Saturday, 18 December 2010 23:13:41 UTC