Attributes imagesrcset and imagesizes attributes on <link>

[domfarolino]

HTML Standard-size changes for w3c/preload#120

TODO:

• Consider an obtain the preload resource override for obtain the resource under the Link type "preload" section, that:
  • Checks to see if as == image, and if so
  • Do some stuff similar to step 9 and below in update the image data (like calling the image selection algorithm etc)
  • Otherwise defer to general obtain the resource algorithm
• List imagesrcset and imagesizes mutations under appropriate times (PR is up)

Would appreciate some thoughts thus far; is this even the direction we want to go, i.e., making some of the algorithms in the images section fit the link element? /cc @zcorpan

---

/images.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/links.html ( diff )
/semantics.html ( diff )

[zcorpan]

How do we handle the picture case?

[domfarolino]

By picture case do you mean a link nested within a picture? If so, it seems <link> is not allowed to be nested in a <picture>, so I assume we just don't search for it as a parent, or its <source> children, in update the source set. If not, could you elaborate?

[eeeps]

Other way around; imgsrcset and imgsizes would allow authors to preload resources that will be encountered by browsers in <img srcset>, later; it would be nice to allow authors to preload resources that will be encountered in <picture>/<source>, too.

E.g., how can authors preload a resource for:

<picture>
<source media=“(min-width: 800px)” srcset=“big.jpg 1200w, small.jpg 600w”>
<img srcset=“cropped-big.jpg 800w, cropped-small.jpg 400w”>
</picture>

[tabatkins]

Presumably we can just use the pre-existing <link media>?

[eeeps]

Oh, of course.

And link type can cover source type cases too, I bet 🎉

[zcorpan]

So if you have

<link rel=preload as=image media="(min-width: 800px)" imagesrcset="big.jpg 1200w, small.jpg 600w">
<link rel=preload as=image imagesrcset="cropped-big.jpg 800w, cropped-small.jpg 400w">

How can you tell if this is one "picture" or two "picture"s?

[domfarolino]

Hmm, well I think it should not matter IIUC. The HTML in your example has potential of fetching two images, and I think any number of <img> or <picture> elements could fetch images that match the ones fetched + cached by the preloads? Or am I not understanding this correctly..

[eeeps]

The HTML in the example [edit: to clear up confusion – in the picture example!] will only load one image. The srcset from the first matching <source> is used; after a match, subsequent <source>s and the <img srcset> are discarded.

But, you could relatively-easily make your <link media>s mutually exclusive:

<link rel=preload as=image media="(min-width: 800px)" imagesrcset="big.jpg 1200w, small.jpg 600w">
<link rel=preload as=image media="(max-width: 799px)" imagesrcset="cropped-big.jpg 800w, cropped-small.jpg 400w">

But! I don't know how you could do the same thing for type...?

[domfarolino]

Gotcha. Yes it is a problem that the HTML @zcorpan provided will preload two images (assuming link media matches), even though the <picture> that both are intended for will only request one. So yeah, the link not having context of eventually-associated <picture>s can lead to a lot of unused preloads, which is quite bad for perf. Might be good to get some ideas on how to maybe make the association, so we don't have to tell devs to make their medias mutually exclusive in these contexts or something, just for the sake of being able to preload. (It'd be nice if the barrier for entry to preload responsive images were pretty low). Paging @irori for some ideas maybe, as he's recently worked on Chrome's impl.

[zcorpan]

How about adding a new as value? The processing of as=image would then look at previous siblings with as=source until a sibling is found that is not a link with as=source.

<link rel=preload as=source media="(min-width: 800px)" imagesrcset="big.jpg 1200w, small.jpg 600w">
<link rel=preload as=image imagesrcset="cropped-big.jpg 800w, cropped-small.jpg 400w">

[domfarolino]

Ok, so:

<link rel=preload as=source media="(min-width: 800px)" imagesrcset="a...">
<link rel=preload as=image imagesrcset="cropped-a...">
<link rel=preload as=source media="(min-width: 800px)" imagesrcset="b...">
<link rel=preload as=image imagesrcset="cropped-b...">
<link rel=preload as=source media="(min-width: 800px)" imagesrcset="c...">
<link rel=preload as=image imagesrcset="cropped-c...">

...would preload three images, because processing <link rel=preload as=source> would not load anything, and would only be considered upon processing the next <link rel=preload as=image>, as an upstream sibling.

I also imagine we should say that when rel=preload && as=source:

• href attribute must not be present, similar to what we do here for the source element
• imagesrcset attribute must be present, similar to what we do here for the source element.

Given this, it seems we'll need a new update the source set algorithm that also takes in <link rel=preload as=image>s, in addition to the new <link rel=preload as=image> "obtain the preload resource" algorithm override.

If this is a decent enough proposal, I guess we can start trying to gather other implementer interest.

[domenic]

I'm stuck in meetings and can't read the above in detail, but I did just want to point out that as values are supposed to map mostly-1:1 with request destinations. It may be better to use a new rel, instead of a new as. Especially if we're changing the semantics to not be always-a-fetch as preload currently is.

I might be totally off-base due to not having read the above comments enough, and if so I apologize, but I wanted to throw this out there before people went too far.

[zcorpan]

I think that makes sense @domenic.

[domfarolino]

Ah, that's a very good point, yeah as=source kinda breaks that destination mapping. A new rel is not a bad idea.

[zcorpan]

How about naming it preload-source?

<link rel=preload-source media="(min-width: 800px)" imagesrcset="a...">
<link rel=preload as=image imagesrcset="cropped-a...">
<link rel=preload-source media="(min-width: 800px)" imagesrcset="b...">
<link rel=preload as=image imagesrcset="cropped-b...">
<link rel=preload-source media="(min-width: 800px)" imagesrcset="c...">
<link rel=preload as=image imagesrcset="cropped-c...">

[irori]

The implicit grouping of <link>s (0 or more <link rel=preload-source>s followed by a <link rel=preload as=image> forms a group) feels a little strange to me, but I can't think of a better alternative.

Perhaps we should file a new issue about the <picture> use case in w3c/preload and discuss there, while we focus on "preload for standalone <img srcset>" use-case here?

[yoavweiss]

I don't think we should be grouping link elements together to try and mimic <picture>. IIUC, the same functionality can be achieved by using the media attributes, and "translating" picture's "first match wins" MQs into a set of mutually-exclusive MQs.

e.g. for

<picture>
    <source media="(max-width: 800px)" srcset="800px">
    <source media="(max-width: 1600px srcset="1600px">
    <img src="larger_than_1600">
</picture>

We'll use:

<link rel=preload as=image media="(max-width: 800px)" href="800px">
<link rel=preload as=image media="(min-width: 801px) and (max-width: 1600px)" href="1600px">
<link rel=preload as=image media="(min-width: 1601px)" href="larger_than_1600">

Does that make sense? Or am I overlooking something here?

[zcorpan]

That makes things more difficult for authors, it's not always easy or possible to make the MQ mutually exclusive. Also type is not mutually exclusive.

[yoavweiss]

Fair enough. type and "exotic" MQs do indeed make things more complex...

[chrisdavidmills]

Docs need recorded on MDN content roadmap — https://trello.com/c/6YAMGL3B/132-html-link-element

[domfarolino]

A bit less of a WIP now, but still have to work out the processing model for actually selecting and requesting the image.

[sideshowbarker]

heads-up @whatwg/documentation