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

> -----Original Message-----
> From: ian.hickson@gmail.com [mailto:ian.hickson@gmail.com] On Behalf
Of Ian Hickson
> Sent: Monday, September 11, 2006 4:24 PM
> To: Peter Sorotokin
> Cc: public-css-testsuite@w3.org
> Subject: 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.

All of the above are the most common case in practice, right? 96dpi
(exactly 96dpi) displays are almost non-existent. Yes, browsers in
practice implement CSS pixel = display pixel and 1 inch = 96 pixels.
This is totally wrong per today's CSS spec, though. Yet the test suite
seems to be geared towards that case. I think there is only one test
which depends on 1 CSS inch being 1 real-world inch and there are many
tests that assume that 1 inch = 96 pixels.

In my application it is very desirable that 1 CSS inch is actually 1
real-world inch. This is what CSS spec says. I also do not want to have
all the borders and backgrounds to be fuzzy because of non-integer pixel
dimensions, so I define 1 CSS pixel = 1 display pixel. Again, this is
what CSS spec says.

The bottom line: I just faithfully implement CSS spec for the most
common case (100+ dpi display) and yet I cannot use many test files in
the test suite? That sounds broken to me.

> 
> 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).

Thanks, that will help.

> 
> 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).

Agreed, but I do not want to render HTML at all at this point. I am only
interested in CSS.

> 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.

Hey, I am implementing the spec. Does the test suite test the compliance
with the spec or the ability to render real-world Web content?

> 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.

Many of *my* authors are print publishers. Should I just tell them that
they always had wrong idea about what the point is? How could I even
start explaining that to them if 1 point in the CSS spec is defined as
1/72th of an inch, *not* as 96/72th of a pixel?

Peter

> 
> -- 
> Ian Hickson
>

Received on Monday, 11 September 2006 23:53:48 UTC