<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#c17">Comment # 17</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><span class="quote">> Standalone images are a rare case, and it is always possible to solve any problems with those by embedding them in an HTML document.</span >
Do you have data on "rare"? I expect the browser to behave correctly when I open an image in it, and its not unusual for users to share direct image links. My server can't magically wrap every direct image request (unknowable property since we can't count on Referrer) into an HTML document with appropriate size markup such that its displayed at correct resolution.
<span class="quote">> We had nearly exactly identical ideas implemented before, and the results were not pretty. The implementations continue to pollute the web platform long after they became unnecessary.</span >
Are you referring to images in particular? If so, what were those ideas and what were the results?
Last but not least, the fact that a markup solution is available (with known limitations, as described above) is not an argument that automation is unnecessary or not desired. We don't force iOS or Android developers to enumerate every resolution variant when an image is used -- both platforms rely on naming conventions to avoid exactly this pain. DPR request header + Content-DPR response header confirmation is the equivalent for web developers.</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>