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

Re: [whatwg] <iframe async>

From: David Bruant <bruant.d@gmail.com>
Date: Fri, 27 Feb 2015 16:37:26 +0100
Message-ID: <54F08F36.3000008@gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
Le 27/02/2015 16:24, Anne van Kesteren a écrit :
> On Fri, Feb 27, 2015 at 4:15 PM, David Bruant <bruant.d@gmail.com> wrote:
>> To achieve this priorization, currently, authors would use a bit of JS to
>> delay adding the iframe to the document. It seems like it solves all the
>> issues listed in the original message (load UI, load event, "fast back").
> Delay until what point?
The exact same question stands for implementors of the current proposal. 
Until what point should a browser delay loading the iframe?

The difference being that the author knows the relative importance of 
the various iframes among themselves and with the parent (at least 
better than the browser) and can make the choice between (non-exhaustive 
* a delay in ms after the delaying script starts executing
* after DOMContentLoaded or load
     * or any amount of time after one of the two events. Maybe choose 
to load after twice the time it took for DOMContentLoaded (which one can 
know via performance API)
* after first paint (there is a way to know when that happens, right? or 
with an upcoming spec?)
* after some other resource has loaded (maybe to "chain" iframe loading)
I'm sure there can be other reasonable options.
I don't think it's reasonable for browsers to implement all these options.

You said that you got feedback from someone asking for this.
What is the behavior they currently implement?
What are people doing today to work around this iframe loading issue?

Received on Friday, 27 February 2015 15:37:53 UTC

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