Design Review #329

#329: imagesrcset and imagesizes attributes on link rel=preload

Visit on Github.

Opened Nov 29, 2018

こんにちはTAG！

I'm requesting a TAG review of:

Name: imagesrcset and imagesizes attributes on link rel=preload
Specification URL: https://github.com/whatwg/html/pull/4048 and https://github.com/w3c/preload/pull/134
Explainer, Requirements Doc, or Example code: Explainer
Tests: https://github.com/web-platform-tests/wpt/pull/9595, https://github.com/web-platform-tests/wpt/pull/14231
Primary contacts: @irori, @domfarolino, @kinu

Further details (optional):

Relevant time constraints or deadlines: we plan to ship this in Chrome 73, which branches in late-Jan 2019 and ships in March.
I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is no difference from existing link rel=preload.
I have reviewed the TAG's API Design Principles

You should also know that...

Two issues have been raised in the past discussions:

<picture> use-case: It's not always easy or possible to create a set of <link rel=preload>s whose selection logic is equivalent to a <picture> element. This was discussed at TPAC 2018, and a summary is here.
Preloads that depend on viewport dimensions would need to be delayed until the end of the <head> tag, where the viewport is locked. (This is not an issue specific to imagesrcset/imagesizes, since preload can have media attribute.) That means most imagesrcsets cannot be preloaded just by preprocessing HTTP headers. We plan to discuss the viewport issue separately from this one.

We'd prefer the TAG provide feedback as (please select one):

open issues in our Github repo for each point of feedback
open a single issue in our Github repo for the entire review
leave review feedback as a comment in this issue

cc: @yoavweiss

Discussions

Comment by @foolip Jan 15, 2019 (See Github)

FYI, there is now an Intent to Ship: imagesrcset and imagesizes attributes on <link> on blink-dev.

Comment by @dbaron Jan 22, 2019 (See Github)

I think that given <link rel=preload as=image> these are probably reasonable -- the biggest question is to what extent we've thought about that (maybe in #202).

@hober also mentioned in today's teleconference the existing sizes attribute and whether a new one is needed.

Comment by @eeeps Jan 24, 2019 (See Github)

@hober @dbaron I can't find any mention of sizes in the minutes, can you elaborate on what was said / your thoughts?

Comment by @hober Jan 25, 2019 (See Github)

@eeeps, I was simply wondering if a separate imagesizes attribute is really needed, given that link already has a sizes attribute that is probably sufficient for the task.

Comment by @domfarolino Jan 26, 2019 (See Github)

Here is some previous conversation on why sizes might be tricky to use here: https://github.com/w3c/preload/issues/120#issuecomment-365814332

Comment by @annevk Jan 28, 2019 (See Github)

The TL;DR is that the syntax is vastly different, which I think is reason enough to use a new attribute for. Overloading one attribute with two syntaxes usage of which depends on other attributes seems rather complex. It might be worth having some notes that point this out in the link element section as some of the syntax stuff is defined elsewhere.

Comment by @travisleithead Feb 6, 2019 (See Github)

Thanks for raising this issue!

In general, we're pretty happy with how this is looking given the existing patterns for preloading that already exist in the platform.

At the same time, we have a related set of larger concerns with preloading of resources containing other resources (e.g., style sheets, ES/WASM modules), as well as the disparate ways and techniques for pre-loading of various content. This is not something we expect you to address in your work, but something we'd like to see harmonized at some point in the future.

Again, we appreciate having the chance to review, and we hope you consider us in the future!