Skip to content
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

imagesrcset and imagesizes attributes on link rel=preload #329

Closed
irori opened this issue Nov 29, 2018 · 7 comments
Closed

imagesrcset and imagesizes attributes on link rel=preload #329

irori opened this issue Nov 29, 2018 · 7 comments
Assignees

Comments

@irori
Copy link

@irori irori commented Nov 29, 2018

こんにちはTAG!

I'm requesting a TAG review of:

Further details (optional):

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

@foolip

This comment has been minimized.

Copy link

@foolip foolip commented Jan 15, 2019

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

@plinss plinss added this to the 2019-02-05-f2f milestone Jan 22, 2019
@travisleithead travisleithead self-assigned this Jan 22, 2019
@dbaron

This comment has been minimized.

Copy link
Member

@dbaron dbaron commented Jan 22, 2019

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.

@dbaron dbaron self-assigned this Jan 22, 2019
@eeeps

This comment has been minimized.

Copy link

@eeeps eeeps commented Jan 24, 2019

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

@hober

This comment has been minimized.

Copy link

@hober hober commented Jan 25, 2019

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

@domfarolino

This comment has been minimized.

Copy link

@domfarolino domfarolino commented Jan 26, 2019

Here is some previous conversation on why sizes might be tricky to use here: w3c/preload#120 (comment)

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented Jan 28, 2019

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.

@torgo torgo added the extra time label Feb 5, 2019
@travisleithead

This comment has been minimized.

Copy link
Contributor

@travisleithead travisleithead commented Feb 6, 2019

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.