[thelist] Re: A pixel is not a pixel (or rather, a px is not pixel)

[CodeBitch]

Arlen,
The discussion at this URL may be relevant.
http://www.macedition.com/cb/cb_20010604.shtml

It should be pointed out that Opera 5/Mac's px-rescaling only applies to font
sizes, not other properties like height and width. So it's probably a case of
them reading the spec correctly and then forgetting that while Mac OS specifies
72dpi, most Mac screens actually have much higher resolution. I call this "doing
the wrong thing for the right reasons", while others prefer the nomenclature
"bug". Opera intend to fix this in the final release, so web designers can go
on for a few more years believing that a CSS px is a physical pixel, even when
it isn't.

On explaining how all the units work, I have heard good reports on the CSS book
by Hakon Lie and Bert Bos. http://www.amazon.com/exec/obidos/ASIN/0201596253/


I like your suggestions for future versions of the CSS standard ("I want 12px
text, but only if that's not less than 0.7 of the user's default size, so the
visually impaired with big font sizes can still read it"). However, all this
is moot if browser manufacturers can't even get CSS1 right, and some designers
can't even create pages with tags that balance.

Regards,
CB

>A couple of recent threads contained notes that pixels were the only way to

>achieve cross-platform consistency. Anyone who has seriously wedded
>themselves to this idea needs to have a look at Opera 5 for the Mac, which

>in fact renders pixel text on a Mac considerably smaller than pixel text on

>a Windows machine. Opera doesn't appear to consider this a bug, and in
>reading the CSS spec, they appear to be justified in that assertion, as the

>CSS spec asserts that the user agent (AKA browser) should in fact *not*
>consider a pixel as a screen pixel, but rather as a hypothetical unit
>approximately equal to 1/90th of an inch.
>
>Which means that if the user agent is not given the video density of the
>monitor attached, it will assume the platform standard (72 pixels per inch

>for MacOS) and resize the value accordingly. (BTW, for the more technically

>inclined: Since almost the beginning of time, MacOS internally has
>contained fields purporting to be the horizontal and vertical dpi values of

>the attached screen. I think some video driver writers even use them. But
>Apple doesn't; Quickdraw, and therefore MacOS, always assumes 72. No idea
>if this has changed under OS X, as I haven't had the time to take it apart,

>yet.)
>
>Pixels aren't your saviour. Get used to the idea that your wonderful
>pixel-perfect beautifully-colored layout will *only* be that way on your
>own screen, and start designing by rules, rather than pixels.
>
>If anyone's got an "in" with the W3C, here's what's needed:
>1) A way to read the rendering assumptions of the browser (96dpi, 72dpi,
>whatever)
>2) A "minimum-font-size" attribute, which functions as a limit beneath
>which the user agent should ignore font sizing declarations
>3) A way of reading the current rendering size of an object specified in
>relative measurements. (200% of what? How big's an em? That sort of thing.

>
>These should all be part of the standard, so that if/when a browser decides

>to support it we can use them to help our pages understand the conditions
>they're about to be subjected to.
>
>(If I seem to be ranting there at the end, it's because I just ran into
>*another* site designed by someone who knows better than *I* do what size I

>want my browser window set at. My apologies if I carried the rancor along
>with me. Maybe I should code up an extra for the Mozilla project; a
>preference button that replaces that particular piece of, um, javascript
>code with a quick redirect to the top of the history stack.)
>
>Have fun,
>Arlen
>Chief Managing Director In Charge, Department of Redundancy Department
>DNRC 224
>
>Arlen.P.Walker at JCI.Com