CSS margin settings are being applied additively instead of being overwritten

RESOLVED WORKSFORME

Status

()

Core
Layout
RESOLVED WORKSFORME
7 years ago
3 years ago

People

(Reporter: expendable.email+bugzilla, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0

As part of a web page I'm designing, we have some CSS that looks like this:

#menu li {
  margin: .5em 2% 0;
}

#menu :nth-child(4n+1){
  margin: .5em 2.5% 0 0;
}

#menu :nth-child(4n){
  margin: .5em 0 0 2.5%;
}

On webkit browsers, this has the desired effect; the first and fifth elements have 0 0 7 5 margins, the forth and eighth have 0 7 0 5 margins, and all others have 0 5 5 5.

On firefox, it gets strange. The first and fifth have 0 0 7.68333 5.5 margins, the forth and eighth have  0 7.68333 0 5.5, and all others have 0 6.15 5.5 6.15. It looks in firebug as though both the "catch-all" CSS entry and the nth-child entries are being applied to the special ones, rather than the more specific entries overwriting the general one.

Reproducible: Always

Comment 1

7 years ago
Please attach a small HTML testcase (use "Add an attachment" link)

Updated

7 years ago
Component: General → Layout
Keywords: testcase-wanted
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
I'm not sure I follow you example.  Given a width of 100*N pixels for the list and a font-size of 2*M pixels, I would expect the first and fifth elements to have margins (listed in top, right, bottom, left) order of (M, 2.5N, 0, 0), the fourth and eighth to have (M, 0, 0, 2.5N), and the rest to have (M, 2N, 0, 2N).

In particular, note that the vertical margins depend on the font-size while the horizontal ones depend on the width of the list given your styles.  If your numbers are in pixels, then it sounds like you have an 11px font and a width of 307.5px or so.  That would be consistent with all your numbers for Gecko.

To get your Webkit numbers, you need a 10px font and a width of 250px, plus webkit's thing with rounding everything to integer pixels.

So is your real question why the font size is different?  Because given the difference in font size, the difference in width is probably expected...

Firebug is, of course, showing that both rules apply.  They do; but only one of the margin declarations applies (the one from the higher-specificity rule).
Marking as worksforme.  If you believe there's still a valid problem here, please attach a testcase (i.e., sample HTML) showing the problem.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.