[whatwg] should we add beforeload/afterload events to the web platform?
bzbarsky at MIT.EDU
Fri Feb 3 12:18:29 PST 2012
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.
More information about the whatwg