WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#16222 closed defect (bug) (fixed)

When admin bar is active, switch body padding-top to margin-top

Reported by: koopersmith Owned by: aldenta
Milestone: 3.1 Priority: normal
Severity: normal Version: 3.1
Component: General Keywords: has-patch
Focuses: Cc:

Description

Using margin-top instead of padding-top on the body element is less likely to cause theme incompatibilities. Borders will be shown below the bar, and padding is more likely to be defined by the theme.

Attachments (3)

16222.diff (411 bytes) - added by koopersmith 5 years ago.
16222.2.diff (464 bytes) - added by aldenta 5 years ago.
Tested in IE6/7/8, FF 3.6.13, Safari 5.0.3, Chrome 8.0.552.237
Screenshot.png (18.1 KB) - added by scribu 5 years ago.

Download all attachments as: .zip

Change History (16)

@koopersmith5 years ago

comment:1 @nacin5 years ago

  • Owner changed from koopersmith to aldenta
  • Status changed from new to assigned

Per discussions and testing, apparently using a margin on the html element here is actually the best way to do this. It's more cross-browser than margin or padding on body (IE7+), and it will almost never have any styling, so it's quite safe.

Patch from aldenta will follow.

comment:3 @nacin5 years ago

  • Summary changed from When debug bar is active, switch body padding-top to margin-top to When admin bar is active, switch body padding-top to margin-top

I think koop is dreaming in debug bar at this point. Correcting the title.

@aldenta5 years ago

Tested in IE6/7/8, FF 3.6.13, Safari 5.0.3, Chrome 8.0.552.237

comment:4 @aldenta5 years ago

Styling the html tag seems to work better in IE and will also help prevent styling conflicts on the body tag.

comment:5 @dd325 years ago

Looks fine in Opera.

comment:6 @nacin5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [17299]) For admin bar padding, use margin on the html element instead of padding on the body element. Causes far less conflicts. props aldenta, fixes #16222.

comment:7 follow-up: @scribu5 years ago

[17299] causes other absolutely positioned elements to be offset by 28px from their expected position.

This does not happen if the margin is set on the body element.

Last edited 5 years ago by scribu (previous) (diff)

comment:8 in reply to: ↑ 7 @koopersmith5 years ago

Replying to scribu:

[17299] causes other absolutely positioned elements to be offset by 28px from their expected position.

If I'm understanding you correctly, this is desired behavior. If the admin bar is on, it should be visible in any scenarios, unless explicitly disabled. The bar should obscure as little content as possible.

If I'm not understanding you correctly or you think this is undesired behavior, please post a screenshot.

@scribu5 years ago

comment:9 @scribu5 years ago

Screenshot.png demonstrates the problem. Previously, the tooltip would sit right above the highlighted element.

comment:10 @scribu5 years ago

The tooltip is generated with qTip2. I'll dig into the JS to see how it calculates the position.

comment:11 @koopersmith5 years ago

It seems to be a bug in qTip2. After testing with the newer version of qTip, the bug goes away. jQuery UI position functions properly as well.

comment:12 @scribu5 years ago

I'm using the one dated "Thu Jan 13 10:18:52 2011 +0000", so how new are we talking here? :)

comment:13 @WraithKenny5 years ago

There's a general issue with using css layouts with html, body {height:100%} but then assigning padding-top:28px; (etc) on either element... the element will then have > 100% height and induce (probably) unwanted/unneeded scroll-bars.

This is evident using 3.1-RC3 with Admin Bar enabled for Admin pages (in user profile settings). The solution for the admin page is to remove the 28px padding on body and instead assign it to #wphead.

For Themes, we can't predict the layout used unless the theme registers support (current_theme_supports( 'admin-bar' )). If a theme does register support, we can assume they added appropriate padding to an appropriate element, and it wouldn't need any injected css from WP core at all.

Note: See TracTickets for help on using tickets.