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

[bugzilla-daemon at webkit.org]

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

--- Comment #8 from Yoav Weiss <yoav at yoav.ws> ---
> What is the specific case that concerns you? Browsers ignore the Content-DPR header field too.

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.

Now, browsers also ignore the Content-DPR header, but since there's practically zero existing content out there with that header, that's not an issue. The Content-DPR header would be an opt-in signal for the browser to take the provided density into account.

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

Yes, CSS overrides intrinsic dimensions. That doesn't mean that intrinsic dimensions are not useful when CSS is missing (because the image was accessed directly, or because the author didn't bother, which happens quite often).

> 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.

Which complications would this cause? The relationship here between srcset and the Content-DPR header is well defined. srcset's descriptor is applied, unless the server-side have overridden it, using Content-DPR.

That enables automatic image resizing (with either srcset or Client-Hints) without taking styling info into account, which adds significant complexity. Content-DPR enables the server-side to adapt the intrinsic dimensions to those of the original image, so that if layout relies on them, it will not break.

> 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?

I'm not familiar with that game.

-- 
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/cacbfa9b/attachment-0001.html>