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

Placeholders #260

Open
yoavweiss opened this issue Mar 11, 2015 · 9 comments
Open

Placeholders #260

yoavweiss opened this issue Mar 11, 2015 · 9 comments

Comments

@yoavweiss
Copy link
Member

In http://ircbot.responsiveimages.org/bot/log/respimg/2015-03-05#T117041 we discussed adding some way for browsers to load a poor-quality image first, trigger onload, and then lazy-load a higher-res resource.

A similar concept is also being discussed in https://code.google.com/p/chromium/issues/detail?id=464849

I'm not yet sure what's the best form of that should be (opt-in/out, trigger onload for intermediate image, hold window.onload for high-res image, etc), but I think we should further discuss it.

@eeeps
Copy link

eeeps commented Mar 11, 2015

(Am I supposed to get a 403 Forbidden at the Chromium issue link?)

Why not just use JavaScript for this, like, say, NPR does now? The big reason I see: you don’t get to leverage the browser’s srcset picking logic for the upgrade, which is potentially much more intelligent/informed and almost certainly far more reliable than whatever you’re rolling on your own. If enough people want to do this, having a consistent, native way to do it seems appropriate.

I’ll hopefully note (while fully acknowledging that this is a sort-of-separate and certainly-more-complicated thing) that this seems like a perfect use-case for some kind of diff-based layering. I’ve been fiddling with Laplacian pyramids recently.

@yoavweiss
Copy link
Member Author

(Am I supposed to get a 403 Forbidden at the Chromium issue link?)

No you're not. I hope it'd get open to the public soon. (No idea why it was closed to begin with, but no permissions to open it myself)

@yoavweiss
Copy link
Member Author

Why not just use JavaScript for this, like, say, NPR does now? The big reason I see: you don’t get to leverage the browser’s srcset picking logic for the upgrade, which is potentially much more intelligent/informed and almost certainly far more reliable than whatever you’re rolling on your own. If enough people want to do this, having a consistent, native way to do it seems appropriate.

A ton of people are using JS for that. What we (ideally) want is for the browser to use its srcset info in order to lower a low-res placeholder (the 0.1x image, if you will) instead.

Again, not sure what the specifics should be, but I think we should discuss it.

I’ll hopefully note (while fully acknowledging that this is a sort-of-separate and certainly-more-complicated thing) that this seems like a perfect use-case for some kind of diff-based layering. I’ve been fiddling with Laplacian pyramids recently.

Yup. (to both it being perfect and more complicated :D )

@tabatkins
Copy link

I agree with this use-case, and think we should address it. Summarized, it's:

Provide a hint to the resource choosing algorithm that it should optimize for download speed rather than quality, choosing sources that are 1x or lower just to get something on the page. This then triggers asynchronous loading of the "normal" high-quality choice; whenever the resource pipeline isn't so contentious, it can go and fetch prettier versions of the image.

This needs to be an opt-in rather than an automatic behavior from the browser because some use-cases do want the high-quality image immediately; if you're going to draw it into a <canvas>, for example, you want the onload event to tell you when the "proper" resource is loaded, not the shitty .1x version.

@eeeps
Copy link

eeeps commented Mar 13, 2015

Do we need to wait for (or instigate) resource priorities work to start working on this?

This would pair nicely with the measuring-sizes-directly functionality that’s been tossed around as certainly useful but problematically racy, recently.

And let me put the cart before the horse and propose that if we end up using a markup token for this, it be named after lowsrc of yore.

@tabatkins
Copy link

I don't think this is tied to resource priorities.

I agree that having it tie into the sizes-based-on-layout functionality would be interesting; integrating it syntactically would probably be a good idea.

lowsrc doesnt' seem like a great idea to me; it implies that it should take a url as its value, when all we need is a flag indicating that the browser should choose a lower source from its existing source list.

@willstocks
Copy link

Hey guys - was anything ever finalised on this? I found myself trying to implement a lowres/LQIP <picture> placeholder the other day but couldn't work out how! Finding this, it seems it's not necessarily possible currently?

@eeeps
Copy link

eeeps commented Sep 3, 2019

@willstocks nothing has been done here (yet) on the spec side of things; there's still no native way to serve a low-quality image placeholder.

You can still use picture and Javascript, though: https://codepen.io/eeeps/pen/KKPyPvy

@Malvoz
Copy link

Malvoz commented Oct 8, 2019

There's a WHATWG issue for placeholders here: whatwg/html#3631.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants