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

[Boris Zbarsky]

On 1/10/12 1:02 AM, Boris Zbarsky wrote:
> I'd like to understand the client-side transformation use-case better,
> in particular. What is it really trying to do?

OK, I got more context on this.  The goal of the client-side 
transformation case is effectively do something like what one can do 
with XSLT in XML.  Specifically:

1)  Don't actually render the HTML coming down the pipe.  This includes 
not doing any loads from it, but also includes not actually doing 
layout, not running scripts in the page, etc.

2)  Bind some sort of transformation to it (in this case a script that 
runs on the DOM or on the original source, depending).

3)  Render the result of that transformation.

mobify uses beforeload for a poor-man's approximation to #1: it can 
block loads, but not prevent execution of inline scripts or prevent 
layout (short of adding "display:none" styles to the page itself).  Then 
it does various other hackery to do #2 and #3.

I agree that this is a good use case to solve, but beforeload doesn't 
really solve it.  We should provide a better solution.

For the rest, I just checked and WebKit does set the event target to the 
node triggering the load, at least for <script> nodes.  I can nearly 
guarantee that we would NOT be willing to do that in Gecko even if we 
were convinced that the 'beforeload' event is a good idea in the first 
place.

The 'afterload' event doesn't have the same sort of problems, of course; 
it's no different from existing 'load' events in cases when it's fired 
on an element.  Whether it provides a good solution for other cases, I 
haven't had a chance to think through yet.

-Boris