- From: David Bruant <bruant.d@gmail.com>
- Date: Fri, 27 Feb 2015 16:37:26 +0100
- 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 list): * 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? David
Received on Friday, 27 February 2015 15:37:53 UTC