srcset/sizes attributes for selectively preloading images

[kinu]

It seems useful if sites can specify srcset and sizes attributes for preloading images, like what we have for img tag, so that responsive images can still appreciate the power of preloading.

One immediate concern we could imagine is that link element already has the sizes attribute for rel=icon cases. There will be at least two options to address this:

1. Make sizes attribute have different meanings depending on the rel= attribute.
2. Add a slightly-different name to it to avoid conflict with the existing one.

[kinu]

/cc @jyasskin @KenjiBaheux @cramforce

[irori]

1. Make sizes attribute have different meanings depending on the rel= attribute.

This seems to be tricky.

sizes is exposed as an attribute of HTMLLinkElement, of type DOMTokenList, which is a set of space-separated tokens. The sizes attribute of HTMLImageElement is a DOMString, and has quite different syntax.

[kinu]

@irori thanks I didn't realize that. This might give an additional motivation to go with option 2. (while naming is hard). What could be a candidate name for this option-- say, imgsizes?

We could still go with something like attribute (DOMString or DOMTokenList) rel, but implementation will get a bit more awkward.

(Would anyone have any thoughts? We plan to experiment this in chromium)

[domenic]

It might be nice to align the names, so that they're e.g. imgsizes + imgsrcset.

[cramforce]

Using image in as and img* elsewhere is a bit unfortunate.

[irori]

cc: @developit

[Malvoz]

@yoavweiss

In issue #127 it seems it was concluded that to avoid complexity on developers when matching the hash of a preload against an element with the integrity attibute one would not need to duplicate the hash in the preload <link>/header field.

Would that approach be applicable for matching preloads against images with sizes|srcset aswell?

[kinu]

@Malvoz

Do you have particular proposal for not duplicating some values?
For integrity the attribute value is used for computing for verification, while sizes|srcset are used for choosing the best matching resource to fetch, so dropping some params may result in double-fetching different resources. It seems replicating the same parameters is just easy and safe to me.

[domfarolino]

Are we comfortable moving forward with imgsrcset and imgsizes? This seems to be a good enough pair to me. I imagine we could change Chrome's experimental impl accordingly

[domenic]

Probably "imagesizes" and "imagesrcset" to match the as=image, as Malte pointed out.

[kinu]

imagesizes and imagesrcset sound good to me. (While no strong opinion on whether they should be img* or image*)

[domfarolino]

FYI I've posted whatwg/html#4048 as a start to the HTML-side of changes that'll like need made for this. The changes in this spec should be pretty trivial.

[domfarolino]

A pretty good point has been brought up in that thread (summarized here) about how in the current setup, this can lead to a lot of unused image preloads, since <link rel=preload as=image>s don't know anything about <picture>s that the images they're fetching may be nested under (thus some of the preloads may never be fetched, as per spec). This might be bad for perf.

[yoavweiss]

Sample code:
<link rel=preload as=image imagesrcset="100w.jpg 100w, 200w.jpg 200w" imagesizes="(max-width: 600px) 50vw, 600px">

[toddreifsteck]

Discussed at TPAC 2018. Here is a rough summary from my recollection. Please refer to minutes on Web Perf WG mailing thread for more accurate summary.

• Real web sites have seen impact from this missing behavior where they cannot use preload for hero images. These were not listed so it was not possible for attendees to see data. It would be ideal if data is presented. If real web sites need this AND this can be specified in a way that gets these web sites a beneift, the room agreed we should solve this.
• Adding this adds some complexity due to the need to queue a list of downloads if preload tags occur before the end of the head due to when viewport is locked.
• Per @rniwa, waiting on viewport to be set raises a question about whether this should be supported as a workaround of ensuring the image is in a 1 pixel div as first item in body.
• @yoavweiss Can you reply on your thoughts on the benefit of implementing this given the potentially minor improvement provided vs known workarounds?

[toddreifsteck]

Ryosuke's statement was about picture... I misquoted him here... but his comment also applies to whether we should specifiy and implement this. :-)

[kinu]

I think the summary (from the minutes) was like:

• For imagesrcset we have use-cases (e.g. hero images and Wikipedia logo cases)
• For picture the concrete use-cases are unclear and the necessary addition to the spec and impl seems relatively high
• Opinion: go ahead with the srcset but for imgs, punt on this for now, until there are more concrete use-cases. Developers can use media-query hacks today.

[domfarolino]

Thanks for the summaries! A few questions/points:

(quoted from #131 (comment))

Even when that need is reported, we believe it is likely to attempt to solve it by simpler modifications to preload than adding full picture capabilities.

Any idea what simpler modifications to preload anyone had in mind? Curious. Also as per @kinu's points, just to be clear, my take is that we're continuing with imagesrcset and imagesizes proposal on <link rel=preload as=image>, but not bothering to specify the relationship between multiple as=image preloads and later <picture>s (since devs can use media-query hacks to forge this relationship). Is this accurate?

[yoavweiss]

Also as per @kinu's points, just to be clear, my take is that we're continuing with imagesrcset and imagesizes proposal on <link rel=preload as=image>, but not bothering to specify the relationship between multiple as=image preloads and later <picture>s (since devs can use media-query hacks to forge this relationship). Is this accurate?

This is indeed accurate.

imagesrcset/imagesizes

There is some added complexity as the browser would need to know the final viewport dimensions when it preloads the image, at least for w descriptor based images. That means that in terms of implementations, those preloads would need to be delayed until the <head> was preprocessed (even if the links were delivered as headers).

At the same time, there were clear use-cases presented (e.g. wikipedia) and the added complexity doesn't seem huge. Therefore the group decided that it makes sense to go forward with the proposed solution.

<picture>-like selection logic

We debated a few options to implement, but didn't see a clear option that doesn't add a lot of complexity. At the same time, it's not clear that there is strong developer demand for the feature. So the group decided that it's worthwhile to wait for such demand to surface before trying to tackle the use-case further.

In the mean time, at least for the art-direction use-case, developers can use mutually exclusive MQs to hack their way towards a solution. We also acknowledged that for the image format based selection use-case cannot currently be fully addressed.

[cramforce]

@yoavweiss Would it make sense to create a http-header version of the viewport meta tag?

[yoavweiss]

Potentially. As @domfarolino pointed out elsewhere, the need to hold the preloads until the viewport is known is not unlike how preload works today when the media attribute is defined.

A header based viewport definition may make sense, but seems orthogonal.

[Krinkle]

Thanks @gi11es for revisiting this. For the record, this was previously discussed at #31.

Wikipedia's current preload approach involves an inelegant media query. The details of which are documented at #31 (comment).

[Malvoz]

@cramforce

Would it make sense to create a http-header version of the viewport meta tag?

https://discourse.wicg.io/t/proposal-viewport-http-header/3233

[domenic]

HTML spec change merged!