Twenty Thirteen: remove fixed navbar

[lancewillett]

Discussing today in IRC dev chat ​log the pros and cons of the fixed navbar. Since it doesn't hold a menu, and duplicates the native WordPress navbar -- not to mention creates a bit of UI bloat by having them next to each other -- we think it'd be best to get rid of the feature.

[lancewillett]

Clean up header.php

[celloexpressions]

Replying to lancewillett:

Since it doesn't hold a menu, and duplicates the native WordPress navbar

Any particular reason for not including the menu there? Maybe you could hide it for logged in users? I've found it fairly useful, with the menu (and search) there in child themes.

[lancewillett]

Replying to celloexpressions:

Replying to lancewillett:

Since it doesn't hold a menu, and duplicates the native WordPress navbar

Any particular reason for not including the menu there? Maybe you could hide it for logged in users? I've found it fairly useful, with the menu (and search) there in child themes.

Yes, too complex and "clever" for a default theme. I think it's perfect for a child theme, or a plugin, to add that functionality.

[celloexpressions]

Replying to lancewillett:

Yes, too complex and "clever" for a default theme. I think it's perfect for a child theme, or a plugin, to add that functionality.

Agreed. And they won't necessarily need to worry about all the extra code for IE 8 compatibility.

[lancewillett]

@obenland Did you have more thoughts to add here? If no more comments or suggestions, I'll go ahead and commit the removal.

[obenland]

I'm sad the IRC decision went in the direction it did.

There were three arguments I could make out in the discussion log for removing it:

• It's not super useful
• When you're logged in or have a logged-out toolbar, you get double bar'd
• It disables the CSS for the toolbar

It's not super useful

Starting a theme process with design, removes the argument that everything about that theme needs to be functional. The fixed navbar is one of the immediately noticeable features that set Twenty Thirteen apart from other themes. It is a visual design element and originally was not meant to serve a specific functional purpose. Nevertheless, with the home link, the search form, and the scroll-to-top functionality, we went out of our way to make the fixed navbar more than just the design element it was intended to be.

When you're logged in or have a logged-out toolbar, you get double bar'd

The argument of duplicate functionality with the admin toolbar leaves out the vast majority of visitors, that are not logged in when viewing a site. And mobile users, who will never see a fixed navbar.

If that wasn't persuasive enough, we can still make it dependent on is_admin_bar_showing() if the additional 28px are really that bad.

It disables the CSS for the toolbar

We removed the code disabling the toolbar callback in r24036, and significantly improved the performance of the scroll event callback in r24005.

The loss of code is marginal really, compared to other parts of the theme, like the right sidebar. And IMO it doesn't justify the loss of identity that goes with removing it.

I love the improvements Twenty Thirteen saw over the last two and a half months, especially the short (and I believe not yet finished) functions.php walk trough with Nacin. But I feel that some recent tickets and changes weren't really improvements, but rather steps back. Like removing the navbar would be.

[RDall]

That is quite well written obenland. I didn't comment previous because I thought the decision had already been made. After reading your comments I though I would share my own.

I do like the bold decision to give the fixed nav bar… It is a clear exit from previous default themes. I think that is a good thing. If we want this theme to be bold… Lets not hold back and lets be bold with it.

The only issue I have with the Fixed Navbar is that if a blog needs a both a logo and the blog title How is that being accommodated in the design? How easily can that be accommodated in a child theme of Twenty Thirteen? For Example: "WordPress Logo" News Or "Nike Swoosh Logo" Running Blog.

Removing the Navbar would solve that issue. But also some cachet attached to the theme as well…

Can it be revisited? Can it be added later? Can it be a option the theme user can turn on? These are a few questions that came to mind after reading Obenland's comment.

[johnjamesjacoby]

I have four reasons we should keep the fixed nav bar:

• Anecdotally, I've been showing it off as a feature of the unreleased WordPress default theme to friends and at meet-ups, and for some reason, it's always a crowd pleaser -- 0 people have said "Ew how do I stop that."
• Every year since twenty-ten, we've reinvented WordPress with a new theme. So far, each of these themes tend to showcase what's sexy at the time. Right now, it's fixed position header strips.
• 3 years from now we'll look back at it longingly the way we do TwentyTen (Green Day's "Time of Your Life" will be playing softly in the background) and we'll think to ourselves "what were we thinking; that fixed position header strip was the cat's meow!" (3.0 kitteh hat-tip)
• I like it.

[philiparthurmoore]

I have nothing to add other than a huge +1 for keeping the fixed nav bar. It's a design feature of the theme that makes it very Twenty Thirteen, and taking it out would make it lose some of its total jazz in my opinion.

[knutsp]

I agree with the latest commenters. Keep the nav bar. I guess it's easy to remove it by a plugin, or in a child theme.

[lancewillett]

Hmm, where were all you +1s at the last dev chat? Would have been nice to have counterpoints at that time.

[wonderboymusic]

​http://www.youtube.com/watch?v=i28UEoLXVFQ

[philiparthurmoore]

Replying to lancewillett:

Hmm, where were all you +1s at the last dev chat? Would have been nice to have counterpoints at that time.

Probably asleep in Tokyo. Not everyone can make IRC chats based on timezone issues.

[nacin]

Good points here. I'm still a pretty strong no.

This is not just the newest default theme for WordPress. This is a theme that hundreds of thousands of people are going to open up and tear apart. If the original developers involved in putting Kubrick together knew most of us would have learned WordPress theming through it, do you think they would have done X, Y, and Z differently?

A default theme should be elegant. Not just in design, but in code. It needs to be simple. Too clever is cool on occasion, and is often just fine when it is buried in some internals. Too clever is not cool when people who are not programmers are going to be dissecting this theme and those who are programmers using it as a baseline for the next 12-24 months.

The standard we hold a default theme should be unique. It is most certainly more constraining — by its necessity as a standard-bearer and as a learning tool. It's because it sets a particular bar: "this is how you code a theme." And yet, despite those constraints, we have a pretty great, bold design here.

This theme makes more than enough of a statement when it comes to design. Does it really, honestly need this too? Twenty Thirteen is nearly 2,000 lines of PHP. That is a good chunk of code. (Also 5,000 lines of CSS.) We're now talking specifically about 126 lines of not uncomplicated JavaScript, and for what? This is not amazing, nor is it must-have. This is scroll-to-top, some nifty fixed positioning, and what really just looks like a lot of code cruft and an over-the-top bell/whistle we couldn't part with because reasons.

(Side note: if we bundled vanilla masonry (​http://vanilla-masonry.desandro.com/), we could get rid of the jQuery dependency all together.)

[celloexpressions]

Replying to nacin:

This is a theme that hundreds of thousands of people are going to open up and tear apart.
A default theme should be elegant... Too clever is not cool when people who are not programmers are going to be dissecting this theme and those who are programmers using it as a baseline for the next 12-24 months.
it sets a particular bar: "this is how you code a theme."

I think that if the implementation of the fixed navbar is as elegant as possible (it seems to be pretty good), then we're giving all of these people a better baseline. Since this is a popular design feature at the moment, think of how many people will do it better using Twenty Thirteen as a framework than if they tried to do it from scratch. It's easy enough to remove, but tricky to add on. We're basically saying, with this particular feature: "this is how you code a fixed navbar in your theme."

This theme makes more than enough of a statement when it comes to design. Does it really, honestly need this too? We're now talking specifically about 126 lines of not uncomplicated JavaScript, and for what? This is not amazing, nor is it must-have. This is scroll-to-top, some nifty fixed positioning, and what really just looks like a lot of code cruft and an over-the-top bell/whistle we couldn't part with because reasons.

I think it is worth it. Especially on large monitors (>1600px), to me it really helps sell the experience of scrolling through all of the bands of color, with one small band of persistent color. Thinking about it more, it really is a design element more than a functional element. If it tried to include a menu, that probably would be "too clever." As you say, there's a lot of code. Maybe it's worth looking for other elements that could lose some, or looking for places to increase efficiency. There's not all that much code in this particular feature, though, for what it does design-wise.

[taupecat]

Adding my $0.02…

I would vote to remove the fixed nav bar, but I'm probably biased b/c I don't like fixed nav bars like this in general.

The implementations usually work well enough in desktop browsers, as is the case here, but in this particular instance it's not adding a ton of functionality. There's no visual or other clues that clicking on the nav bar will take you to the top of the page (and that's not enough of an ingrained pattern across the web for people to know it automatically). Such functionality is just as easily achieved by clicking the "home" button on my keyboard. So ultimately this fixed nav feels like a waste of space, albeit not a huge one. (A huge one would be the one I have to put on this project I'm building at work… dear g-d is it a ton of dead pixels! But I digress…)

As for iOS (can't speak to Android, b/c I don't have any Android devices), the implementation of fixed nav bars is never as good. I tested the most recent SVN commits on my iPad, and there was a HUGE lag in the time I scrolled up past the normal header's visibility and when the fixed nav actually appears. Ditto for scrolling back to the top of the page. I got the same results in iCab Mobile as well, so it's just a reinforcement that tablet browsers don't handle fancy CSS/JavaScript tricks like this as well as their mouse & keyboard cousins.

And besides, clicking the clock at the top of the tablet screen takes you to the top of the page, and that functionality pattern is slightly more widespread than clicking on the nav bar, although to be fair I run across lots of people who don't know you can do that in practically every iOS app.

I agree with Nacin in that the fixed nav bar is not the be all & end all of Twenty Thirteen. The color scheme and the enhanced support for post formats are really the gems of this release.

Thanks.

[markjaquith]

I don't find the arguments for keeping the fixed bar very persuasive.

Also:

[lancewillett]

In 24169:

Twenty Thirteen: remove fixed navbar. Closes #24184.

[johnjamesjacoby]

Replying to lancewillett:

In 24169:

Twenty Thirteen: remove fixed navbar. Closes #24184.

That's too bad. I really liked that navbar.

[billhector]

okay, you removed it. Are there instructions on how to activate it in a child theme?

[ocean90]

Replying to billhector:

okay, you removed it. Are there instructions on how to activate it in a child theme?

Take a look at the commit [24169].