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

[Boris Zbarsky]

On 2/3/12 3:07 PM, Ian Hickson wrote:
>> OK.  I have no serious problem with a "beforeprocess" event that fires
>> before processing the response, esp. if "processing" is defined in a
>> page-visible way (so e.g. you could still compile a script in the
>> background before firing "beforeprocess"; you just couldn't run it).
>
> I don't have an objection to adding a cancelable bubbling event that fires
> synchronously as part of the "execute a script block" algorithm, between
> the current steps 1 and 2 of "if the load was successful", which gets the
> URL of the script, targetted at the script, which if canceled cancels the
> execution of the script.
>
> Does any browser have an event like that already? If not, any opinions on
> an event name?<script onbeforerun="">?

Gecko has a "beforescriptexecute" event.  It's a simple event targeted 
at the element; there's no reason to include the URI, since that can be 
gotten off the element.  I believe calling preventDefault() on it will 
prevent the script from executing.

I also believe that we have proposed this for standardization in the 
past, though it seems to have fallen through the cracks a bit...

But note that this is script-specific; I believe that content-blocker 
use cases would want this for images, stylesheets, etc.

-Boris