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
