- From: James Robinson <jamesr@google.com>
- Date: Thu, 17 Oct 2013 14:36:38 -0700
- To: Simon Pieters <simonp@opera.com>
- Cc: www-style <www-style@w3.org>, "Robert O'Callahan" <robert@ocallahan.org>
Received on Thursday, 17 October 2013 21:37:06 UTC
On Thu, Oct 17, 2013 at 2:23 PM, Simon Pieters <simonp@opera.com> wrote: > On Thu, 17 Oct 2013 18:53:25 +0200, James Robinson <jamesr@google.com> > wrote: > > Thanks Simon. This looks great to me. I think it'd be worth noting >> somewhere (not entirely sure where) that changes to the page zoom fire a >> resize event, since they change the size of the viewport in CSS pixels, >> and >> so authors that want to react to page zoom can simply listen to the window >> resize event and take a look at devicePixelRatio. I don't see a >> processing >> model for page zoom defined anywhere, although that'd be the ideal place >> to >> put this. >> > > See http://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. - James > > -- > Simon Pieters > Opera Software >
Received on Thursday, 17 October 2013 21:37:06 UTC