[whatwg] should we add beforeload/afterload events to the web platform?
jamesr at google.com
Tue Jan 17 16:24:48 PST 2012
On Sun, Jan 15, 2012 at 1:23 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 1/12/12 9:22 AM, Boris Zbarsky wrote:
>> On 1/12/12 5:16 AM, Simon Pieters wrote:
>>> Note that it
>>> removes the root element when the script element is executed, not at
>> Ah, I missed that. I guess the HTML5 parsing algorithm means that now
>> the elements are parsed into the other document, eh? That's actually
>> pretty cute. I wonder whether we can get the mobify folks to switch to
> Thinking back on this, this still has the issue of not preventing preloads.
> 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.
Even this scheme doesn't work with a model like SPDY push or other bundling
techniques or with more aggressive preloading that initiates loads before
the main resource is loaded.
It seems like there are two use cases:
1.) Monitoring/modifying/preventing network activity for a given resource
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 needs. 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
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).
> If that plus a beforeprocess event addresses the majority of the
> web-facing use cases, we should consider adding that.
More information about the whatwg