On 1/10/12 3:40 PM, Adam Barth wrote:
Do they really need to block the load, or block processing of the response?
Just block processing the response.
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).
The actual element turns out to be useful tracking down and fixing
these issues, at least in complicated web sites.
Fair.
To be clear, I'm not the biggest fan of beforeload because dispatching
synchronous events during loading is pretty tricky.
Exactly. Also bad for the long-term evolution of the web, in my opinion.
They are reasonably popular, however.
Except that every use case that's been brought up so far (except the
not-really-working-anyway adblock use case) hasn't actually wanted what
this event claims to provide but something slightly different... and
just not had that better thing.
I do think there are good use cases here that we should address; a sync
"before load" event is not the right way to address the ones I've seen
so far.
-Boris
