Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#14631 closed defect (bug) (wontfix)

twenty ten bottom margin bug and fix

Reported by: EMG Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0.1
Component: Themes Keywords: has-patch
Focuses: Cc:


This bug and fix for the Twenty Ten theme is related to the top margin bug and fix as seen here: http://core.trac.wordpress.org/ticket/13636


The margin-bottom: 20px that is applied to the footer div triggers a well known CSS bug causing the 20px margin to be applied to the adjoining/bottom margin-touching wrapper div instead of the footer div.


To correctly apply the 20px margin-bottom to the footer div and not accidentally to the wrapper div, the wrapper div needs to be given a 1px padding-bottom and the footer div needs to be given a 19px margin-bottom.

The padding applied to the wrapper where it touches the bottom of the footer container will trigger the margin-bottom to be rendered correctly for the footer and not the wrapper as the padding will add some 'separation' between the two containers.

Another fix is to add a 1px border to the bottom of the wrapper and leave the 20px margin-bottom on the footer.

The border adds 'content' to the bottom of the wrapper which triggers the margin-bottom for the footer to be rendered correctly.

I have tested both fixes on my own most current WordPress and Twenty Ten install and both fixes 'fix' the CSS rendering bug.


If two adjoining containers share a common side (in this case, bottom of the footer and the bottom of the wrapper) and there is no padding or border to 'separate' them (padding) or 'add content' (a border would 'add content' in this case) aside from a declared margin that affects that shared side (in this case, the footer's margin), a bug is triggered where:

The margin applied to one container can be 'doubled' or 'pushed out' to the other container.

Case in point:

In Twenty Ten (the latest version as of the date of this ticket with the wrapper top margin fix applied as described in the trac ticket referenced), the footer div has a margin-bottom of 20px applied to it. Visually, what you see is the footer with a margin-bottom of 0px and the wrapper div with a margin-bottom of 20px. The margin got 'pushed out' or 'doubled'. When the fix as described above is applied, the 20px of margin-bottom get correctly rendered to the footer div.

Attachments (4)

TT-MarginBug-Screen1.png (87.4 KB) - added by EMG 4 years ago.
TT-MarginBug-Screen2.png (142.8 KB) - added by EMG 4 years ago.
TT-MarginBug-Screen3.png (146.5 KB) - added by EMG 4 years ago.
14631.diff (1.1 KB) - added by nacin 4 years ago.
I couldn't resist.

Download all attachments as: .zip

Change History (12)

comment:1 follow-up: iandstewart4 years ago

  • Cc ian@… added

I'm not sure I'm seeing this issue. Is is it happening in all browsers and do you have a screenshot?

EMG4 years ago

EMG4 years ago

EMG4 years ago

comment:2 in reply to: ↑ 1 EMG4 years ago

Replying to iandstewart:

I'm not sure I'm seeing this issue. Is is it happening in all browsers and do you have a screenshot?

Hi there Ian! :)

I enclosed screenshots of both the visual appearance of the margin in question and also screenshots of the CSS coding that would affect that margin to show that the CSS has no specifications for a bottom margin or a bottom padding (aside from 0px).

I am using Firefox 3.01X (I do work on an older machine and the newer Firefox really slows things down) and that is where I took the screenshots from.

Also, I have confirmed that this bug appears in Firefox, Flock, Chrome, Safari, and Opera and I am using a Windows machine running XP Pro.

The fix described in he trac ticket does away with that margin.

Please let me know if I need to send in screenshots for the other browsers. The 20px+ margin between the wrapper and the end of the document is persistent in all the browsers - including the ones I have fully up-to-date.

comment:3 iandstewart4 years ago

Hey, EMG. I've had a brief chat with the designer and he's confirmed that the 20px space was intentionally left blank. In short, it's supposed to look that way.

Was it not there in FF 3.01 before the patch was applied?

comment:4 EMG4 years ago

Hey there! :)

I think it has always been there pre and post-patch as the patch fixed the top margin bug which occurred for the same reason this one is occurring.

If it's supposed to look that way from a design perspective, that's fine and I can go ahead and delete this trac ticket, but when looking at it from a technical/CSS perspective, the CSS specifications equate to a 0px margin and padding between the end of the document and the wrapper as shown in the screenshots I provided.

The reason for the margin/space to appear is specifically because a bug has been triggered to make the margin appear between the wrapper and the end of the document when the margin originally was supposed to be between the footer and the wrapper.

I know I'm being nitpicky, but I would rather margins appear because they are coded to appear rather than triggered to appear via a known CSS bug which is why I submitted this ticket.

I have had no other issues with the Twenty Ten theme otherwise and I have been using it to make child themes.

nacin4 years ago

I couldn't resist.

comment:5 EMG4 years ago

Hey there, nacin!

Considering I don't see such a formatting in my copy of the Twenty Ten theme, can I safely consider what you posted to be an add-on to literally add on the space intentionally left blank?

... And no, I'm not being a smartass.

I simply am not sure how to interpret what you just posted.

comment:6 nacin4 years ago

  • Keywords has-patch added; twenty ten twenty ten theme margin doubling margin bugs collapsing margins CSS bugs removed

:-) I could not resist a little humor.

comment:7 EMG4 years ago


Thanks for that! :-)

comment:8 nacin3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.