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

[bugzilla-daemon at webkit.org]

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

--- Comment #7 from Alexey Proskuryakov <ap at webkit.org> ---
(In reply to comment #6)
> If you are referring to the density info that images contain (e.g.
> http://www.w3.org/TR/PNG/#11pHYs and the Xdensity, Ydensity in JFIF's APP0
> marker), these seem to be largely ignored by both browsers and desktop image
> viewers, which means we cannot start supporting them without breaking
> content. 

What is the specific case that concerns you? Browsers ignore the Content-DPR header field too.

> Also, since the same image can be served in different width & density
> combinations, I'd say baking this info into the image is not ideal. (e.g. a
> 600px wide image that is displayed over the entire viewport can be served to
> a 1x, 600px wide screen or to a 2x, 300px wide screen)

What is the use case for that? One can just use CSS to stretch to 100%.

> FWIW, the header we're discussing here does the same thing that srcset's
> descriptors are already doing in markup across all modern browsers.

This also sounds like an argument against it. The distinction between markup and transport layer data is intentional, and when there are multiple ways to achieve the same thing, that invariably causes complications.

This is like the Munchkin game - game rules say one thing, text on a card says another, someone plays a card that reverses all the rules, and conflicts are officially resolved by who yells the loudest... It's fun, but why would anyone want browsers to work like that?

-- 
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/85b904f3/attachment.html>