Opened 13 years ago
Closed 13 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)
#2
@
13 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.
#3
@
13 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.
#4
@
13 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') );
#5
@
13 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.
#6
@
13 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?
Sure it is.
Rare side effect, that won't be much alleviated with our own absolutely positioned div.
For logged in users only. This is by design, so "you don't have to scroll to the top of the page"
Please report problems, not solutions. This is the problem you're trying to report, isn't it?