WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#16969 closed defect (bug) (wontfix)

Stick admin bar to the top of the page, not the window

Reported by: scribu Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: UI Keywords:
Focuses: Cc:

Description

I would like to contend that having the admin bar visible at all times, even when scrolling down the page has more drawbacks than benefits:

Benefits:

  • you don't have to scroll to the top of the page

Drawbacks:

  • less vertical space for content
  • url hashes don't work properly
  • other absolutely possitioned elements can be misaligned

If there are other benefits that I'm not seeing please mention them, or add a link to a discussion where they were mentioned.

PS: The fact that this is how it worked on wp.com is not a valid argument.

Change History (8)

comment:1 nacin3 years ago

PS: The fact that this is how it worked on wp.com is not a valid argument.

Sure it is.

other absolutely possitioned elements can be misaligned

Rare side effect, that won't be much alleviated with our own absolutely positioned div.

less vertical space for content

For logged in users only. This is by design, so "you don't have to scroll to the top of the page"

url hashes don't work properly

Please report problems, not solutions. This is the problem you're trying to report, isn't it?

comment:2 scribu3 years ago

Yes, it started from the url hashes drawback.

But also, I don't think this particular implementation detail was seriously discussed. I would love to be proven wrong, though.


Rare side effect, that won't be much alleviated with our own absolutely positioned div.

It doesn't have to be absolutely positioned: $('body').prepend('#wpadminbar');


This is by design, so "you don't have to scroll to the top of the page"

As I see it, the major goal is to have a series of useful links always available on every page, in a consistent place, not necessarily visible at all time.

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

comment:3 scribu3 years ago

It would make sense to have the admin bar always visible if it was dynamically updated with the number of comments awaiting moderation, for example, but since it's static, it doesn't make sense.

comment:4 WraithKenny3 years ago

For a work-around, wrapping the #wrapper in another element, you can set:

<div style="
position: fixed;
top: 28px;
bottom: 0pt;
left: 0pt;
right: 0pt;
overflow: auto;">
<div id="wrapper">...</div>
</div>

Or using an id and a style element via the callback for add_theme_support( 'admin-bar', array( 'callback' => 'admin_bar_bump_callback') );

comment:5 aaroncampbell3 years ago

To expound on what Nacin said about the wp.com argument, I think it's a valid argument because wp.com is a massive testing ground with tons of users. I'm not saying it's not possible to do something BETTER than wp.com, but I think that ignoring what's working well on wp.com would be a big mistake.

Having said that, I'm also against moving the bar to the top of the page. The point of the bar is to have tools instantly available to you, not "nearby but out of sight". I just think it would lose some effectiveness.

I also wonder how many sites use a lot of url hashes, have users logged in often, AND want to keep the admin bar around for those users. The admin bar seems like it's most useful for those that are working on the site. If a site has a lot of logged in users that don't work on the site, and the admin bar is causing problems (like messing up url hash links), they could just hide the admin bar for all or at least most users.

comment:6 GaryJ3 years ago

If the url hash links are an issue because the desired content is starting under the admin bar, could an extra bit of JS not be added (for logged in users who are showing the admin bar) that jogs the vertical scroll by another 28px (or whatever the jog needs to be so the content isn't butting up against the admin bar if there's no padding on the content element) when the URL contains a hash?

comment:7 scribu3 years ago

@GaryJ: Yeah, I guess it could be mended that way.

comment:8 scribu3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Guess it's not going to happen. Similar: #17481

For the vertical scroll, a new ticket should be opened, although I have a feeling it would introduce more problems than it would fix.

Note: See TracTickets for help on using tickets.