Hello William,
Thank you for your input. I'm sorry you didn't get advanced warning. We do try as much as possible to post all upcoming features to our blog. Would you be willing to share where you go for updates and what would be your preferred medium to receive them?
We do understand the need to be able to brand your own Hub, which is why we allow space for a custom header, support CSS/HTML on the homepage, and have a theme builder that applies the theme across the whole app. We try to take up as little real estate as possible on the homepage by only controlling the navigation bar that contains search, notifications and sign in. We are reworking that to make it more minimal, but we're also trying to make it a better Hub experience for collaborators and visitors. For example, a visitor who enters a Hub from Google and lands someplace that is not necessarily the homepage should know who authored the content that they are viewing and find a consistent way to explore other initiatives and content. Our goal is to add more customization to these components (navigation, search collections, etc) and hopefully, this will encourage people not to hide our navigation outright, as doing so can detract from the overall usefulness of Hub.
ArcGIS Hub isn't strictly a website builder (although that is a very popular part of our app); it is a management framework for organizations to collaborate with partners and communities around initiatives relevant to their work through GIS content. This includes publishing content through websites and pages both internally and externally, but also engaging with community participants through events, surveys, and teams. There are many views in our app that currently do not support layout customization, including the search navigation bar, search results, dataset and item detail pages, event registration pages, and profiles. While we apply the theme from the theme builder and a custom header, if present, the reason we do not allow CSS on these views is to limit the likelihood we will break your site when we release new features.
We used to give everyone access to global CSS for the whole app when we were just Open Data, but unfortunately, people would absolute position all kinds of page functionality to get custom layouts. If our app were the equivalent of a static website, this might have been okay, but since we release bug fixes and feature updates nearly every week, we'd often break sites who had customized their layouts too heavily. Obviously, they would not be terribly happy with us because they'd have to adjust their CSS to compensate. With a couple thousand customers, we simply could not predict how people would be using CSS, and therefore, we'd be stuck because we couldn't release anything new without risk of affecting someone's global CSS implementation. This is why, in our app today, you have free rein over anything you want to do in your homepage with CSS, but we save just a tiny slice of the page as a safe zone to add new functionality so that we won't break your layout.
And as was the purpose of my original post, if you had hacked our safe zone (we understand, it happens) and were experiencing oddities as related to your custom header, we wanted to provide some tips that could help you troubleshoot faster in fixing your custom code.