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.

Sign up for GitHub

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

Jump to bottom

imagesrcset and imagesizes attributes on link rel=preload #329

Closed
3 of 5 tasks
irori opened this issue Nov 29, 2018 · 7 comments
Closed
3 of 5 tasks

imagesrcset and imagesizes attributes on link rel=preload #329

irori opened this issue Nov 29, 2018 · 7 comments
Assignees
@hober @dbaron @travisleithead
Milestone
2019-02-05-f2f

Comments

@irori
Copy link

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
Copy link

foolip commented Jan 15, 2019 •
edited
Loading

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
Copy link
Member

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
Copy link

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
Copy link
Contributor

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
Copy link

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

@annevk
Copy link
Member

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.

@travisleithead
Copy link
Contributor

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
Assignees

@hober hober

@dbaron dbaron

@travisleithead travisleithead

Labels
None yet
Projects
None yet
Milestone
2019-02-05-f2f
Development

No branches or pull requests
10 participants
@hober @irori @dbaron @torgo @foolip @annevk @travisleithead @plinss @eeeps @domfarolino