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

[koopersmith]

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.

[nacin]

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.

[nacin]

Ref: ​http://wordpress.org/support/topic/admin-bar-css

[nacin]

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

[aldenta]

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

[aldenta]

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

[dd32]

Looks fine in Opera.

[nacin]

(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.

[scribu]

[17299] causes absolutely (or relatively) positioned elements to be offset by 28px from their expected position.

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

[koopersmith]

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.

[scribu]

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

[scribu]

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

[koopersmith]

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.

[scribu]

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

[WraithKenny]

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.