New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`srcset`/`sizes` attributes for selectively preloading images #120

Open
kinu opened this Issue Jan 31, 2018 · 22 comments

Comments

Projects
None yet
9 participants
@kinu

kinu commented Jan 31, 2018

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

This comment has been minimized.

kinu commented Jan 31, 2018

@irori

This comment has been minimized.

irori commented Feb 15, 2018

  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

This comment has been minimized.

kinu commented Feb 19, 2018

@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

This comment has been minimized.

Contributor

domenic commented Feb 20, 2018

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

@cramforce

This comment has been minimized.

cramforce commented Feb 20, 2018

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

@irori

This comment has been minimized.

irori commented Aug 20, 2018

cc: @developit

@yoavweiss yoavweiss added the discuss label Aug 20, 2018

@Malvoz

This comment has been minimized.

Malvoz commented Aug 28, 2018

@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

This comment has been minimized.

kinu commented Aug 31, 2018

@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

This comment has been minimized.

Contributor

domfarolino commented Sep 25, 2018

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

This comment has been minimized.

Contributor

domenic commented Sep 25, 2018

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

@kinu

This comment has been minimized.

kinu commented Sep 25, 2018

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

@domfarolino

This comment has been minimized.

Contributor

domfarolino commented Sep 26, 2018

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

This comment has been minimized.

Contributor

domfarolino commented Sep 27, 2018

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 yoavweiss added this to the Level 2 milestone Oct 21, 2018

@yoavweiss

This comment has been minimized.

Collaborator

yoavweiss commented Oct 26, 2018

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

@toddreifsteck

This comment has been minimized.

Member

toddreifsteck commented Oct 26, 2018

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

This comment has been minimized.

Member

toddreifsteck commented Oct 26, 2018

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

@kinu

This comment has been minimized.

kinu commented Oct 26, 2018

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

This comment has been minimized.

Contributor

domfarolino commented Oct 26, 2018

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

This comment has been minimized.

Collaborator

yoavweiss commented Oct 27, 2018

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

This comment has been minimized.

cramforce commented Oct 29, 2018

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

@yoavweiss

This comment has been minimized.

Collaborator

yoavweiss commented Oct 29, 2018

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

This comment has been minimized.

Krinkle commented Oct 30, 2018

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment