W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2013

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

From: James Graham <jgraham@opera.com>
Date: Mon, 29 Apr 2013 10:56:53 +0200
Message-ID: <517E35D5.7040401@opera.com>
To: whatwg@lists.whatwg.org
On 04/29/2013 05:26 AM, Robert O'Callahan wrote:
> On Mon, Apr 29, 2013 at 3:11 PM, Glenn Maynard <glenn@zewt.org> wrote:
>
>> On Sun, Apr 28, 2013 at 9:11 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> It would be easy for us to add some Firefox-only or FirefoxOS-only API
>>> here, but that seems anti-standards. I'd rather unnecessarily standardize a
>>> feature that doesn't get broadly used, than propagate some Firefox-only
>>> feature that does get broadly used.
>>>
>>
>> If it's a feature that will only actually be used in FirefoxOS, then
>> expecting other browser vendors to invest time implementing it wouldn't
>> make sense.
>>
>
>   If it doesn't get used, why would they need to invest time implementing it?
>
> 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.

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.

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.
Received on Monday, 29 April 2013 08:57:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:57 UTC