Re: Behavior of device-pixel-ratio under zoom

On Fri, Oct 18, 2013 at 1:27 AM, Simon Pieters <simonp@opera.com> wrote:

> On Thu, 17 Oct 2013 23:36:38 +0200, James Robinson <jamesr@google.com>
> wrote:
>
>  See http://dev.w3.org/csswg/cssom-****view/#resizing-viewports<http://dev.w3.org/csswg/cssom-**view/#resizing-viewports>
>>> <htt**p://dev.w3.org/csswg/cssom-**view/#resizing-viewports<http://dev.w3.org/csswg/cssom-view/#resizing-viewports>
>>> >
>>>
>>
>>
>> That's great, but I think you should also specify that the
>> width/height/devicePixelRatio all change in the same task that dispatches
>> the resize event so authors can't see an inconsistent combination.  I.e.
>> if
>> I'm at 100x100 @ page zoom of 1.0 and then invoke my browser's page zoom
>> UI
>> to go to a page zoom of 2.0 while the page is actively polling these
>> values, it should only ever see 100/100/1.0 until the resize event fires
>> at
>> which point it should only see 50/50/2.0.
>>
>
> Why is it important for width/height/devicePixelRatio to not update until
> the resize event fires?


As a general principle, whenever there is a property change associated with
an event notifying the page of the change the property should be changed in
the same task that fires the event so that code that polls the property and
code that listens to the event always have the same view of the world.

In practice, implementations will generally behave this way without any
explicit text but it's important to put this down normatively so authors
can depend on it.



> Is it that scripts might assume that the page has responded to the change
> already if it sees a new value? Why is that a problem for devicePixelRatio
> but not for e.g. getComputedStyle?


getComputedStyle() should behave the same way.

- James


>
>
> --
> Simon Pieters
> Opera Software
>