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

[Henri Sivonen]

On Tue, Jan 10, 2012 at 7:48 AM, Tantek Çelik <tantek at cs.stanford.edu> wrote:
> 1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock
> extension[2]

Extension use cases don't require an API exposed to Web content, though.

Furthermore, IE9 has a built content blocking rule engine and Firefox
has a de facto dominant rule engine for year even though it has been
shipped separately (AdBlock Plus). Maybe instead of exposing arbitrary
programmability for content blocking, other browsers should follow IE9
and offer a built-in rule engine for content blocking instead of
letting extensions run arbitrary JS to inspect every load.

> 2. Clientside transformations, e.g. Mobify[3]

There's already an easier cross-browser way to "deactivate" an HTML
page and use its source as input to a program:
document.write("<plaintext style='display:none;'>"); (This gives you
source to work with instead of a DOM, but you can explicitly parse the
source to a DOM.)

Anyway, I'd rather see mobile adaptations be based on CSS instead of
everyone shipping a bunch of JS to the client munge the page in ways
that foil all optimizations that browsers do for regular page loads.

> As might be expected, there is at least one use-case for a
> complementary 'afterload' event:
>
> 1. 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.[4]

It seems like fonts should have an API for listening when they become
available, yes.

> Should 'beforeload'/'afterload' be explicitly specified and added to
> the web platform?

I'm worried about the interaction with speculative loading. Right now,
Gecko is more aggressive than WebKit about speculative loading. I
don't want to make Gecko less aggressive about speculative loading in
order to fire beforeload exactly at the points where WebKit fires
them. I'm even worried about exposing resource load decisions to the
main thread at all. Right now in Gecko, the HTML parser sees the data
on a non-main thread. Networking runs on another non-main thread. Even
though right now speculative loads travel from the parser thread to
networking library via the main thread, it would be unfortunate to
constrain the design so that future versions of Gecko couldn't
communicate speculative loads directly from the parser thread to the
networking thread without waiting on the main-thread event loop in
between. (In this kind of design, a built-in content blocking rule
engine would be nicer than letting extensions be involved in non-main
threads.)

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/