When should HTMLImageElement trigger resource loading? (Was: Possible implementation route towards <picture>)

[Yoav Weiss]

On Fri, Jan 31, 2014 at 11:14 AM, Simon Pieters <sim...@opera.com> wrote:

On Fri, 31 Jan 2014 09:48:54 +0100, Yoav Weiss <yo...@yoav.ws> wrote:

How to implement this needs to be specified, which is https://github.com/
ResponsiveImagesCG/picture-element/issues/91

I agree that the "what to implement" parts should be specified. IMO we
should spec:
* JS based 'src' setting should trigger an immediate download, before the
element is added to the DOM

"immediate" is wrong per spec even ignoring <picture>. http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data step 8 requires you to await a stable state, which basically means to let the current script finish or, in the HTML parser case, wait until the parser yields to the event loop (or encounters a </script> tag which provides a stable state).

The spec requires this so that authors can set the src and crossorigin attributes in any order in script and it should have the same effect.

I think the same reasoning should apply to script-created img/picture structure: you don't want to start downloading a script-created img if the next line in the script is going to append it to a picture element, so we should await a stable state.

You're right that "immediate" is wrong according to the spec, but it seems that this is the way that it's currently implemented in Blink. From testing the setting of src and crossorigin in both orders, it seems that Blink, WebKit and IE send the request immediately, without waiting for stable state and as a result, images where src is set first are sent without an "origin" header. It's hard to tell for Gecko since it doesn't send an "origin" header even when crossorigin is set before src.

So, I guess my question is "Who is wrong here?"

On the one hand, the specified behavior would be better for authors, enabling the setting of src, srcset and crossorigin in arbitrary order and receive the same results. It'd also enable HTMLImageElement to be aware of its parent before triggering any resource requests, facilitating the implementation of picture's selection algorithm.

On the other hand, no browser does that today.

Should I open a bug regarding the current behavior in Blink?

[Yoav Weiss]

On Mon, Feb 3, 2014 at 11:27 PM, Yoav Weiss <yo...@yoav.ws> wrote:

 It's hard to tell for Gecko since it doesn't send an "origin" header even when crossorigin is set before src.

 

Gecko does send the "origin" header when crossOrigin is set before src and the request is actually cross-origin. It doesn't send it when crossOrigin is set after src, though.

So, all browsers seem to immediately load resources when the src attribute is set, rather than wait for stable state.

[Philip Jägenstedt]

I'm currently working on supporting "await a stable state":
http://crbug.com/340547

I need it for HTMLMediaElement, but it should also allow us to
implement http://whatwg.org/html#update-the-image-data per spec.

Philip

[Simon Pieters]

On Mon, 03 Feb 2014 23:27:32 +0100, Yoav Weiss <yo...@yoav.ws> wrote:

> You're right that "immediate" is wrong according to the spec, but it
> seems
> that this is the way that it's currently implemented in Blink. From
> testing

> the setting of src and crossorigin <http://jsbin.com/OnOkuQE/1> in both

> orders, it seems that Blink, WebKit and IE send the request immediately,
> without waiting for stable state and as a result, images where src is set
> first are sent without an "origin" header. It's hard to tell for Gecko
> since it doesn't send an "origin" header even when crossorigin is set
> before src.
>
> So, I guess my question is "Who is wrong here?"

Yeah, everyone is wrong. :-(

> On the one hand, the specified behavior would be better for authors,
> enabling the setting of src, srcset and crossorigin in arbitrary order
> and
> receive the same results.

This is indeed the reason the spec is the way it is. I think it was
specified to await a stable state at the same time as the crossorigin
attribute was added to img, but it seems browsers implementing crossorigin
on img took shortcuts (Presto included).

> It'd also enable HTMLImageElement to be aware of
> its parent before triggering any resource requests, facilitating the
> implementation of picture's selection algorithm.

Indeed.

Note that the selection itself is sync, and if the selected image is in
cache, it is loaded immediately (e.g. getting .width in the same script
works). That is required for Web compat I think. This is step 7 in
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data

> On the other hand, no browser does that today.
>
> Should I open a bug regarding the current behavior in Blink?

I think that would be good.

--
Simon Pieters
Opera Software

[Yoav Weiss]

One more correction - that seems to have been fixed and Firefox nightly now sends the "origin" header on both requests.