On Tue, 10 Jan 2012 07:34:19 +0100, Boris Zbarsky <bzbar...@mit.edu> wrote:
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
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297
Might not be cross-browser yet (e.g. Opera seems to run the image's onload
handler), but should work per spec I think. Well, the load can't be
prevented if it's speculatively loaded it before the script has executed,
but maybe that's fine for the use case.
--
Simon Pieters
Opera Software
