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 WinXP.
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.
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 widths. 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
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 ...
'height' doesn't apply to inline non-replaced elements. See: http://www.w3.org/TR/2004/CR-CSS21-20040225/visudet.html#inline-non-replaced http://www.w3.org/TR/2004/CR-CSS21-20040225/visudet.html#line-height
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Component: GFX → Layout
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.