Re: Prerender spec

Hi all,

I'm jumping in the middle of this with somewhat limited context, sorry 
if I'm missing something.

On 14/06/2013 18:56 , Philippe Le Hegaret wrote:
> On Fri, 2013-06-14 at 09:23 -0700, Arvind Jain wrote:
>> Do folks agree? Or should there be a separate document?
>>
> I guess it depends on the size and the level of buy-in. Usually, it's
> preferred to do an extension spec to start with but, in this case, it
> seems an overkill.

I agree that an extension spec for this seems way overkill. The primary 
advantage of doing that would be to not have to worry about 
synchronising with us too much. But given the size of the feature I 
doubt that would be a major issue.

If you want to push this forward, I would recommend to start with simply 
bringing it to the HTML WG as a proposal (in email, much like the below).

My (personal) push-back on this would be about whether it is really 
valuable for UAs, in addition to prefetch. Both prefetch and prerender 
are hints, with behaviour largely left up to the UA. My question would 
therefore be: what is that prevents a browser from seeing a prefetch 
link and in fact prerendering it? Is this something that would not be 
decidable subject to some given heuristics? Failing that — and perhaps 
more importantly — are developers likely to choose between the two wisely?

The latter question is particularly important, because if the answer 
tends to be "no", then you're back to treating prefetch and prerender as 
the same thing, and requiring some form of heuristic to decide when to load.

Note that I'm not turning your proposal down here — I'm just pointing 
out the questions that will need answering in order to move this 
forward. I'm not a performance expert; the odds are that you have very 
good answers I haven't thought of.

> Any reason why this can't be applied to a and area elements, like
> prefetch?

IMHO if it's on link it ought to be on those two as well.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Friday, 21 June 2013 10:59:24 UTC