More Hell for Web Developers

Dave Hyatt, chief architect of Safari and WebKit, outlines a proposal to solve the “high-DPI” problem:

Consider a Web page that is designed for an 800×600 resolution. Let’s say we render this Web page such that the pixels specified in CSS (and in img tags and such on the page) map to one pixel on your screen.

On a screen with 1920×1200 resolution the Web site is going to be tiny, taking up < 50% of the screen's width and half the screen's height. In terms of absolute size, the text will be much smaller and harder to read.

Now this may not be a huge problem yet, but as displays cram more and more pixels into the same amount of space, if a Web browser (or any other application for that matter) naively continues to say that one pixel according to the app’s concept of pixels is the same as one pixel on the screen, then eventually you have text and images so small that they’re impossible to view easily.

How do you solve this problem?
The natural way to solve this “high DPI” problem is to automatically magnify content so that it remains readable and easily viewable by the user. It’s not enough of course to simply pick a pleasing default, since the preferences of individuals may vary widely. An eagle-eyed developer may enjoy being able to have many open windows crammed into the same amount of space, but many of us would like our apps to remain more or less the same size and don’t want to have to squint to read text.

The full solution to this problem therefore is to allow your user interface to scale, with the scale factor being configurable by the user. This means that Web content has to be zoomable, with the entire page properly scaling based off the magnification chosen by the user.

Much more detail in the post, including elaborations on questions such as, “What the heck is a CSS px anyway? Most Web site authors have traditionally thought of a CSS pixel as a device pixel.” Yup, I sure have.