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

[Ian Hickson]

On Mon, 9 Jan 2012, Tantek Ã~Gelik wrote:
>
> WebKit supports a 'beforeload' event [1] which is supported in shipping 
> Safari and Chrome[2] and apparently has (enabled) the real-world 
> use-cases of:
> 
> 1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock 
> extension

Extensions are out of scope, since they don't have to use standard Web 
features.


> 2. Clientside transformations, e.g. Mobify

I couldn't work out the use case here. Can you elaborate? If it's just 
"make a Web site work for multiple media including handheld and desktop", 
then it seems like building a multimedia site from the ground up using 
media queries, CSS, and media-aware JS is a far better solution than 
taking a Desktop site and pushing extra JS into it to hack the page to 
work on a mobile device.


> As might be expected, there is at least one use-case for a complementary 
> 'afterload' event:
> 
> Downloadable fonts - people who want to use custom fonts for drawing in 
> the canvas element need to know when a font has loaded. 'afterload' 
> seems like a good way to know that, since it happens as a side effect of 
> actually using it and fonts don't have an explicit load API like images 
> do.

Seems like the right way to support that is to provide a font loading API, 
not a global loading notification API that you can use to look for font 
URLs.


> Safari and Chrome have already shipped 'beforeload' [...].

On Tue, 10 Jan 2012, Boris Zbarsky wrote:
> 
> 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.

Having the mobile device do this sounds like a terrible idea. Surely it 
would be orders of magnitude more effective to have the server do this 
kind of transformation.


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

I'm not sure I agree it's a good use case to solve, but I definitely agree 
that even if it was, beforeload wouldn't cut it.


> 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.

Indeed. In fact, at that point I don't really understand the difference 
between beforeload and the progress-events-suggested "loadstart", which 
some objects and elements use.

On Wed, 11 Jan 2012, Simon Pieters wrote:
> 
> 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.

Yeah that's pretty much sufficient for the transformation case...


On Sun, 15 Jan 2012, Boris Zbarsky wrote:
> 
> Again, preventing preloads on a per-load basis is a hard problem if you 
> want to have sane parallelism.  Preventing _all_ loads for a document 
> based on some declarative thing near the start of the document, on the 
> other hand, should not be too bad.  If that plus a beforeprocess event 
> addresses the majority of the web-facing use cases, we should consider 
> adding that.

Preventing all loads in a document seems trivial. Don't declare any loads! 
I really don't understand why you would include <script> and <img> 
elements, etc, if you're not going to want them to be processed.

(The only exception I can think of is for defining templates or shadow 
trees for segments or components that are going to be stamped out later. 
The Web Components work on <template>s will likely end up providing a 
declarative way to "neuter" parts of a document for that purpose, though.)


On Tue, 17 Jan 2012, James Robinson wrote:
> 
> It seems like there are two [features being requested]:
> 
> 1.) Monitoring/modifying/preventing network activity for a given 
> resource load
> 
> 2.) Monitoring/modifying/preventing DOM modifications that occur as the 
> result of a resource load
> 
> For (1) I can't think of any web-facing [use cases].  For extensions, I 
> believe this is better addressed by APIs that target the network layer 
> more directly - for example proxy auto config scripts, or things like 
> http://code.google.com/chrome/extensions/trunk/webRequest.html.
> 
> For (2) I think this would be better addressed by using next-generation 
> mutation events to observe (and potentially react) to the changes that 
> occur when an <img> is loaded, for example.  I struggle to think of good 
> web-facing use cases for this, though.
> 
> In any event I think that beforeload as it exists today is a bad API for 
> the web and hope that we can stop exposing it to the web in WebKit 
> (although I suspect it'll stick around for extension contexts, which is 
> more acceptable in my view).

I couldn't agree more with the above.


On Tue, 10 Jan 2012, Adam Barth wrote:
> 
> Some web sites use beforeload to monitor for mixed content 
> vulnerabilities.  In some cases, they block the load, and in other cases 
> they allow it (e.g., because they're working to clean up their mixed 
> content bugs).

On Tue, 10 Jan 2012, Boris Zbarsky wrote:
> 
> Do they really need to block the load, or block processing of the 
> response?
> 
> For the mixed-content case, it seems like blocking processing of the 
> response is enough (and that furthermore only the URI is needed, not the 
> actual element, to detect mixed-content cases).

On Tue, 10 Jan 2012, Adam Barth wrote:
> 
> The actual element turns out to be useful tracking down and fixing these 
> issues, at least in complicated web sites.  For example, suppose your 
> web application contains widgets written by separate teams and you want 
> to block mixed content requests in some, but not all, of these widgets.
> 
> To be clear, I'm not the biggest fan of beforeload because dispatching 
> synchronous events during loading is pretty tricky.  It took us a while 
> to get the crashes out of the WebKit implementation.  They are 
> reasonably popular, however.

On Tue, 10 Jan 2012, Boris Zbarsky 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="">?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'