[Webkit-unassigned] [Bug 145380] Add Content-DPR header support

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=145380

Ilya Grigorik <igrigorik at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |igrigorik at gmail.com

--- Comment #11 from Ilya Grigorik <igrigorik at gmail.com> ---
(In reply to comment #9)
> > If browsers would start taking the density data images have integrated into account now, current images (that have that data set to something) would have the wrong intrinsic dimensions, and current content which layout depends on image intrinsic dimensions would break, without any opt-in signals from the content's author.
> 
> This is a lot easier to resolve by adding an opt-in in HTML that would tell
> the engine to respect image dpi.

That would require that *all* images on the page contain correct values: if any image has this data missing, or is embedding incorrect values, then they would be rendered incorrectly. This is a non-starter given the vast volume of existing image content on the web that may or may not already have this metadata on it.. and much of which is not controlled by the origin that would enable this flag. You would have to introduce an entirely new (and consistent across all image formats) field, such that we can guarantee that its presence is a clear opt-in indicator that the display density should be adapted; we can't --safely-- piggyback on existing fields for this purpose.

Further, as Yoav already pointed out, the same image can be served for different width & density combinations.. which means that your HTTP server would now need to be able to read/write image meta-data on the fly, as opposed to writing out a simple response header -- first is expensive (read/modify image header) and requires new capability in each server, second is cheap, simple, and works on every existing server.

Last but not least, "width: 100%" is not a solution.. There are many cases where the display size is determined by the image itself, not by some outside container or explicit width value on it -- this is a valid and very common use case on the web (e.g. viewing image URL directly). In order for such images to be displayed correctly, we need an explicit "intended DPR" signal on the response.

In short, (1) the density opt-in needs to be per image, not per document (this breaks down for direct image view also), (2) it has to be "safe", (3) it needs to be cheap to generate at response time by the server, (4) we can't rely on developer-provided width / container width. As a result, the combination of all of these is, I believe, best met by the proposed Content-DPR response header.

> Adding such a signal at transport level does not make sense, it's not a
> feature of transport. Doing this would cause conflicts with loading
> infrastructure - http caches, appcache, blobs, service workers all need to
> be analyzed for potential issues, and for impact on future design
> directions, which is not an easy thing to do. 

This is not true, there are no conflicts here, we're talking about simple content negotiation [1] that has well established mechanisms: client advertises its capabilities via request headers; server selects optimal response variant based on provided request fields; server advertises properties of the response that dictate how it should be cached and processed by the client and any intermediaries. This is robust, widely used (e.g. gzip, format negotiation, etc), and nothing new.

[1] http://httpwg.github.io/specs/rfc7231.html#content.negotiation

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150528/767cdb7a/attachment.html>