Elements not correctly positioned in absolute positioned div




15 years ago
15 years ago


(Reporter: Harald, Unassigned)


Windows NT

Firefox Tracking Flags

(Not tracked)





15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.7b) Gecko/20040421
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.7b) Gecko/20040421

Look at the test case.
This works fine in IE 5/6, i.e. as I had it intended to look.

The problem SEEMS to be that in a DIV which itself is in another DIV which are
both positioned absolutely, elements like A (with a 4 pixel border left, top,
right and 5 pixel padding left, top right, but not at bottom) are not positioned
correctly, but partly outside the DIV (5 pixels more to the top and less high (4
pixels) so the effect is, it is floating above the "ground".

It seems that Gecko calculates the padding and border wrongly, if they are not
on all four sides.

Is this a bug, or is there a different/standards compliant way to do this ?

Reproducible: Always
Steps to Reproduce:
See example.

Elements with borders and padding on only 3 sides in a DIV
Actual Results:  
The elements in the div are displayed too small and partly outside of the div.

Expected Results:  
The bottom of the elements should be aligned on the bottom of the outside div
(like TABS).

Additonally to Moz1.7b on WinNT4 I confirmed this also on Firefox 0.8 final on

Comment 1

15 years ago
It also doesn't make a difference if I change the A's to SPAN's.

I also made some more tests.
It really seems that not the missing bottom padding/border is the problem, but
that Gecko calculates the position of the element according that part which is
inside the padding and the border.

The inner part starts always at the "correct" position, which is 60 pixels from
the top. The top padding and border are drawn above this and thus the complete
element seems to be drawn too far at the top.

This doesn't change if I leave away the borders and/or padding.

The inner part seems to be always 19 pixels high (not 30 as defined), never mind
if I have borders and pddings or not - thus leaving 11 pixels of space below it.

Comment 2

15 years ago
Correct me if I'm wrong, but I think its because the height of an inline element
(the anchors) is determine by the line-height property, not height. If you set
line-height to 41px on the anchors the menu appears to render as intended.

element content height = 'normal' line-height
border-top-width: 4 pixels
padding-top-value: 5 pixels

border-top-width + padding-top-value + 'normal' line-height = 41px
4 + 5 + x = 41
x = 32

Not sure why x = 32, perhaps because of vertical-align or pixel rounding or the
line box. Anyways, it seems pretty clear that if you set border or padding on an
inline element, the width of such is not used to calculate the offset of the
element, only the content area of the element. However setting the line-height
appears to affect the vertical offset, so you if you want a pixel-perfect layout
you have to use a pixel line-height value that includes the border and padding

Comparing this to IE might not be relevant since IE does stretch inline elements
to fit the specified height property (not line-height as in CSS specification)
as well include border+padding in content width/height.

I'm not a developer so I'm not trying to comment on this being a valid bug or
not, just trying to help explain whats going on. Though I would like to know why
line-height should have been 2 pixels more than I expected.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421


Comment 3

15 years ago
Thanks for the hint.

In IE if I use line-height (I even didn't know this property existed) and set it
to 41, there is a 1px blue line below the A's, while in Moz, it works.

If I set it to 43, it is OK in IE and in Moz the elements go down one line.

BTW, it doesn't matter which height I set for the div, I can even let it away.

There seems to be no way, to make both browsers work the same on this :-(
I thought most such problems had gone with NS4, but ...
You need to log in before you can comment on or make changes to this bug.