W3C home > Mailing lists > Public > www-style@w3.org > November 2013

Re: [mediaqueries] resolution and device-pixel-ratio

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 22 Nov 2013 11:40:25 -0800
Message-ID: <CAAWBYDAcofxxoVWrQShcUsJHiqPZj0vXrbA-MqFbepJSTba=kw@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Jonathan Kew <jfkthame@googlemail.com>, www-style list <www-style@w3.org>
On Fri, Nov 22, 2013 at 11:06 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Nov 14, 2013, at 4:41 AM, Jonathan Kew <jfkthame@googlemail.com> wrote:
>> If it was possible and acceptable for Blink to change in order to conform to the agreed standard for device-pixel-ratio (realizing that some content could be affected), shouldn't it be possible for Safari to do the same?
>> How much content would "break" as a result, and how bad is said "breakage"?
> I'd guess the worst case is pages that attempt to size a canvas and get a non-integer multiple of the base resolution when they expected an integer. This could cause drawing to be completely garbled. Note: I have not tried to find content where this actually happens and I don't know for sure that it exists.
>> If the main result is that some pages may fail to use the optimum-resolution bitmap assets in certain cases - e.g. when page-zoom is not 100% - but otherwise continue to work, ISTM that may be a reasonable price to pay for converging on a single standard instead of leaving a non-standard, incompatible implementation to pollute the web indefinitely.
> Would you favor changing the spec and the non-Safari implementations to match Safari instead? That would also achieve the goal of converging on a single standard.
> The reason matching only the 1:1 zoom CSS pixel ratio makes sense is:
> (1) Most content using devicePixelRatio was originally created with iOS in mind, and therefore would not expect the page zoom to be factored in, since on iOS there is no page zoom.

That would affect everyone equally, and we're so far okay with eating
that compat cost in Blink.

> (2) If the value is based on 1:1 zoom, then it won't change over time on the same page.

Page zoom is constant in *nearly* all cases as well.

> (3) It seems weirdly inconsistent to factor in page zoom but not pinch zoom (and pinch zoom really can't be factored in due to #1).

The point of dPR is to tell you how many device pixels map to a single
CSS pixel.  Page zoom affects this ratio in the exact same way as
actual hardware resolution does - higher zoom means more hardware
pixels in a single CSS pixel.  The viewport is reduced accordingly
with that ratio.

Pinch zoom does *not* do this.  It changes the ratio, but pretends it
didn't, so the viewport is still the same size as always.

There's also different usage assumptions behind them.  Page zoom is
rarely changed; typically set once per domain or once per UA, and then
not adjusted again.  Pinch zoom is changed constantly, back and forth,
in a continuous way.  Basing any image-density decisions on a value
that is constantly fluctuating would be terrible.

> I realize there's arguments either way, but if a value with the page zoom factored in is useful, then surely it could have another name instead of conflicting.
> (Though for the record, what are the reasons to include the page zoom? If they are documented elsewhere, a pointer would be sufficient.)

Assuming the page has already been zoomed in to the user's preference,
then every single use of dPR we could think of actually wanted
hardware density * page zoom.  Using just hardware density produced
worse results in every situation.

Received on Friday, 22 November 2013 19:41:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:16 UTC