Re: pixel-based vs. real-word-pased units

On 9/11/06, Peter Sorotokin <psorotok@adobe.com> wrote:
>
> If CSS spec meant to say that 96px is *always* equal to 1inch (or that
> 1inch is always equal to 96 pixels which seems like the more common
> definition of an inch in today's browsers) it should have just said that
> instead of going through the complex explanations about arm length and
> so on. If it did not mean to say that, test suits should not be written
> with that assumption.

You are correct that the CSS2.1 test suite assumes that the OS is
configured to believe that the display is either a 96dpi display, or a
display whose resolution is "very different from that of a typical
computer display". It makes a series of other assumptions as well,
including the following:

 * The device is a full-color device.
 * The device has a viewport width of at least 640px (approx).
 * The 'medium' font-size computes to 16px.
 * The initial value of 'color' is black.
 * The canvas background is white.
 * The user stylesheet is empty (except where indicated by the tests).
 * The device is interactive and uses scroll bars.

These are mentioned in the test suite's README file (but I just
discovered that the README file isn't being properly generated by the
test suite's Makefile, which I will fix).

In practice, if you want to render real-world Web content, you're
going to have to make the 96dpi assumption (as well as most of the
others). Not making that assumption breaks all kinds of Web pages.
There was a time several years ago where Mac browsers assumed 72dpi,
and they were universally having difficulties with important Web
sites. All Mac and Windows browsers with any measurable market share
today assume that the screen resolution is 96dpi; they have to in
order to get reliable and interoperable rendering, because authors
have widely used "absolute" units like 'pt' with the 96dpi assumption
in place.

-- 
Ian Hickson

Received on Monday, 11 September 2006 23:23:51 UTC