Re: what to do with invalid (or improper) mime-type resources

> Similarly with loading.  Browsers need to be able to make intelligent
> decisions on what to load when, including deciding (perhaps based on
> bandwidth or other constraints) whether to prefetch things or wait
> until they're needed.  A browser that wants to conserve bandwidth --
> maybe it knows it's on a per-per-megabyte mobile connection, or it
> doesn't want to interfere with other pages loading at the same time --
> might legitimately decide not to prefetch something no matter what the
> author thinks.

Another thing that’s curious to me about your assertion that the spec should 
stay out of such details like "loading":

4.3.1 The `script` element
http://www.w3.org/TR/html5/scripting-1.html#running-a-script

"6. If the user agent does not support the scripting language given by the 
script block's type for this script element, then the user agent must abort 
these steps at this point. The script is not executed."

The context of this statement is that it's step 6, and it says to abort the 
steps if the `type` value is invalid. Step 12 is where the browser can fetch 
the resource, so this step 6 tells the browser effectively *not* to 
fetch/load a resource if the type is invalid. Other wording in this section 
seems to speak to the intent, which is that loading of the resource is 
specifically being prevented (not just a hint by the spec, but an 
algorithmic requirement), and that the idea is that this prevents an 
unnecessary load of the resource.

I could easily argue back against this algorithm and say: "why shouldn't the 
browser be allowed to fetch the resource?" Why is the spec taking the extra 
step to restrict what the browser can do in this circumstance?

And how is that not quite similar to what I'm suggesting? All I'm suggesting 
is that the spec should be consistent, and should give instruction on when 
to load resources and when not, for the containers like <object> and `Image` 
and <link>? And if you're in the business of telling the browser when to 
load and not, why not also give some guidance to the browser how it should 
handle caching of those resources during those specifically defined loading 
scenarios? That is, I'm only suggesting that maybe the dynamically inserted 
use-case for these containers should be more well-defined for loading and 
caching behavior, *NOT* the markup driven use-cases.

I don't see how specifying narrow loading/caching behavior under those very 
specific circumstances is overly restricting the browser's ability to make 
optimization judgments under other scenarios?


--Kyle

Received on Monday, 20 December 2010 13:59:02 UTC