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

On Nov 22, 2013, at 11:40 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

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

You're free to make your own judgments but that doesn't mean everyone has to be ok with it.

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

When we first invented devicePixelRation, we thought the point was to expose the device's intrinsic ratio of CSS pixels to device pixels, rather than the ratio as affected by a temporary or page-local zoom factor. I wish the feature with a different point had been given a different name.

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

In Safari, page zoom is currently not persistent per domain or per UA at all, so it doesn't match your assumption. Does that mean we are actually correct not to factor it in?

I want to mention also that devicePixelRatio is not just for image density decisions. You need it most for density decisions that are not about bitmap images, such as the canvas case I mentioned.

The canvas problem (where you have to deal with non-integer ratios when you really want to scale your backing store by an integer only) is a real issue, and an ongoing annoyance to developers


Fundamentally, it seems like all the sources of zoom really need to be exposed separately, since they have different properties. Having a dPR that includes page zoom makes it impossible to exclude page zoom. Exposing both separately (or both hardware-only and hardware*page zoom) lets you do either.


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

Did you consider the canvas case?

Did you consider UI where the page is only ever zoomed after initial load?

Regards,
Maciej

Received on Friday, 22 November 2013 19:56:47 UTC