Help! My Office 365 Suitebar turned black!

Recently I’ve been doing a lot of work in Office 365 for a client, and I must admit I’m loving it. No more fuzzing about with installations of Service Applications, or going in to IIS to see why the site isn’t performing the way it should – all of that stuff is managed by Microsoft for you. However, that also comes with a big ‘but’: forced updates.

Let me explain. In Office 365 updates are going to happen whether you like it or not. That’s all fine, and usually a great thing because it means you get all the new and shiny stuff quickly, while those with on-premises installations have to wait for a SP or even a next release. Microsoft introduced the ‘First Release’ feature which allows you to receive these new updates for a particular user (or tenant if opted that way) before it gets rolled out to your entire company or production tenant, which is a great feature and comes in handy when testing out new functionality or an upgraded UI. There are still some changes however that can have major impact on the UI of your SharePoint sites that are not pushed through the First Release function, nor are they communicated about in any way.

One such major UI changes occurred a few weeks ago, around the 25th of August 2015. Let me explain the scenario first, and then I’ll get into the details of the change (and how to fix it). We have several SharePoint Site collections that serve a different purpose. We have site collections that are meant purely for collaboration and contain team- and projectsites. Then we have site collections that are used for corporate communications, such as news, latest announcements, company history and vacancies, that kind of stuff. And lastly we have site collections meant for document management solutions. We opted to have as minimal customizations as possible, but we did want our end users to know which of the three intranet area’s they were currently visiting. We thought that theming (or Composed Looks) would be a great way of showing this. We created several color files and themes: blue; green and orange. The Suite bar would be the main way of determining which of the area you are visiting, and as an added bonus, it made communication about the new intranet a lot more clear (e.g. ‘Green’ received a major update today by allowing you to create your own team- and projectsites).

In came Microsoft and their forced updates. All of a sudden our themes were no longer applied to the Suite Bar. Everything else would still be visible, so links would still be a certain color and Page Titles were also still fully functional. The Suite Bar however was totally black, which is the default tenant setting. Our initial thought was that Microsoft must have had an update that contained a bug of some sort which is why this was no longer working. It wasn’t just for our own Themes, but the OOTB themes also no longer changed the Suite Bar color, so clearly something was going on. We opened up a premier support ticket and after a few days of investigating (for some reason they received lots of support calls about theming – geez, weird huh?) they replied the following:

Due to a multitude of customers’ request we changed the behavior.

What it comes down to is that customers want to keep the Suite Navigation bar the same across Site Collections regardless if a Site Collection administrator or a user wants a different theme.

Mainly because they want to keep the ‘Company’ color

Right. Okkaayyyy. It’s not a bug, it’s a feature! A non-communicated feature, which happened in our production tenant before it happened in our first release enabled test tenant. And it happened three days prior to going live with our ‘Blue’ intranet area, which was now no longer blue.

I can see the reasoning behind this ‘feature’. It does make sense to have one Office 365 company theme being pushed to your entire tenant, rather than let each site collection have their own color. I would have preferred it if they had gone about this a bit differently though. A few weeks prior to this change Microsoft added a new feature to the Company Profile – Theme section of Office 365:


Users can override a company theme in their Office 365 settings, but when this option is checked, those overrides are no longer valid. It would have made sense if they added a second check box here to ‘Prevent Site Collection administrators from overriding custom theming with their own theme’. That would enable tenant administrators to have control over the theming behavior, rather than the company theme being pushed down whether you like it or not. Alas, who knows, maybe Microsoft will add that second checkbox in the coming weeks or months.

Luckily there is still a way in which we can restyle the Suite Bar back to our ‘original’ color and that comes in the form of custom CSS styling. A few simple CSS lines will enforce the suite bar to turn back to the color of your choice. Using the CSS below, our Suite Bar turned back to an awesome shade of blue:

/* Fix the Office365 Suite bar */
.o365cs-base.o365cst .ms-bgc-tp,
.o365cs-base.o365cst .ms-bgc-tp-h:hover,,
.o365cs-base.o365cst .o365cs-topnavLinkBackground-2

I’m not a fan of !important – rather I try to avoid it at all times. However because the Suite Bar is loaded dynamically, it will reset back to black (or rather – the company profile theme color) if you don’t add it.

That’s it. You can add additional statements to this CSS to ensure the hover color is also set correctly, but in most cases this will be all. Simply add this CSS to any already referenced CSS file in your site collection. If you don’t have one yet, you can either use the Alternate CSS URL, or use CSS Injection techniques to make sure it is applied to every site within the site collection. In our case we already had a different CSS file for each section of the intranet, which were all referenced from a centralized location, so it wasn’t that much work. I can imagine however that if you have a multitude of site collections with a multitude of different Suite bar color, you have your work cut out for you. Oh well, I guess it’s not all peaches and cream being in Office 365 and having Microsoft manage a lot for you.


iOS scrolling issues in a SharePoint Online Public Website

SharePoint online allows you to create a Public Facing Website (atleast, until March 2017 for existing customers, read more). Although the public website has some limitations, there are still some pretty cool things you can do with it.

For a customer of ours, I have implemented a responsive design using the Public Facing Website. I used the default corev15 styling css, and added an additional css file to do all the custom styling. When testing the website on different devices though, I came across a strange bug. For all iOS devices, the vertical scrolling was ‘groggy’, or simply very very slow. This resulted in a poor user experience, especially for pages which had quite a bit of content.

Turns out there is a pretty easy fix for this. In the corev15 the basic scrolling is implemented in two different css statements, as shown below:




If you want to fix this annoying bug, you can simply add ‘-webkit-overflow-scrolling: touch;’ to the #s4-workspace css rule. Tada, scrolling is now as you would expect it to be in the first place. Gotcha!

If you’re not using a custom masterpage or CSS file, you can simply add the CSS markup by clicking on ‘Site’ and ‘Edit style sheet’ from the ribbon. Add the markup below:

-webkit-overflow-scrolling: touch;

That’s it, you’re all set! Happy coding.