Intent to Ship: imagesrcset and imagesizes attributes on <link>

[Kunihiko Sakamoto]

Contact emails

ksak...@chromium.org, d...@chromium.org, kin...@chromium.org

Explainer

https://docs.google.com/document/d/1wob4u9AER1kmUodqIEp78BuziSJChBl54A5ZRXPRCUI/edit?usp=sharing

Spec

whatwg/html: https://github.com/whatwg/html/pull/4048

w3c/preload: https://github.com/w3c/preload/pull/134

TAG review: https://github.com/w3ctag/design-reviews/issues/329

Summary

Add imagesrcset and imagesizes attributes to <link rel=preload as=image>, that correspond to the srcset and sizes attributes of HTMLImageElement, so that responsive images can still appreciate the power of preloading.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/8tVgAyS47y0/e9L-NbatBwAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://irori.github.io/imagesrcset-demo/

Debuggability

Preloaded images appear in the devtools network panel, and the "Initiator" column references the <link rel=preload> element that initiated the image loading.

Risks

Interoperability and Compatibility

Medium. Blink will be the first to ship this feature.

Edge: No public signals

Firefox: No public signals (bug)

Safari: No public signals (bug)

Web developers: Positive signals from the AMP team

This has been discussed in webperf WG at TPAC 2018 (summary), and there were people from Microsoft / Safari / FireFox too.

Browsers that support preload but do not understand imagesrcset/imagesizes attributes would continue to preload the resource specified with the href= attribute.

Ergonomics

This will be used along with images featuring srcset / sizes attributes.

Activation

To take advantage of this feature, developers just need to add link preload headers for key images, e.g. hero image, and re-use existing srcset and sizes attributes with slight name changes. For backward compatibility, developers would just use the existing href attribute set on their key images.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. https://wpt.fyi/results/preload?label=experimental&q=srcset

Entry on the feature dashboard

https://www.chromestatus.com/features/5164259990306816

[Daniel Bratell]

It looks like the spec change is based on, and blocked by, https://github.com/whatwg/html/pull/4031 which isn't quite finished (but maybe quite soon). Is this implementation based on an earlier draft of that, or what is the relation, if any? In general it looks like a good change to solve a real problem.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO5vZCgwKpG5XfTwF20dZbzTmteMZsetmO%3DjaGJCg7ZrYZ%3D6Lg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Dominic Farolino]

The relationship between the two changes is not mechanical, and is more-so the result of unfortunate timing :) In #4048 (spec PR for this feature) I introduce "obtain the preload resource" algorithm, however #4031 introduces more general infrastructure for different link types to provide their own algorithms (a preload-specific obtain algorithm, for example). #4048 is blocked on #4031 because it can utilize its naming infra, is all. No normative implementation difference; hopefully that clears it up, and apologies for any confusion.

[Kunihiko Sakamoto]

Yeah, the blink implementation was done before https://github.com/whatwg/html/pull/4031 was written, but I think no implementation change is needed based on that.

Kunihiko Sakamoto

2019年1月15日(火) 13:36 Dominic Farolino <domfa...@gmail.com>:

The relationship between the two changes is not mechanical, and is more-so the result of unfortunate timing :) In #4048 (spec PR for this feature) I introduce "obtain the preload resource" algorithm, however #4031 introduces more general infrastructure for different link types to provide their own algorithms (a preload-specific obtain algorithm, for example). #4048 is blocked on #4031 because it can utilize its naming infra, is all. No normative implementation difference; hopefully that clears it up, and apologies for any confusion.

On Friday, January 11, 2019 at 9:49:04 AM UTC-5, Daniel Bratell wrote:

It looks like the spec change is based on, and blocked by, https://github.com/whatwg/html/pull/4031 which isn't quite finished (but maybe quite soon). Is this implementation based on an earlier draft of that, or what is the relation, if any? In general it looks like a good change to solve a real problem.

/Daniel

[Philip Jägenstedt]

LGTM2

Thanks for clarifying the PR dependency. Often intents are treated as blocked on spec PRs actually being merged, but here https://github.com/whatwg/html/pull/4048 is approved and to be rebased on something that doesn't change behavior, so that doesn't seem warranted here.

Looking at https://wpt.fyi/results/preload?label=experimental&q=srcset I see that there's a wpt.fyi bug. In a meantime, https://staging.wpt.fyi/results/preload?sha=5c708fbf40&label=experimental&q=srcset shows recent results. Can you check if the link-header-preload-srcset.tentative.html failure is expected?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO5vZCiMY1NMuv-1Ek7UGNiSrNrPKC8kjnDgp3RooirLCvczCw%40mail.gmail.com.

[Philip Jägenstedt]

That should have been LGTM1 :)

[Daniel Bratell]

LGTM2 from me.

/Daniel

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zvnqysnorbppqq%40cicero2.linkoping.osa.

[Kunihiko Sakamoto]

Thanks for the LGTMs!

The failure of link-header-preload-srcset.tentative.html on wpt.fyi is a test code side issue, and will be fixed soon (https://crbug.com/922343).

2019年1月16日(水) 5:20 <lukebj...@google.com>:

wpt.fyi now includes results which come from PRs, so the link for test results should contain the "master" label, i.e. https://wpt.fyi/results/preload?labels=master,experimental&q=srcset

Sorry for any confusion caused.

[lukebj...@google.com]