<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Add Content-DPR header support"
href="https://bugs.webkit.org/show_bug.cgi?id=145380#c13">Comment # 13</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Add Content-DPR header support"
href="https://bugs.webkit.org/show_bug.cgi?id=145380">bug 145380</a>
from <span class="vcard"><a class="email" href="mailto:igrigorik@gmail.com" title="Ilya Grigorik <igrigorik@gmail.com>"> <span class="fn">Ilya Grigorik</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=145380#c12">comment #12</a>)
<span class="quote">> > 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).</span >
>
<span class="quote">> > 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.</span >
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.
<span class="quote">> > 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.</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>