pixel-based vs. real-word-pased units

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

pixel-based vs. real-word-pased units

Peter Sorotokin

Some tests seem to assume that 96px = 1in (e.g. http://www.w3.org/Style/CSS/Test/CSS2.1/current/t0803-c5501-mrgn-t-00-b-a.xht).

Isn’t that wrong assumption?

 

Peter

Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson

On 9/11/06, Peter Sorotokin <[hidden email]> wrote:
>
> Some tests seem to assume that 96px = 1in (e.g.
> http://www.w3.org/Style/CSS/Test/CSS2.1/current/t0803-c5501-mrgn-t-00-b-a.xht).
>
> Isn't that wrong assumption?

Not for anything whose screen is at arm's length from the viewer's
eyes, no. (It _is_ technically incorrect for projection screens, but
in practice if a projection screen rendered 1in as a real inch -- say,
10px -- it would break a lot of existing content, so projection media
UAs usually treat "1in" as being a relative unit and not a physical
one. I expect in a few years we'll end up redefining the absolute
units to take this into account.)

--
Ian Hickson

Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin

Ian, I do not see how that is the case with the current language in the
spec. The current draft of CSS2.1 spec says:

Pixel units are relative to the resolution of the viewing device, i.e.,
most often a computer display. If the pixel density of the output device
is very different from that of a typical computer display, the user
agent should rescale pixel values. It is recommended that the reference
pixel be the visual angle of one pixel on a device with a pixel density
of 96dpi and a distance from the reader of an arm's length. For a
nominal arm's length of 28 inches, the visual angle is therefore about
0.0213 degrees.

[ http://www.w3.org/TR/CSS21/syndata.html#length-units ]

My laptop's screen is about 115dpi (which is quite typical for a
computer display, I'd say), so user agent should not rescale pixel
values in my case (I can imagine once it gets to 160, 1 CSS pixel would
be equal to two display pixels).

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.

Peter

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Ian Hickson
Sent: Monday, September 11, 2006 3:28 PM
To: Peter Sorotokin
Cc: [hidden email]
Subject: Re: pixel-based vs. real-word-pased units

On 9/11/06, Peter Sorotokin <[hidden email]> wrote:
>
> Some tests seem to assume that 96px = 1in (e.g.
>
http://www.w3.org/Style/CSS/Test/CSS2.1/current/t0803-c5501-mrgn-t-00-b-
a.xht).
>
> Isn't that wrong assumption?

Not for anything whose screen is at arm's length from the viewer's
eyes, no. (It _is_ technically incorrect for projection screens, but
in practice if a projection screen rendered 1in as a real inch -- say,
10px -- it would break a lot of existing content, so projection media
UAs usually treat "1in" as being a relative unit and not a physical
one. I expect in a few years we'll end up redefining the absolute
units to take this into account.)

--
Ian Hickson

Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson

On 9/11/06, Peter Sorotokin <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
Of Ian Hickson
> Sent: Monday, September 11, 2006 4:24 PM
> To: Peter Sorotokin
> Cc: [hidden email]
> Subject: Re: pixel-based vs. real-word-pased units
>
> On 9/11/06, Peter Sorotokin <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson

On Mon, 11 Sep 2006, Peter Sorotokin wrote:
> >
> > 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?

The test suite is primarily written by browser vendors and therefore
primarily tests for CSS compliance in a Web context, which includes making
certain assumptions that are required for rendering Web content.

I would be happy to add a flag to the filename to indicate that the test
assumes Web browser characteristics (though that would probably flag most
tests -- all of them, if you consider HTML support to be a Web browser
characteristic). I would also be happy to accept tests that don't make
those assumptions. To contribute such tests, please see:

   http://lists.w3.org/Archives/Public/public-css-testsuite/2006Aug/0000.html

It would be great to get tests from implementors who aren't Web browser
vendors, since, as you imply, that has resulted in a bias in the test
suite so far.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

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

Lachlan Hunt
In reply to this post by Peter Sorotokin

Peter Sorotokin wrote:
> 96dpi (exactly 96dpi) displays are almost non-existent.

No, that's not true.  Most monitors I've ever used are exactly 96dpi.
Just look at almost any 17" LCD display with a native resolution of
1280x1024 or (I think) a 21" at 1600x1200.  My point is that such
monitors do exist and are relatively common, at least where I'm from.

--
Lachlan Hunt
http://lachy.id.au/

Reply | Threaded
Open this post in threaded view
|

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

Grant, Melinda
In reply to this post by Ian Hickson

 
Ian said:
>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

Another large assumption made by the test suite is that custom fonts are
installable (such as the Ahem font).  You may wish to add this
assumption to the README.  For all of the printer UA's of which I am
aware, this assumption breaks.

Best wishes,
Melinda


Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson

On 9/11/06, Grant, Melinda <[hidden email]> wrote:
>
> Another large assumption made by the test suite is that custom fonts are
> installable (such as the Ahem font).  You may wish to add this
> assumption to the README.  For all of the printer UA's of which I am
> aware, this assumption breaks.

Will do.

--
Ian Hickson

Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin
In reply to this post by Ian Hickson

My point is that those tests as they are today are *incorrect* per
today's spec (and in my case they are likely to cause confusion for the
users and even for our own QEs). There is no much need for a flag in the
filename, but the language in the test could be more precise; for
instance, instead of "The two diagrams below should be identical, with
no red present", it could say, "If blue and green boxes below are of
equal length, than two diagrams below should be identical, with no red
present", with two additional boxes, green of width 1in and blue of
width 96px. There are maybe 10 tests that fall under that category.

It is perfectly understandable that web content has preferred treatment,
but not to the point of having the whole test suite being runnable only
on 96dpi display.

Peter

-----Original Message-----
From: Ian Hickson [mailto:[hidden email]]
Sent: Monday, September 11, 2006 5:18 PM
To: Peter Sorotokin
Cc: [hidden email]
Subject: RE: pixel-based vs. real-word-pased units

On Mon, 11 Sep 2006, Peter Sorotokin wrote:
> >
> > 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?

The test suite is primarily written by browser vendors and therefore
primarily tests for CSS compliance in a Web context, which includes
making
certain assumptions that are required for rendering Web content.

I would be happy to add a flag to the filename to indicate that the test

assumes Web browser characteristics (though that would probably flag
most
tests -- all of them, if you consider HTML support to be a Web browser
characteristic). I would also be happy to accept tests that don't make
those assumptions. To contribute such tests, please see:

 
http://lists.w3.org/Archives/Public/public-css-testsuite/2006Aug/0000.ht
ml

It would be great to get tests from implementors who aren't Web browser
vendors, since, as you imply, that has resulted in a bias in the test
suite so far.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

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

L. David Baron
In reply to this post by Ian Hickson
On Monday 2006-09-11 16:23 -0700, Ian Hickson wrote:
> 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.

No, you have to clamp the OS-provided logical resolution to a *minimum*
of 96dpi.  This is because authors have often specified font sizes in
points when looking at 96dpi displays, since that's the default logical
resolution on Windows.  For small font sizes, the number of pixels
occupied by the characters is a major determinant of legibility.

Using larger values of logical resolution works just fine for real world
Web content.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin
In reply to this post by Peter Sorotokin

Is there going to be some sort of resolution on this? How things like
this are decided?

Peter

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Peter
Sorotokin
Sent: Monday, September 11, 2006 7:33 PM
To: Ian Hickson
Cc: [hidden email]
Subject: RE: pixel-based vs. real-word-pased units


My point is that those tests as they are today are *incorrect* per
today's spec (and in my case they are likely to cause confusion for the
users and even for our own QEs). There is no much need for a flag in the
filename, but the language in the test could be more precise; for
instance, instead of "The two diagrams below should be identical, with
no red present", it could say, "If blue and green boxes below are of
equal length, than two diagrams below should be identical, with no red
present", with two additional boxes, green of width 1in and blue of
width 96px. There are maybe 10 tests that fall under that category.

It is perfectly understandable that web content has preferred treatment,
but not to the point of having the whole test suite being runnable only
on 96dpi display.

Peter

-----Original Message-----
From: Ian Hickson [mailto:[hidden email]]
Sent: Monday, September 11, 2006 5:18 PM
To: Peter Sorotokin
Cc: [hidden email]
Subject: RE: pixel-based vs. real-word-pased units

On Mon, 11 Sep 2006, Peter Sorotokin wrote:
> >
> > 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?

The test suite is primarily written by browser vendors and therefore
primarily tests for CSS compliance in a Web context, which includes
making
certain assumptions that are required for rendering Web content.

I would be happy to add a flag to the filename to indicate that the test

assumes Web browser characteristics (though that would probably flag
most
tests -- all of them, if you consider HTML support to be a Web browser
characteristic). I would also be happy to accept tests that don't make
those assumptions. To contribute such tests, please see:

 
http://lists.w3.org/Archives/Public/public-css-testsuite/2006Aug/0000.ht
ml

It would be great to get tests from implementors who aren't Web browser
vendors, since, as you imply, that has resulted in a bias in the test
suite so far.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'