Re: [whatwg] API to delay the document load event

On Sun, Apr 28, 2013 at 10:26 PM, Robert O'Callahan
<robert@ocallahan.org>wrote:

>  If it doesn't get used, why would they need to invest time implementing
> it?
>

Putting a feature in the HTML spec (or related specs) is asking all
browsers to implement it.  If we don't expect anyone but Firefox to
implement something, then it shouldn't be in there.  If all you want is the
feature to have a specification, that's different--an API can have a
specification without it being inside the HTML spec, it can still be openly
reviewed here, etc.

(Not to argue one way or the other about whether it would be used or not--I
have only a mild intuition that it wouldn't be--only that the bar should be
cross-browser use.)


On Mon, Apr 29, 2013 at 3:56 AM, James Graham <jgraham@opera.com> wrote:

> I'm not sure that's true. I mean, it's *possible* but you have to be
> careful to never depend on anything that could happen after the "natural"
> load event in e.g. your load event handler. I can quite easily see people
> getting that wrong.
>
> In general this seems quite a scary design. The load event is rather
> intimately tied in to the lifecycle of the document, and encouraging people
> to arbitrarily delay it feels like a potential source of bugs and confusion.
>

We've suggested firing a different event, leaving onload alone, so it's not
nearly so invasive.


On Mon, Apr 29, 2013 at 7:44 AM, David Bruant <bruant.d@gmail.com> wrote:

> What about starting with an API à la html@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.

Also, independent scripts loading on a page increase the probably of at
> least one failing.
>
>     document.delayLoadEvent();
>     doX(function(){
>         doY();
>         document.stopDelayingLoadEvent();
>     })
>

    var delay = document.delayCompletion();
    doX(function(){
        try {
            doY();
        } finally {
            delay.finished();
        }
    });



> That's a way to debug, not to react at runtime. If one of your independent
> script forgets to call document.stopDelayingLoadEvent(), how does the page
> recover to guarantee that the "load" event will happen eventually anyway?
>

I'm much more concerned with APIs being debuggable than APIs letting people
hack around bugs.  The delayCompletion() approach is the only one that is
trivially debuggable (you can figure out which DelayCompletion object was
never finalized, and where it was created); all of the others leave you
wondering which piece of code is messing about with the document attribute
or who called stopDelayingLoadEvent twice.

>   As a web developer, I can totally imagine a web browser forgetting to
> fire "load" because of weird internal conditions like "one
> document.delayLoadEvent call was before DOMContentLoaded and another after".
>

My proposal isn't to touch onload at all, it's to fire some other
independent event.  Its only relationship to onload is that onload is when
onfinishedloading gets run, if no delayCompletion objects are pending at
that time.

   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.


> "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 don't require the use of wrapper libraries (or script
postprocessing tools--sorry, that's gross) to use in a clean,
self-contained way.

(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.)

-- 
Glenn Maynard

Received on Monday, 29 April 2013 23:56:16 UTC