On Sat, 23 Aug 2014 02:44:23 +0200, Ian Hickson <i...@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

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 <i...@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
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

Reply via email to