Re: [whatwg] High-density canvases

On 11 Sep 2013, at 6:13 am, Ian Hickson <> wrote:

> On Wed, 11 Sep 2013, Dean Jackson wrote:
>> On 11 Sep 2013, at 5:32 am, Ian Hickson <> wrote:
>>> On Wed, 11 Sep 2013, Dean Jackson wrote:
>>>> On 11 Sep 2013, at 12:14 am, Stephen White <> 
>>>> wrote:
>>>>> now that some browsers are including browser zoom (page zoom) in 
>>>>> window.devicePixelRatio
>>>> Ouch. Who is doing this and why?
>>> Why ouch?
>> Because weíve always operated under the assumption that devicePixelRatio 
>> is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that 
>> it is constant for a particular display. The only change content would 
>> see is if the window is dragged to/from a high resolution screen.
>> There are other ways to query the page zoom.
> That seems broken... why would you want to hide the page zoom?

We donít want to hide page zoom.

I think there are two separate things a developer might want:

- the number of actual pixels that correspond to 1 CSS px without zoom
- the page zoom

If you merge the two, then an unsuspecting developer might think that the user has zoomed in by 2x on an iPhone, and decide to make things smaller. Yes, thatís not necessarily great content, but it makes some sense. For most page content you donít really care about the device:pixel ratio - text looks fine! For images, you should use the mechanisms weíve developed (srcset and image-set).

Now, I completely agree that there are going to be cases where you might want the image selected for srcset and image-set to respond to zoom. After all, there is no point loading a huge image if it is going to be 1x1 cm^2. But I think thatís separate from changing devicePixelRatio.

>> I fear this will break existing content. I donít think weíd ever want to 
>> change the behaviour.
> I guess we'll just have to treat devicePixelRatio as legacy and introduce 
> a new value that's the real device:pixel ratio, then.

Indeed. Iím not opposed to exposing this. I am reluctant to change something that has behaved a particular way for a number of years.

Meanwhile, back to canvas, why donít we change canvas to be purely callback based, and pass in all the info a developer needs to decide what the best output should be? Put something like requestAnimationFrame into the canvas spec (although that is a bad name - it only sometimes is related to animation). That way you could even imagine a future where a single canvas could have multiple render targets (when printing you get an even higher resolution).


Received on Tuesday, 10 September 2013 20:23:35 UTC