Are px's measured differently between browsers?

[PHP John]

I have noticed that the "px" measurement for positioning elements seems to be different between browsers.

For instance a px based position of two elements that are vertically next to each other in IE are slighly separated in Netscape/Mozilla and slighly overlapped in Opera.

Also horizontal alignment seems to be slightly skewed in Opera.

I posted a good example of this under the thread titled "Cross browser compatibility". (http://www.sitepointforums.com/showt...hreadid=112358)

Can anyone shed some light on this and show me how they overcome this seeming incompatibility?

Thanks!

[DougBTX]

There are differences in how margins/paddings/borders are included/excluded in the width, so you should check that.

The only browser I know of where 1px doesn't allways equal 1 pixel is Opera 7 on the Mac where the screen's dpi is set to 72. Then it makes fonts slightly smaller. (and any browser when printing for example)

hth,
Douglas

[PHP John]

Doug,
Thanks for the reply! This is still all very new to me.

[M. Johansson]

I know (and find VERY annoying) that IE includes borders in the calculation of positioning. I'm not sure if this is specified in the standards or not, but it makes it totally impossible to use borders effectively, IMHO.

[DougBTX]

I know (and find VERY annoying) that IE includes borders in the calculation of positioning. I'm not sure if this is specified in the standards or not, but it makes it totally impossible to use borders effectively, IMHO.

The dimensions of the content area of a box -- the content width and content height -- depend on several factors: whether the element generating the box has the 'width' or 'height' property set, whether the box contains text or other boxes, whether the box is a table, etc. Box widths and heights are discussed in the chapter on visual formatting model details.

The box width is given by the sum of the left and right margins, border, and padding, and the content width. The height is given by the sum of the top and bottom margins, border, and padding, and the content height.

The background style of the various areas of a box are determined as follows:
Content area: The 'background' property of the generating element.
Padding area: The 'background' property of the generating element.
Border area: The border properties of the generating element.
Margin area: Margins are always transparent.

http://www.w3.org/TR/REC-CSS2/box.html
And, probably more important:
Widths

Douglas

[earther]

You can get around the padding problem by putting the padding in a separate div rather than including it in the div that you are trying to pad. Hope that's understandable.

[M. Johansson]

So it's actually IE which got it right, it seems.

[vgarcia]

You can get around the padding problem by putting the padding in a separate div rather than including it in the div that you are trying to pad. Hope that's understandable.

But then you're really no better off than with nested tables, which is what XHTML/CSS is trying to get away from.

So it's actually IE which got it right, it seems.

Nope, IE5/Windows got it wrong. IE5/Win uses your width and height as the total area, so if you specify a width of say 500 pixels, that 500 pixels includes your padding, border, and margins. Under the correct W3C box model, your padding, border, and margins are added to the width you specify, so if your width is 500 pixels, it's 500 pixels plus padding, border, and margins.

Understandable?

[M. Johansson]

Ahhh.

[vgarcia]

Ahhh.

For further reading, check out the "Box Model Hack" link in my sig, which should explain a little more and give you an example.

[earther]

For further reading, check out the "Box Model Hack" link in my sig, which should explain a little more and give you an example.

Hey, I'm not defending IE. It was just easier to do the extra divs rather than wrap my overworked brain around the Box Model Hack caculations. Are there any other reasons to do the hack rather than the divs (other than yours above and that I don't have access to IE 5x to check if I've got it right)?

[vgarcia]

Hey, I'm not defending IE. It was just easier to do the extra divs rather than wrap my overworked brain around the Box Model Hack caculations. Are there any other reasons to do the hack rather than the divs (other than yours above and that I don't have access to IE 5x to check if I've got it right)?

The box model hack reduces excessive presentational markup and works around IE5/Win's bugs, which is about the only reason to use it. In all honesty I don't use it much, as I try to make layouts that look good without the hack applied. This usually means that I can't make pixel-precise measurements between browsers, but my sites still work and look decent whether the browser is Opera 7 or IE5.

[earther]

The box model hack reduces excessive presentational markup and works around IE5/Win's bugs, which is about the only reason to use it. In all honesty I don't use it much, as I try to make layouts that look good without the hack applied. This usually means that I can't make pixel-precise measurements between browsers, but my sites still work and look decent whether the browser is Opera 7 or IE5.

Right now I'm still way too anal about layout precision. Maybe someday I'll develop a more flexible attitude and design skills. It's quite an interesting learning process . . . Thanks again for your clarity (not eligible to give you more rep yet!).

[Jeff Lange]

Yes, IE5/Win's Font-sizing and box-model are very annoying.

I enjoy designing in IE6 and Mozilla though, then work with my designs to get them to look correct in Opera (usually pretty good), and IE5 (sometimes more of a pain).