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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu May 28 22:20:26 PDT 2015


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

--- Comment #13 from Ilya Grigorik <igrigorik at gmail.com> ---
(In reply to comment #12)
> > That would require that *all* images on the page contain correct values
> 
> As you acknowledge later, there is no problem when opt-in is per image (or
> per class when specified in CSS).
>
> > Further, as Yoav already pointed out, the same image can be served for different width & density combinations
> 
> The best way to handle that is via HTML/CSS sizing.

For both of the above comments, we can't rely on HTML/CSS sizing as "best" or only solution: both are optional and we need a solution that works for cases where neither is specified. Case in point, if I'm opening a direct link to the image, I expect it to be displayed correctly, and there is no HTML or CSS context there.. We need the client to advertise its desired DPR and server to confirm what is has provided.

> > we're talking about simple content negotiation
> 
> Content negotiation has been a huge failure on the Web, it just doesn't
> work. This is pretty well established common knowledge, which matches my
> experience too.

That's not true. Yes, there are cases where content negotiation was proposed for certain use cases but failed to gain adoption for various reasons, but this does not imply that the underlying mechanism is "broken". You're successfully using it to negotiate gzip'ed versions of text assets on this very page; it's being used (very successfully) to negotiate and deliver various new image formats (e.g. WebP, JPEG-XR), and so on. It works.

Stepping back.. the intent here is to help developers automate delivery of images. Markup based solutions are good to have, but there is no reason to force developers to write unnecessary boilerplate where client and server can use well-established mechanisms to do this on their behalf (and markup has its own limitations, as noted above). Better, automation + content-negotiation allows us to deliver an improved experience to all existing content without any code modifications - e.g. existing <img src=..> tags become DPR-aware without any changes. This is a win on all sides.

-- 
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/20150529/3680cc62/attachment.html>


More information about the webkit-unassigned mailing list