Re: [whatwg] Preloading and deferred loading of scripts and other resources

On Sat, 23 Aug 2014 02:44:23 +0200, Ian Hickson <ian@hixie.ch> wrote:


> On Wed, 12 Mar 2014, Boris Zbarsky wrote:
>>
>> I realize no one would write actual code like this; the real-life use  
>> case I'm
>> worried about would be more like this:
>>
>>   // img is already loaded sometimes
>>   // Would like to observe a new load
>>   var promise1 = img.loaded(); // oops! This will be pre-resolved if
>>                                // we were already loaded, but otherwise
>>                                // will resolve with the new load we're
>>                                // about to start.
>>   img.src = bar;
>
> promise1 would be rejected as soon as you set 'src' if it hadn't loaded
> yet.

The old image doesn't stop loading immediately when setting 'src' if its  
dimensions are known. In that case it only stops loading if the new image  
gets known dimensions before the old one finishes loading.

> If it had loaded, it would resolve straight away. In the latter case,
> you might observe either the old image or the new one, there's no way to
> know for sure.
>
> This is certainly bug-prone and I'm sure people will get it wrong and
> it'll usually work but sometimes not, due to the race. However, it's a
> logic error -- you're always observing the first load, not the second. It
> will always resolve straight away, either aborting or succeeding based on
> whether the original load is aborted or had completed.
>
>
> On Wed, 12 Mar 2014, Domenic Denicola wrote:
>>
>> With promises you should only ask for the "loaded" promise *after*
>> setting `src`; anything you retrieve before that represents a previous
>> load. Except, I suppose, for the base-case of images with no src,
>> transitioning to having an src? Or are they considered to have e.g.
>> loaded `about:blank` already?

No, but iframe does (when inserted to the document).

>> I.e. what should this do?
>>
>> var img = document.createElement("img");
>> var promise1 = img.loaded();
>> img.src = "foo.png";
>> var promise2 = img.loaded();
>
> I think we should spec this case to reject promise1, since the image is
> not .complete.

.complete returns true actually. (Thought I don't mind rejecting.)

> I definitely don't think we should say that promise1 waits
> for the src to be set.


> On Tue, 22 Jul 2014, Ben Maurer wrote:
>> On Tue, Jul 22, 2014 at 10:26 AM, Ian Hickson <ian@hixie.ch> wrote:
>> > On Mon, 21 Jul 2014, Ben Maurer wrote:
>> > >
>> > > (1) Allowing the user to specify parameters to Fetch. For example, a
>> > > user could say:
>> > >
>> > > <script src="/my.js" params="{'headers':{'myheader':'value'}}"
>> > > id="myscript" />
>> > >
>> > > This would allow the user to make any type of request customization
>> > > that they could for a direct call to Fetch.
>> >
>> > I think this would make a lot of sense. It's similar to earlier
>> > suggestions for controlling "Referer" on a per-link basis, but more
>> > generic. The problem I had with the proposals for controlling Referer
>> > was that while there's an obvious way to do it for <script> and
>> > <link>, it quickly starts breaking down don't have a 1:1 mapping of
>> > URL to element. For example, how do you get the fetches of URLs in a
>> > style sheet? Or of the poster frame of a <video> element? Or
>> > EventSource objects? Should we just have different ways to set the
>> > options for each one?
>>
>> I guess the upshot of of doing this through fetch is that once we added
>> the ability to specify fetch metadata it would hopefully reduce the need
>> for future modification of all the different ways one could load an
>> object.
>> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0129.html
>> suggests the idea of using fetch for stylesheet subresources in the
>> context of subresource integrity.
>
> Yeah. I think it makes sense to expose a Request object once one is
> underway, and a RequestInit object (probably in the form of a  
> JSON-encoded
> content attribute?) to configure it, at least for the main resources.
>
> I'm not sure how to handle elements with multiple resources, e.g. <video
> poster> or the new <picture> stuff.

So currently <video> and <img> have an attribute to configure the request,  
namely crossorigin="". It doesn't apply to poster, but <video crossorigin>  
applies to <video src>, <source src> *and* <track src>. (You can't paint  
the poster on a canvas anyway so it doesn't matter much.) For <img  
crossorigin> it applies to the URL that gets loaded, whether that is from  
src, srcset or <source srcset>.

integrity would need to be able to apply to each individual URL somehow  
(probably with a new srcset descriptor for <img>).

Is crossorigin's coarseness OK or do we need something per URL?

-- 
Simon Pieters
Opera Software

Received on Monday, 25 August 2014 09:23:16 UTC