[whatwg] API to delay the document load event
bruant.d at gmail.com
Tue Apr 30 01:38:38 PDT 2013
Le 30/04/2013 01:55, Glenn Maynard a écrit :
> "I want it to be self-contained within the code that's actually
> using the feature, not messing about with document-global attributes."
> => The "self-contained" keyword makes me think that you really
> want Caja or some lighter version of it.
> Good web APIs
There is no such thing as a "good web API". There are use cases,
different ways to achieve them, some require cooperation with the
platform, some can be achieved with pure libraries using existing features.
Let's try to pin down which use case belongs where based on the
state-of-the-art of the platform (spec+implementation) and
state-of-the-art of libraries.
> don't require the use of wrapper libraries (or script postprocessing
> tools--sorry, that's gross)...
There is a way to use Caja that doesn't require post-processing
apparently (based on ES5 strict mode, they say it's undocumented for
now) . Note that I agree on the gross-ness. Probably the Caja
folks do too. It's not for fun that they came to this conclusion. They
did because the platform is absurdly hard to deal with when trying do
> ...to use in a clean, self-contained way.
Yes, I really wish the platform was providing a good way to do seamless
secure communication-friendly self-containment. ES6 will have the module
loader API and that'll help. For the rest of the web platform,
unfortunately, Caja remains the best thing around. And will remain the
only possible thing because of the same-origin policy. (Caja relies on a
server proxy to fetch cross-origin referrer-less, cookie-less resources)
You keep saying "self-contained" and I keep answering you "Caja". What's
your definition of "self-contained" that doesn't require Caja or some
> (Sorry for some heavy snipping, but let's slow down discussing what
> the API should look like for a bit, so we don't drown out the
> discussions about use cases, the need for this feature, where it
> should live, etc.)
Whether to support "independent scripts" or not influences what the API
should look like.
> On Mon, Apr 29, 2013 at 7:44 AM, David Bruant <bruant.d at gmail.com
> <mailto:bruant.d at gmail.com>> wrote:
> What about starting with an API à la html at loading and if devs
> complain it's too hard when there are independent scripts, then
> add a mechanism like delayLoadEvent/stopDelayingLoadEvent? (I
> still believe delaying the UA load event is a terrible idea. What
> will dev tools show? The actual load event or the delayed one? And
> the argument about performanceTiming, etc.). The more complex
> multi-call API can be later retrofitted, but please wait for devs
> to ask for it.
> We shouldn't expose one API with the expectation that we might have to
> add a second API for the same thing. Then we're permanently stuck
> with two separate, overlapping APIs, which is far more complex.
It's not absolutely necessary, but looking back at the different
proposals in this thread, it's hard to reconcile them.
> How are document.delayLoadEvent and document.stopDelayingLoadEvent
> any less global than an attribute on <html>? That is *exactly* the
> same amount of globalness. The risks and consequences of bugs and
> malicious behavior is equivalent for both features.
> Huh? That wasn't my proposal; I argued specifically against that.
> Please see
> and look at the sample implementation I gave you earlier:
My bad. I had misunderstood this part of your proposal.
I guess we're back on whether it's considered a good thing to distribute
authority to independent scripts on the same page without being able to
react *at runtime* if one fails to use properly its authority.
As you cited it, addEventListener is good at distribution, because one
handler can't mess with other handlers (unless
.stop(Immediate)Propagation which is very explicit). Like, if a handler
throws, the error is swallowed and other handlers are called normally.
One error doesn't stop your application from working. It only stops the
one part that depended on the (failing) event handler. Here, there is no
recovery story. If one "independent" part fails, the whole page fails to
tell the UA that the app is ready. I don't think this is an acceptable
More information about the whatwg