homepage Welcome to WebmasterWorld Guest from 54.234.128.25
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Subscribe to WebmasterWorld
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderator: open

CSS Forum

    
When is 1px not "one pixel"?
OR: Pixel as a relative unit
DrDoc




msg:3706372
 3:34 pm on Jul 24, 2008 (gmt 0)

We all know that
px is a relative unit. But, relative how? Well, logic dictates that a screen with a physical resolution set to 96 PPI (pixels per inch) equals 96 pixel per inch. Inches are, as we know, absolute units. 1 in = 96 px @ 96 PPI. Logically, then, at a higher resolution (such as 120 PPI), the number of pixels per inch changes. 1 in = 120 px @ 120 PPI.

Some browsers, such as WebKit, break this behavior, always making 1 in equal 96 px. This, of course, is incorrect, as it now makes absolute units (such as in, cm, etc) relative and unusable.

But, there are also instances when 1 px does not even equal one physical pixel. Gecko, for example, maps 1 px to 2+ physical pixels on high resolution devices.

Again, an important reminder to be consistent in unit usage. Sticking to relative units (em, %) is always best for the layout as a whole. Although px is also a relative unit of measure, it should be avoided as it doesn't scale well for different screen resolutions in certain browsers.

Fixed units (such as in or cm) should be used when actual-size representation is important. Just remember that some browsers break this behavior, by not scaling according to screen resolution.

 

Xapti




msg:3706735
 10:17 pm on Jul 24, 2008 (gmt 0)

I was going to rant about this, but I forgot.

It pisses me off that virtually everyone on the web uses like 10px for their websites font size. At best it's like 12-14px. This is absolutely ridiculous. Why the hell aren't people using the default font size? I ranted about this on a chatroom, and everyone got real bitchy about how all design firms want specific pixel values, and using the default always makes the font too large, and that it's ugly (aparently making things bigger somehow makes them uglier). They say that the default font size is too large, and people don't change them (because they are too dumb or ignorant, or what?)
I would say people who have trouble reading small text are by far the most likely people to also not know how to set something like minimum font size, or default font size on the browser... that should be even more of a reason why the default should be used if it's large. If the customers are thinking 16px is too big for them (which it might be depending on the monitor/resolution), then it's their responsibility to be changing the font size... not the webmasters to dictate the font size for everyone. It's absolutely ridiculous.

Here is another annoying example with fixed font sizes of various sizes on one page:
I have my default font size on 17px, and minimum font size to 16px (firefox). (the reason is because I am running 2MPx display)
If the website is using 16px for h1, 15px for h2, 13px for h3, and like 12px for everything else, and 10px for small print... my browser won't be able to distinguish any of it, because my min size is 16x, and small print will be big, headers will be small, everything the same.

Anyway, to the point of borders... while it's not as much of an issue with margins and padding, because they are generally larger values, some (generally kinda lousy) browsers are not that compatible with using ems for something like border. Having the em setting too low may make the border invisible, and making it too high, may cause more pixels than desired. It may take guess work to find a suitable value, only to still result in problems with people with different font sizes. In particular, I believe for whatever reason, IE6 isn't consistant in displaying borders with ems... both borders may be .05em, but one will be 2px the other will be 1px, even though both are the same font size... it's quite strange.

DPI isn't a huge issue overall. To be accurate, a user has to adjust their DPI to match their monitor. In some instances, they may have to do it twice (safari for windows would require a change in both windows and safari, I believe). Macs always run at 96DPI AFAIK since they are integrated into the screens.
Having correct DPO is only really relevant for print previews generally. I cannot come up with many other reasons. Some lousy websites use pts for font sizing, and setting the DPI will increase them, but even then it's not necessary for the DPI to be accurate, just the size you want to make pts look nice.

tangor




msg:3707541
 6:37 pm on Jul 25, 2008 (gmt 0)

User behavior is changing a bit. Some may not know how to adjust their font sizes inside the browser, but FF 3 with the ZOOM feature is easy to understand (I use it myself).

And many fixed point websites break here and there after zooming. :)

I know appearance is a big part of the web experience, and for graphic intensive sites is essential. I also know that content is far more important and gave up on fixed fonts (points) about six years ago. Took a while to style my H tags the way I wanted in relation to the default for body text, but once done I no longer worry about what size font the browser is using, or if the user has Zoomed in... YMMV

DrDoc




msg:3707891
 1:12 am on Jul 26, 2008 (gmt 0)

The problem is that so many designers/coders have no clue what "one pixel" really means. They also assume that they know what their users like the best, which is a dangerous assumption. But that's a completely different topic.

I don't really want to get into a discussion about small vs large fonts. I wanted to highlight a common misconception. "1 px" is not always "one pixel". It's merely a unit of measure that maps to a number of screen pixels. Usually, this mapping equals 1:1. But that is not necessarily the case.

Xapti




msg:3708304
 9:08 pm on Jul 26, 2008 (gmt 0)

Oh yeah, I also wanted to point out a note about absolute units...

absolute units is a relative term... when using the term absolute, it's absolute to what frame of reference?

To a computer, pixel is the most solid, absolute unit, because that's how it sees everything it displays... pixels (or sub-pixels to be specific)

From the human perspective, where real world measurements are standard, pts, cm, and inches, are ovbiously more of the absolute unit.... it's just computer wise.... 1 inch could display as any size, depending on the monitor and DPI setting (which often aren't set up right).

I just thought I'd mention that, because I find it annoying when people use the words absolute units, since all it could mean is not em.

DrDoc




msg:3708353
 10:20 pm on Jul 26, 2008 (gmt 0)

From the human perspective, where real world measurements are standard, pts, cm, and inches, are ovbiously more of the absolute unit.... it's just computer wise.... 1 inch could display as any size, depending on the monitor and DPI setting (which often aren't set up right).

If 1in displays as anything but "one inch", the problem is the browser (or whatever application is responsible for rendering).

WebKit handles this wrong.
Gecko has it right.

Absolute units are supposed to be absolute. 1in is always supposed to be exactly equal to one inch. In any case, they are not supposed to be dependant on screen resolution.

Even more important to use em or % as units of measure.

poppyrich




msg:3709198
 2:02 pm on Jul 28, 2008 (gmt 0)

@doc

Absolute units are supposed to be absolute. 1in is always supposed to be exactly equal to one inch. In any case, they are not supposed to be dependant on screen resolution.

Huh?

Look, the math behind how computers render is a really complicated topic but here's something simple to consider:

My screen is set to a 1280 DPI resolution. My screen measures appr 14.75 inches in width. 14.75/1280 equals .0115. Therefore, my screen width is divided up into dots appr .0115 inches big.
My DPI setting is 96. 96 x .0115 is 1.104.

Therefore, if I create a div with a 96px width it measures out, with a ruler, at about an inch and a tenth.

I don't know what you mean by "supposed to", but this is the way it's been workin' for a long time now.

DrDoc




msg:3709664
 8:30 pm on Jul 28, 2008 (gmt 0)

By "supposed to" I mean: if you specify
1in in your CSS, the browser should convert that to as close to one physical inch as at all possible. Gecko does this, regardless of DPI settings.

What you get the other way around (specifying a number of pixels) is slightly irrelevant, as they have no real-world representation. The size of a pixel varies greatly. All you get is a number of those pixels.

But one inch is always -- or, is "supposed to be" -- exactly one inch.

[edited by: DrDoc at 8:31 pm (utc) on July 28, 2008]

poppyrich




msg:3710287
 2:49 pm on Jul 29, 2008 (gmt 0)

Hey doc, now you've got me to write a test page or two (later today)
because I'm a skeptic.

For years I've wished there was a browser scripting property or just a hack of some kind to find out the actual physical size of the user's monitor - not just the resolution.

If what you're telling me is true then it's at least hafway possible in Moz.

I still can't see how the browser can ignore screen resolution and the PPI when calculating 1in. (In the IE script model there's a property called screen.deviceXDPI/YDPI that you can query for the PPI.)

It simply doesn't make sense to me. How does the browser square this circle? What you're calling inconsistent, I'm calling consistent.

Let you know what I see....

later

poppyrich




msg:3710379
 4:16 pm on Jul 29, 2008 (gmt 0)

My results aren't correlating with yours, doc.

HTML for test page as follows:

<html><head>
<style>#div1{position:absolute;top:100px;left:100px;
width:2in;height:2in;
border:1px solid black;
}</style>
</head>
<body>
<div id="div1"></div>
</body></html>

On a 19" LCD screen with a resolution of 1280x1024, the box measures (as expected - see math in prev post) about 2 1/4".
With the same screen at a resolution of 1024x768, the box measures (as expected) about 2 3/4".
96 DPI in both cases.

Happens in both IE and FF3.

However, it prints to exactly 2 inches.

Demaestro




msg:3710389
 4:28 pm on Jul 29, 2008 (gmt 0)

In the case of fonts there is the pt instead of px option. I believe that it too is to act as a fixed value but I think that screen resolution affects this but changing font sizes in browser preferences doesn't.

Does anyone avoid or advocate using pt for this reason?

Xapti




msg:3710404
 4:47 pm on Jul 29, 2008 (gmt 0)

at one point I advocated it, since windows and IE (even though I didn't really use IE) use the pt system, so if I bump up my DPI to make windows and IE fonts bigger, websites I encounter will have to use points. Because that's a ridiculous battle, and it's really Microsoft's fault for not using proper scaling mechanisms and not using pixels, I've just advocated use of the EM. It may be a very good idea to use pts for printing, though.

DrDoc




msg:3710521
 6:35 pm on Jul 29, 2008 (gmt 0)

On a 19" LCD screen with a resolution of 1280x1024, the box measures (as expected - see math in prev post) about 2 1/4".
With the same screen at a resolution of 1024x768, the box measures (as expected) about 2 3/4".
96 DPI in both cases.

You need to use the native resolution for a test like that to be useful.

Besides, what you tested is not what I was trying to prove. You changed the resolution on a device incapable of physically displaying a different resolution. Instead, use the native resolution for your screen, and play with the DPI.

Whether you use 96 DPI or 200 DPI, the size of your 2in box should not change in Gecko.

Not all browsers vary their px-to-in ratio. WebKit doesn't. Gecko does. At 200 DPI, there are 200 pixels to an inch in Gecko. Whether the DPI is 96 or 200, there are exactly 96 pixels to an "inch" in WebKit.

That is the problem. Not all browsers treat the in unit absolute.
I don't even want to think about how uber tiny
1px must be in a browser like WebKit at 200 DPI.

At least Gecko begins to scale, making one CSS pixel equal two or more device pixels.

DrDoc




msg:3710529
 6:39 pm on Jul 29, 2008 (gmt 0)

Interesting reading about units and the challenges browser makers are faced with:
[wiki.mozilla.org...]

poppyrich




msg:3711453
 6:57 pm on Jul 30, 2008 (gmt 0)

So, what you're saying, if I'm getting it right, is that Gecko ignores the DPI setting of the underlying operating system?
(Yes/No)

I'm getting a headache.

I don't know what you mean by, "native resolution", either.
Is this the resolution used by aboriginal populations? (Sorry, couldn't help it.)

Help me focus: what underlying practical repercussions were you trying to illuminate? Maybe then I'll get it.

If your answer to my first question is yes, I'll go back and do a few more tests.

And here's an additional complication for you: FF3, Opera, and soon, IE8 implement "Adaptive" Zoom features that rely on a change of "logical" resolution to reduce and enlarge.
How does that figure in?

Aspirin, where's my aspirin....

jessejump




msg:3711493
 7:35 pm on Jul 30, 2008 (gmt 0)

Inches and points are for printing. There are only pixels on a monitor. The video card doesn't know the size of the monitor. It doesn't know how many inches there are on your monitor. You can hook any size monitor up to your computer.
96 DPI is an approximation of an inch, not a true inch.

DrDoc




msg:3711551
 8:36 pm on Jul 30, 2008 (gmt 0)

Points are definitely for printing. Inches are mainly for printing, but do have some screen applications as well.

And, what I'm trying to highlight is that the pixel is not a very reliable unit of measure. It means something completely different depending on browser, DPI, etc. To make matters worse, the CSS pixel doesn't even have a reliable hardware equivalent. Sometimes it's a 1:1 ratio; other times 2:1 or something else.

Pixels are not good for much at all. Not for font sizes. Not for layout dimensions. Not even for images (which we are stuck sizing in pixels).

But most people tend to forget (or simply not know) just how relative the pixel is. They look at nothing but their own screen, and forget that their own settings are not representative of the average user. Unfortunately, the pixel doesn't generally scale as well as it should. It's kind of a hybrid between absolute and relative.

poppyrich




msg:3713926
 5:02 pm on Aug 2, 2008 (gmt 0)

Pixels are not good for much at all.

Look, think about it any way you want, but when you write:

font-size: 12px;

or font-size:2em;

The browser converts these settings into "computed values" (it's in the spec, you can look it up) which are IN PIXELS, IN PIXELS.
Did I mention they are computed into pixels?

Plus, the bias against using points is unfounded. Points came out of print media and new media snobs gave them a bad name.
Points map to pixels in a 3:4 ratio and are, in practice, interchangeable since pts can be designated using a floating point number.

This works because the browser converts these settings into PIXELS!

font-size: 12pt;

is 16 pixels.

DrDoc




msg:3714071
 2:02 am on Aug 3, 2008 (gmt 0)

Well, if you would have read from the beginning of this thread, you would have noticed that your statement is not entirely true.

In some browsers, 1px will convert to one device pixel. On a 200dpi monitor, your left hand navigation will be completely unreadable. In other browsers, that same "1px" will convert to perhaps 2 or even 5 device pixels. In other words, viewing the same webpage on the same machine but in two different browsers is capable of proving drastically different result, to the point of brokenness.

No other unit exhibits this problem.

% is obvious
em is relative to the current font (which always scales to device pixels)
Even
pt does not exhibit this problem.

But px does.

The fact that some browsers will render a 12pt wide element different from its 16px cousin, depending on screen DPI. That, my friend, is what this is about. And that is what is making pixels deceivingly problematic.

[edited by: DrDoc at 2:03 am (utc) on Aug. 3, 2008]

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved