[whatwg] Processing the zoom level - MS extensions to window.screen

[Henri Sivonen]

Charles Pritchard wrote:
> TV use-cases seem like they'll become more prevalent, with Apple and Google and their devices.

Apple TV doesn't have legacy connectors--only HDMI. A quick look at the specs of Google TV devices suggests that Google TV devices are also HDMI-only.

The devices sold as "TVs" these days have square pixels and are driven like the devices sold as "computer displays".

I think it makes no sense to assume that:
 1) People who want to use the Web on a device positioned as a "TV" want to do it using their legacy standard def TV that only has legacy inputs.
AND
 2) Hardware & browser vendors want to optimize APIs for legacy TVs with legacy inputs.
AND
 3) Web authors will obtain test systems that run a new browser optimized for a legacy TV together with an actual legacy TV and will carefully optimize their code for this case.

So I think exposing non-square pixels to Web content would be folly. It's useless to expose variable device characteristics to Web authors unless the characteristics vary so obviously from day one that even clueless authors are forced to realize that characteristics vary. See http://blogs.msdn.com/b/iemobile/archive/2010/11/22/the-ie-mobile-viewport-on-windows-phone-7.aspx

- -

I actually often run an up-to-date Web browser (Firefox trunk) using a device sold as a "TV" as the display, so I do appreciate the concern that <canvas> zooms badly. The easiest way to browse the Web (as it exists in reality) on a "TV" is to apply a zoom factor of 1.85 to CSS pixels. (The Web as it exists in reality is designed to work in a full-screen browser window on a 1024-pixel-wide screen and "TVs" are 1920 pixels wide.) I often wish that sites used SVG instead of <canvas> so that they'd Just Work without resampling artifacts with 1.85 zoom. 

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/