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 15:54:11 +0100
Message-ID: <54F08513.5030006@gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>, whatwg@lists.whatwg.org
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.
> It sounds like what's wanted here is more of a "load this at lowest 
> priority", which has nothing to do with whether it's running in the 
> same thread (what I assume you mean by parallel) or not: either way 
> the net connection is shared, right?
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. That's how things were implemented in Servo last I 
looked (admittedly some time ago and iframes were far from 
standard-compliant, but I think the demo was relevant anyway).

I don't understand the concern with the shared net connection.
Does the spec mandates the order of resource loading between parent and 
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 an opt-in from devs, maybe?

>> Can async loading be retroffited into sandboxed iframes?
> Please define "async loading" in the context of your question?
What I meant was "loading that doesn't block parent's loading".

Received on Friday, 27 February 2015 14:54:41 UTC

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