Re: XBL2 spec question... is the prefetch element underspecified?

(received on private list, but replied on public list because it was later 
sent to the public list too)

On Tue, 14 Nov 2006, Marcos Caceres wrote:
>
> Just wondering, does anyone else think that the behavior of the 
> <prefetch> element is slightly underspecified?

It is dramatically underspecified. This is actually intentional, because 
the exact behaviour doesn't really matter to get interoperability. It is 
merely advisory, and can be used by UAs to prime their cache, but is not 
required.


> The spec provides limited answers to the following questions:
> 
>    Do prefecthed resources load synchronously or asynchronously? (it is
> implied that it is asynchronous, but it doesn't say)

What would it be synchronous with? The insertion of the <prefetch> element 
into the DOM? That would be one way to implement it, but would not be very 
pleasant to the user. Implementing synchronously would be equivalent to 
pretending time had stopped while parsing the document and HTTP requests 
were instantaneous. We can't make that non-compliant, it's out of the 
scope of the spec.


>    While preloading, do these elements block the document's onLoad event until
> they have loaded?

No (the spec doesn't say they do, so they don't).


>    Once the element actually starts loading, does it fire an event on the
> implementation?
>    Once an element has loaded, does it fire an event on the implementation?
>    If the element fails to load, does it fire an event on the implementation?
>    If the src attribute points to an invalid url, does the UA fire an event?
> or is it in error and ignored?

No to all of these -- the spec doesn't say to fire any events, so no 
events fire.


>    If the author finds the prefetch taking too long, how can they cancel it?
> (Ie, should there be a scripting interface?)

If they don't want the prefetching to happen, they shouldn't specify it. 
They can't stop prefetching anyway -- the UA would be quite happily 
entitled to walk the XBL binding and find all the possible URIs that it 
might use and precache them itself, even without the <prefetch> element.


>    What happens when the MIME type of the prefetched resource is unknown to
> the User Agent?  for instance, the author prefetches 'foo.fum' of type
> 'application/apples'

The MIME type has no effect (since the spec doesn't say it has any 
effect). The only goal here is to let the UA prime its cache.


>    Can I access the internals of the data I have preloaded from the prefetch
> element? say, for instance, I load some RSS and I want to parse it? (ie. why
> use prefetch instead of XHR or just javascript?)

If the UA supports <prefetch>, and it fetched the resource, then when the 
script later does XHR, it will get the data from the cache instead of 
hitting the network (assuming cache headers are set appropriately). Thus, 
everything becomes quicker. However, <prefetch> and XHR are orthogonal, 
using one doesn't imply anything about using the other. You can't fetch 
the data from <prefetch> without using a mechanism to fetch data (like XHR 
or an <html:img> element or similar).


>    What's the scope of prefetch? can prefetched images, for example, be used
> by a bound document?

That depends on the UA's cache policy, but it would seem silly for the UA 
to partition its cache.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 5 January 2007 21:05:21 UTC