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

[James Robinson]

On Sun, Jan 15, 2012 at 1:23 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 1/12/12 9:22 AM, Boris Zbarsky wrote:
>
>> On 1/12/12 5:16 AM, Simon Pieters wrote:
>>
>>> Note that it
>>> removes the root element when the script element is executed, not at
>>> DOMContentLoaded.
>>>
>>
>> Ah, I missed that. I guess the HTML5 parsing algorithm means that now
>> the elements are parsed into the other document, eh? That's actually
>> pretty cute. I wonder whether we can get the mobify folks to switch to
>> this....
>>
>
> Thinking back on this, this still has the issue of not preventing preloads.
>
> Again, preventing preloads on a per-load basis is a hard problem if you
> want to have sane parallelism.  Preventing _all_ loads for a document based
> on some declarative thing near the start of the document, on the other
> hand, should not be too bad.


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.

It seems like there are two use cases:

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.  For extensions, I believe
this is better addressed by APIs that target the network layer more
directly - for example proxy auto config scripts, or things like
http://code.google.com/chrome/extensions/trunk/webRequest.html.

For (2) I think this would be better addressed by using next-generation
mutation events to observe (and potentially react) to the changes that
occur when an <img> is loaded, for example.  I struggle to think of good
web-facing use cases for this, though.

In any event I think that beforeload as it exists today is a bad API for
the web and hope that we can stop exposing it to the web in WebKit
(although I suspect it'll stick around for extension contexts, which is
more acceptable in my view).

- James



>  If that plus a beforeprocess event addresses the majority of the
> web-facing use cases, we should consider adding that.


>
> -Boris
>