Closed Bug 224753 Opened 21 years ago Closed 10 years ago

1 pixel rounding error when the padding and margins expressed in em

Categories

(Core :: Layout, defect)

Other Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Erich.Iseli, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(4 files)

Tested on Mozilla 1.5/Linux

If you load the testcase, you will notice a 1px white line between the h3 and
the following p. This is because the values of padding and margin are expressed
in em, and these values are small (0, 0.1em, 0.2em). If you increase the size of
these paddings and margins, the white line disappears. If you remove the h1 at
the top of the page, the white line disappears too.
Testcase mentioned in comment#0
OS: Linux → All
This rounding error occurs in the Firefox 1.0 release across all platforms
(well, I only tested Win, Mac and Linux).  For a view of this error on a full
website, check out <a
href="http://studentaids.org/brandeis/frontpage.php">studentaids.org/brandeis/frontpage.php</a>.

There is an inconsistant spacing between the li elements in the left navigation
bar caused by using EM measurments for the margin of the LIs and the padding on
the As.  Internet Explorer and Safari don't exhibit this error.
Same problem if I use em measurements in the menus :
http://css.tests/menu4err.php
with more rounding errors if you zoom and a rounding error with the background
(#zone_left) if you increase text size
also
http://css.tests/menu4c.php in the menu at the right.
If you remove border-bottom the gap is more visible,
if you decrease text size, a vertical line appears on the right
Tested with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414
Firefox/1.0.3
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050216
and
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050429
Firefox/1.0+
Sorry about the addresses,
http://css.tests.free.fr/menu4err.php
http://css.tests.free.fr/menu4cc.php
should be better.
I will attach a testcase if it is not a duplicate.
*** Bug 295486 has been marked as a duplicate of this bug. ***
Is this still an issue?
I see the error with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8)
Gecko/20050509 Firefox/1.0.4
I do not see the error with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.8b2) Gecko/20050525 Firefox/1.0+ ID:2005052509
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

I don't see the problem with the original testcase, but it still occurs when I
add an opacity != 1.0 to the style.
The checkin for bug 317375 has altered the behavior of the second testcase.  It still fails, except that now the space between the h3 and the p has changed from being a 1px white line to a 1px gray line.
I found this problem independantly, but I think it may be another manifestation of this bug.  I see a white line between the light blue background and the dark blue outline on items 3, 4, and 8.  Note that it only seems to show up when the padding calculates to a fraction pixel count and there is also a -moz-border-radius.

Even without the border style this can cause problems by intruducing a 1-pixel gap between the bad element and the following one.

Position:absolute is used only to get consistant results -- the problem can happen with position:static, but note item 7 where a fractional top masks the problem.  The problem can similarly be masked with multiple position:static items in a row.
(The test-case file is commented internally)
The problem is that up-to the current version of Firefox 3.0.5, it non-consistently rounds the fractions of em(s) to the corresponding pt(s).

For example:
If you set the body text to 1em that by default equals 12pts, then use a 0.1em fraction for margin-right of a series of a elements in li elements, then the margins round non-consistently once to 1pt and the other time to 2pts.

Since 1 tenth of 12 is 1.2 then it seems that it should be rounded and results in a non-consistent rounding in firefox, though seemingly IE7 and Opera9 round it to the upper integer value and Safari to the lower.
Assignee: layout → nobody
QA Contact: ian → layout
WFM on:
Mozilla/5.0 (X11; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0 (20140112030204)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: