On Fri, Feb 27, 2015 at 7:52 PM, Fady Samuel fsam...@chromium.org wrote:
This is obviously larger than the particular set of use cases mentioned
here, but another set of iframe discussions I've seen lately have centered
around going off thread or out of process. I wonder if there is a more
On Fri, Feb 27, 2015 at 7:31 PM, Ashley Gullen ash...@scirra.com wrote:
Perhaps independent is a better name than async, indicating the iframe
content is independent of the main page. Browser loading UI, load events,
fast back and possibly performance tools would not take in to account
On 2/27/15 9:54 AM, David Bruant wrote:
I jumped a bit to conclusions quickly, but I think the point remains. If
the iframe is loaded in parallel (different thread, different process,
anything that isn't blocking the parent), then its loading doesn't block
the parent loading.
Sure it does, to
Le 27/02/2015 15:54, David Bruant a écrit :
Does the spec mandates the order of resource loading between parent
and iframe?
If so, is it also the case for sandboxed iframes?
If not, then browsers have enough liberty today to prioritize parent's
resource loading over iframe without the need of
On Fri, Feb 27, 2015 at 4:37 PM, David Bruant bruan...@gmail.com wrote:
You said that you got feedback from someone asking for this.
What is the behavior they currently implement?
Since I'm one of the people Anne talked to, I can expand a bit on what he said.
Right now, we insert iframes
Le 27/02/2015 17:27, David Håsäther a écrit :
On Fri, Feb 27, 2015 at 4:37 PM, David Bruant bruan...@gmail.com wrote:
You said that you got feedback from someone asking for this.
What is the behavior they currently implement?
Since I'm one of the people Anne talked to, I can expand a bit on
On Fri, Feb 27, 2015 at 5:51 PM, David Bruant bruan...@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
On 2/27/15 4:43 AM, David Bruant wrote:
It is my belief that providing the sandbox attribute should be a strong
enough indicator that the iframe could be fully run in parallel (not
just loaded async'ly).
Iframes are already loaded async, obviously.
It sounds like what's wanted here is more of
Le 27/02/2015 15:23, Boris Zbarsky a écrit :
On 2/27/15 4:43 AM, David Bruant wrote:
It is my belief that providing the sandbox attribute should be a strong
enough indicator that the iframe could be fully run in parallel (not
just loaded async'ly).
Iframes are already loaded async, obviously.
Perhaps independent is a better name than async, indicating the iframe
content is independent of the main page. Browser loading UI, load events,
fast back and possibly performance tools would not take in to account
independent iframes, since they are explicitly marked as not important to
the
This is obviously larger than the particular set of use cases mentioned
here, but another set of iframe discussions I've seen lately have centered
around going off thread or out of process. I wonder if there is a more
basic primitive here that can apply to all these use cases [and perhaps
even
On Fri, Feb 27, 2015 at 3:59 PM, David Bruant bruan...@gmail.com wrote:
The request is to being able to
provide different priority orders to different iframes (some containing not
important content like ads, others containing important content) while what
I'm suggesting treats all iframes the
On 2/27/15 10:24 AM, Anne van Kesteren wrote:
On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@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
I've started thinking about better iframes lately and I've been thinking
along the lines of async iframes as well. If you start adding iframes
onload, are you not forcing relayout? In an iframe async world, you can
compute the layout of the top level frame before beginning to load the
content of
On Fri, Feb 27, 2015 at 4:37 PM, David Bruant bruan...@gmail.com wrote:
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
On 2/27/15 10:15 AM, David Bruant wrote:
But for processor timeslices, the amount of blocking seems insignificant
compared to the current situation as long as you have the hardware to
run 2 threads in parallel, no?
Until the subframe spins up a dozen workers, yes.
To achieve this
On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@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).
On 2/27/15 10:35 AM, Fady Samuel wrote:
I've started thinking about better iframes lately and I've been
thinking along the lines of async iframes as well. If you start adding
iframes onload, are you not forcing relayout?
You can add whenever and set src onload.
Of course the more complicated
On Fri, Feb 27, 2015 at 4:28 PM, Boris Zbarsky bzbar...@mit.edu wrote:
onload, if you don't want it to block onload.
Yeah that seems like a pretty bad alternative. That would be quite a
significant delay.
--
https://annevankesteren.nl/
Le 27/02/2015 15:58, Boris Zbarsky a écrit :
On 2/27/15 9:54 AM, David Bruant wrote:
I jumped a bit to conclusions quickly, but I think the point remains. If
the iframe is loaded in parallel (different thread, different process,
anything that isn't blocking the parent), then its loading doesn't
On 2/27/15 10:06 AM, Anne van Kesteren wrote:
Yes, less important and therefore should not block the load event or
any UA notion of complete.
Hmm. Not blocking the load event is interesting. Right now, even
defer scripts and whatnot block the load event. Experimenting with an
opt-in way
Le 27/02/2015 16:24, Anne van Kesteren a écrit :
On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@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
On 2/27/15 2:18 PM, Tim Streater wrote:
One thing I'd like would be to be able to put content into an iframe (and thus
have it parsed), but defer any rendering or speculative download of resources
referred to in the content.
Depending on whether you care about the href of your iframe and
On 27 Feb 2015 at 18:52, Fady Samuel fsam...@chromium.org wrote:
This is obviously larger than the particular set of use cases mentioned
here, but another set of iframe discussions I've seen lately have centered
around going off thread or out of process. I wonder if there is a more
basic
Hi Anne,
Le 27/02/2015 08:57, Anne van Kesteren a écrit :
I got feedback that isolating ads from your page through iframe is
desirable, but that the impact on browser load UI, the load event, and
fast back, are very much not desirable.
It's the first time I read the term fast back? What does
On 27 Feb 2015 at 19:38, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/27/15 2:18 PM, Tim Streater wrote:
One thing I'd like would be to be able to put content into an iframe (and
thus have it parsed), but defer any rendering or speculative download of
resources referred to in the content.
26 matches
Mail list logo
