Contact emails
scli...@chromium.org, be...@chromium.org
Spec
Design doc: https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzpnqO2EqkgGD3T0O-pQ08/edit#
Summary
Add support to Blink for removing or postponing image loads while preserving page layout. To achieve this, support issuing range requests for just the first few bytes of images, and then attempt to extract the image dimensions from these chunks and display placeholders with the same dimensions in their place.
This support will not be activated by default, and there will be no impact to the regular path of loading images.
Motivation
Allow other features to activate this support in order to save data for users.
Potential use cases of this functionality in Chromium include:
Interoperability and Compatibility Risk
No risk.
Ongoing technical constraints
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
No OWP launch tracking bug, since this is just adding low-level support that will be used by higher-level features to be implemented later, but the crbug is https://crbug.com/605350.
Requesting approval to ship?
No. This is just adding low-level support that will be used by higher-level features to be implemented later.
A couple quick questions about how this is observed by web content (once it's used by Data Saver or some other feature, naturally):
1. Does the load event fire on an <img> when the placeholder loads, or when the original image loads?
2. If a script accesses the image (for example, by drawing it into a CanvasRenderingContext2D), does it see the placeholder image or does it act as though the image has not yet loaded?
--
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+unsubscribe@chromium.org.
Why will the Data Saver not implement it at its layer and then Blink will just really get those placeholders from the server (the proxy)?
I like this for a reason that wasn't mentioned:
- We can raster a tile that doesn't have the image decoded yet. Later, we can swap in the decoded image. Since image decodes are slow, that tile waits an uncomfortably long time.
I am curious about the load event though. Some sites use this to know when an image has been completely downloaded before displaying it, right? Wouldn't that be broken?
The image replacement support referred to by this intent to implement would offer a means of showing image placeholders that doesn't require a proxy, and thus would work for https:// resources.
The image replacement support referred to by this intent to implement would offer a means of showing image placeholders that doesn't require a proxy, and thus would work for https:// resources.I know that this is not in the scope of this intent, but does that mean enabling the data saver mode would result in images getting replaced in HTTPS pages too? I do not think developers would be very comfortable with that.
That would break the window load event promise, though, right? It makes more sense to fire the error event if the image is never going to be loaded, I think.
This depends on what the use case for image replacement. I think we will need both to satisfy consumers of this feature.If the image will never load by design we should fire the error event, otherwise e.g. for deferred loading cases I think it makes sense to simulate a slow load.On Wed, Aug 24, 2016 at 5:52 PM, Rick Byers <rby...@chromium.org> wrote:On Wed, Aug 24, 2016 at 4:13 PM, PhistucK <phis...@gmail.com> wrote:That would break the window load event promise, though, right? It makes more sense to fire the error event if the image is never going to be loaded, I think.Yeah that's probably even more web-compatible (although hopefully most pages are already mostly usable well before every single image has finished loading).
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
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.