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

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

> On 04/29/2013 05:26 AM, Robert O'Callahan wrote:
>
>> Also, this is a feature where it's trivial for applications to gracefully
>> degrade on browsers that don't have the feature.
>>
>
> 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.
>

I'm not sure what you're getting at here.

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

Adding new things that delay the load event has not been a source of bugs
and confusion in my experience. Authors do it a lot and we've done it in
specs too.

Is getting screenshots of pages for thumbnails really something that needs
> an author-facing API? In general the concept of "fully loaded" doesn't make
> any sense for a class of modern web applications, which might keep loading
> content or changing their presentation across their liefetime. Therefore it
> seems like simply taking one screenshot at page load and replacing it with
> one a little later after a timeout might be a good-enough solution.
>

The problem is when you next load the application. You don't want to
replace a good screenshot with a screenshot of the application saying
"Loading...".

Rob
-- 
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

Received on Monday, 29 April 2013 09:43:17 UTC