[whatwg] API to delay the document load event

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) [1][2]. 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 
secure confinement.

> ...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 
lighter version?

> (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 
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0111.html, 
> and look at the sample implementation I gave you earlier: 
> https://zewt.org/~glenn/finished-loading.html 
> <https://zewt.org/%7Eglenn/finished-loading.html>.
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 
property.

David

[1] 
https://groups.google.com/d/msg/google-caja-discuss/tFhYLJ4abL4/1Mq34zXd_z0J
[2] 
https://groups.google.com/d/msg/google-caja-discuss/tFhYLJ4abL4/p0xUcsV99boJ
[3] 
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039424.html
[4] 
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039440.html