Admin Bar pushed down at screens of 600px width and lower on the frontside

[Funkatronic]

On a window resized to the width of 600px, the Admin menu bar shifts down, obscuring part of the blog's front end. The culprit CSS is found in admin-bar.min.css. There is a declaration of position:absolute that only gets triggered when the screen is width 600px and below. Disabling this css declaration in Chrome's developer's tools fixes the issue.

Broken:

Fixed:

[SergeyBiryukov]

Could not reproduce with Twenty Fourteen or Twenty Thirteen.

[dd32]

More information is needed here, What theme are you running? What are the styles on *, body, and html? There's probably a position declaration there that doesn't play nice with the toolbar that needs to be looked into.

[Funkatronic]

Thank you for the feedback: found the problem. The Foundation framework sets body as position: relative whereas the admin bar sorta needs it at static. Closing this ticket and sorry for the trouble

[Veraxus]

Confirming this problem.

At 600px, #wpadminbar is changed from position:fixed to position:absolute.

In CSS, fixed position is always relative to the window, whereas absolute positioning is relative to the first ancestor element with a non-static position.

Many major front-end frameworks and boilerplates use positioning overrides ( e.g. position:relative ) on the html and/or body elements as routine corrective/normalization practice - so when the admin bar changes from fixed to absolute positioning, it does not snap to the top of the window as expected, but to the top of the body element, which has been shifted 46px from the top of the window due to the top margin.

Considering how commonplace explicit body element positioning is as a routine normalization practice (particularly when off-canvas layouts are to be employed), I would say that this constitutes a serious problem/oversight in core.

There are a number of potential fixes by theme creators, but this should be remedied in core.

When the screen is max-width:600px, the html and body should be explicitly set to position: relative (which is more common than not, anyway). The admin bar should then be positioned top:-46px to compensate. Problem solved.

[Funkatronic]

Replying to Veraxus:

Confirming this problem.

At 600px, #wpadminbar is changed from position:fixed to position:absolute.

In CSS, fixed position is always relative to the window, whereas absolute positioning is relative to the first ancestor element with a non-static position.

Many major front-end frameworks and boilerplates use positioning overrides ( e.g. position:relative ) on the html and/or body elements as routine corrective/normalization practice - so when the admin bar changes from fixed to absolute positioning, it does not snap to the top of the window as expected, but to the top of the body element, which has been shifted 46px from the top of the window due to the top margin.

Considering how commonplace explicit body element positioning is as a routine normalization practice (particularly when off-canvas layouts are to be employed), I would say that this constitutes a serious problem/oversight in core.

There are a number of potential fixes by theme creators, but this should be remedied in core.

When the screen is max-width:600px, the html and body should be explicitly set to position: relative (which is more common than not, anyway). The admin bar should then be positioned top:-46px to compensate. Problem solved.

Actually, wouldn't it be position:static since that is the default positioning for most elements in html? I tried relative and it stayed the same but static fixed the issue.

[lee@…]

I often have the body element set as relative and this problem is effecting me also.

Is the idea of making the admin bar absolute positioned instead of fixed at max-width 600px to save on screen real estate on smaller screens? The 46px of display is only lost when logged in and so not really an issue in my mind.

I would suggest the fix is to leave the element #wpadminbar position fixed at all screen sizes.

As a developer If I already had a fixed element at the top of the window on small screens I could push it down if necessary using the admin-bar body class. Easiest option to manage.

Cheers - Lee.

[Veraxus]

I think Lee's suggestion is probably the most practical. Definitely more practical than mine.

@Funkatronic: Yes, position:static is the default state, but putting position:relative on the body forces descendants to obey it's boundaries, which can provide numerous "mechanical" benefits (and avoid some hard-to-solve problems with certain layouts)... which is why it's so common.

[sagarjadhav]

Fixed position issue when logged in for smaller screens

[sagarjadhav]

Above issue can be replicated while using framework like foundation as already described by most of the users above.
Most of the frameworks apply position: relative to body.
For @media screen and (max-width: 600px) , WordPress adds a style for Admin bar
#wpadminbar { position: absolute; }

Removing that particular css fixes the problem, without causing any additional issue on any other device or browser.

[iammattthomas]

For the sake of background: the reason the adminbar scrolls at mobile sizes is because a fixed-height, fixed-position element causes major problems when you tap/pinch-to-zoom in mobile browsers. MP6 originally disabled zooming in mobile browsers but we were encouraged to allow it for accessibility reasons. So that's why the existing code is there.

As for a different technical solution for achieving the same effect without the problem described above: no opinion there.

[kirasong]

It looks like the consensus is that the current patch is not the ideal fix for this issue.

Going to suggest we move this off 3.9, since there isn't a current agreed-upon solution or patch.

[juiceboxint]

If you use the Google "Website Translator" widget anywhere on your page, it will force
position: relative on the body, so whether or not you wanted or needed to use body { position: relative } in your code, you may find that you get it anyway.

The best fix I've found to this is to set the body to position: relative in your CSS—so it's present on initial page load and doesn't cause any flashes when the JS does its thing—then add the following to handle the admin bar at screen sizes less than 600px:

@media (max-width: 600px) {
	html #wpadminbar { top: -46px; }
}

The admin bar still has placement issues when you actually use the translation while logged in, because Google adds its own "admin bar" to the top of the site—so it won't work as well if people who have accounts on the site will need to use the translation feature, but it should work in most situations anyway.

[morganestes]

I've tested this out on 4.3 trunk with Twenty Fifteen and can't reproduce it. Since it seems dependent on which theme is running and the styles specific to that theme (not core), I'm going to close this out.

If anyone can consistently reproduce this in a way that fixing it in core makes sense for the majority, we can revisit it then.

[atomicjack]

There is actually a fix that can be put into WordPress core to fix this for every theme.

Change the #wpadminbar to position:fixed;

That resolves the issue and doesn't cause any problems.

[ocean90]

Replying to atomicjack:

Change the #wpadminbar to position:fixed;

That resolves the issue and doesn't cause any problems.

We don't want to have a fixed toolbar on mobile.

[rogerlos]

This can be fixed by using the ::before pseudo element on the body tag, rather than setting a margin on html. If the body is relatively positioned or not becomes irrelevant at that point.

Here's a JS snippet which does this, but it would be worth considering changing the WP stylesheet to reflect this. (You'd want to de-bounce the resize call if using the JS below, or maybe use a mutation observer on the admin bar instead, in production.)

You could also potentially use your theme stylesheet to attempt to override the inline sheet added by WP, and use media queries to match the WP break points.

jQuery('document').ready( function ($) {

    // event listener, and run once when this script loads
    window.addEventListener( 'resize', fixadminbar );
    fixadminbar();

    function fixadminbar() {

        // get adminbar height, 'css' will be true if bar is present, false if not
        var ah = $( '#wpadminbar' ).outerHeight(), 
            css = typeof( ah ) !== 'undefined',
            $head = $('head');

        // if 'css' is true, change value to CSS rules
        css = css 
            ? 'html{margin-top:initial !important}'
                + 'body::before{content:"";height:' + ah + 'px;display:block}' 
            : css;

        // if this has been written before, remove old version
        $head.find('#wpadfx').remove();
           
        // append new if bar is present
        if ( css )
            $head.append('<style id="wpadfx">' + css + '</style>');
    }
});

[SergeyBiryukov]

#51617 was marked as a duplicate.

[zeinnicholas]

I'm baffled this is being ignored for 7 years now...