[whatwg] should we add beforeload/afterload events to the web platform?

[James Robinson]

On Tue, Jan 17, 2012 at 4:29 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 1/17/12 7:24 PM, James Robinson wrote:
>
>> Even this scheme doesn't work with a model like SPDY push or other
>> bundling techniques or with more aggressive preloading that initiates
>> loads before the main resource is loaded.
>>
>
> Er... you mean it initiates loads before it has any idea whether the main
> resource might have changed such that it no longer links to the objects in
> question?
>

The way that these sorts of schemes work is that the server knows that a
set of resources are needed in addition to the main resource and it starts
sending them down before the client has received/parsed the main resource.
 The server serving foo.html can have a pretty good idea about whether
foo.html contains the string "<script src=foo.js>" so there isn't any real
reason for it to not serve foo.js at the same time assuming that the
underlying protocol can handle such a thing.  In situations with high RTTs
and reasonable bandwidth (like common mobile networks) this can be a big
win.

I bring this up to make sure that we aren't making promises about resource
loads that we can't keep.

- James


>
> I agree that such aggressive preloading is impossible to control from the
> source document; an interesting question is whether it's desirable.  I know
> that in the past when Gecko preloaded too aggressively we got huge
> complaints from various ad providers about "bogus impressions"....
>
>
>  1.) Monitoring/modifying/**preventing network activity for a given
>> resource load
>>
>> 2.) Monitoring/modifying/**preventing DOM modifications that occur as the
>> result of a resource load
>>
>> For (1) I can't think of any web-facing needs.
>>
>
> I believe mobify does in fact want (1) as much as it can to conserve
> bandwidth...
>
>
>  In any event I think that beforeload as it exists today is a bad API for
>> the web
>>
>
> Good, we agree on that.  ;)
>
>
>  (although I suspect it'll stick around for extension contexts, which is
>> more acceptable in my view).
>>
>
> It's obviously just fine from my pov at that point.  ;)
>
> -Boris
>