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

>> 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.

I can understand this as a general approach, but leaving something 
deliberately undefined also has the potential to create a ridiculous mess 
where the browsers all diverge, and then are forced to stay divergent 
because of their own legacy issues.

I'd say the spec should be open to more strictly defining that which has 
previously been left "undefined" when it becomes clear that leaving 
something "undefined" is creating confusion and inefficiency among the 
browser vendors instead of encouraging open experimentation.

With respect to my current question, *I* think we're far overdue in that 
regard.

>> 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.

For performance optimization reasons (both in CSS loading and in JS 
loading), as I said above, I think it's time that the spec consider being 
more specific on this issue. The performance optimization community is 
starting to realize that how an element is loaded and cached makes a huge 
difference in how the page (page-load, page run-time, etc) will perform.

Leaving the loading/caching behavior (for JS and CSS, specifically) 
undefined is no longer encouraging the browser vendors to compete and 
innovate as much as it is leading to significantly costly legacy behavior, 
divergent algorithms that are not (as you assert) feature-testable, 
requiring brittle browser sniffing (user-agent, browser inference, etc), and 
lots of misinformation as people try to externally discover the intricacies 
of each browser's algorithm.

As indicated below, the need to "preload" (without having a direct facility 
to do so) is leading to usage of elements in ways they weren't necessarily 
intended to work, and this usage is what's calling into direct inspection 
what the currently "undefined" behavior of loading/caching is for such 
elements.

>> 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?

I hesitate to dive into answer this question fully in this thread, because I 
think it probably needs its own thread. So, that's what I'll do, I'll start 
a separate thread to talk about "preloading" (subject: 'Need to: "preload" 
CSS and JS') and we'll keep this thread specifically about my question of 
how resources should be loaded/handled in the cases where they're loaded 
with improper containers or mime-types.

To the extent that the other thread doesn't lead to a direct and immediate 
answer to how to "preload" resources, this thread's discussion of how 
resource loading/caching should behave is still, I think, relevant.

--Kyle

Received on Sunday, 19 December 2010 14:21:00 UTC