W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2015

Re: [whatwg] <iframe async>

From: David Håsäther <hasather@gmail.com>
Date: Fri, 27 Feb 2015 18:28:34 +0100
Message-ID: <CAMPaTMcDa+FLSzsN0zKtBSeom0CeEcecjzkLKa5DA+=bb1_1LQ@mail.gmail.com>
To: WHATWG <whatwg@lists.whatwg.org>
On Fri, Feb 27, 2015 at 5:51 PM, David Bruant <bruant.d@gmail.com> wrote:

>> We want these to have normal priority
>> (otherwise we could insert them on load), but we don't want want them
>> to delay load, mainly because *our* site is perceived as slow when the
>> progress bar is shown.
>
> Which progress bar are you referring to? The browser load UI indicator?

Yes.

>> I don't think it's too uncommon for people to
>> wait for the progress bar to disappear before they start interacting
>> with the page. I do that sometimes, e.g. to make sure I don't misclick
>> because an image loads and the page jumps.
>
> The "progress bar" problem and the load event problems seem distinct (but
> they're not because of how browsers implement the load UI indicator).

I'm mainly talking about the load indicator for my use case, I'm not
listening to the load event.

>> The bfcache problem is another thing that would be really nice to solve,
>> yes.
>
> From the problem statement, maybe the attribute that should be added is
> "does-not-delay-load" (which could be used on images or any element which
> loads something that delays the load event).

Yes, good point, there are probably use cases outside of iframes, e.g.
third-party images (like avatars, that could be considered
unimportant).

-- 
David Håsäther
Received on Friday, 27 February 2015 17:29:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:27 UTC