Kill Sticky Headers (2013)(alisdair.mcdiarmid.org)
alisdair.mcdiarmid.org
Kill Sticky Headers (2013)
https://alisdair.mcdiarmid.org/kill-sticky-headers/
83 comments
Exactly. When I'm using an application called a browser to view a document on the web, I don't want the document to try to become part of the chrome: that breaks the "web page" metaphor. There is a very small subset of websites, such as Figma, that feel more like independent applications than web pages, and for those I get more annoyed by the presence of the browser chrome, for basically the same reason.
What's worse, almost no sticky header has any useful items in it. Take StackOverflow as an example. It has a link to the homepage and a searchbar, in spite of the fact that many frequent StackOverflow users have never visited the homepage and never used the built-in search. The top of the screen is the most valuable part, because my head is usually above the screen, so it's more comfortable for my eyes to rest around the top of the viewport. So if you put something there, it had better be important.
What's worse, almost no sticky header has any useful items in it. Take StackOverflow as an example. It has a link to the homepage and a searchbar, in spite of the fact that many frequent StackOverflow users have never visited the homepage and never used the built-in search. The top of the screen is the most valuable part, because my head is usually above the screen, so it's more comfortable for my eyes to rest around the top of the viewport. So if you put something there, it had better be important.
You should hit f11 if you're working in an app and are upset with the browser bar. Go full screen or go home.
Sticky headers just become part of the window to me. Like everything, some are better than others. Some are horrendous with flashing video/banners/etc. Some are useful so that the site navigation is always available regardless of page length. I personally hate having to scroll back to the top just to jump to the next section. This website is too hot, this one is too cold, this one is almost just right. Can't please 100% of the users, ever.
I think the only time sticky headers are ever acceptable is when you need to regularly refer back to them. Long tables without sticky headers are the worst
Or use recfile syntax instead of a table.
Columns can be easily collapsed or hid; wasting vertical space is a worse solution than wasting horizontal space
Also tables align nicely in a grid, recfiles do not
Also tables align nicely in a grid, recfiles do not
One might be bigger than the other, but in absolute terms both are just big.
In a big grid you can't make sense of the cells anyway, so that alignment has no function beyond being just an alignment.
In a big grid you can't make sense of the cells anyway, so that alignment has no function beyond being just an alignment.
Unless you browse the internet in a frameless full screen window, there are a lot of other elements stuck at the top of it (or at the bottom)
It might be you're overreacting to something it's not really a big deal in general
It might be you're overreacting to something it's not really a big deal in general
Ever since I started using unlock origin's cosmetic filters to remove headers, footers and sidebars from most websites I visit, the web has become a much more enjoyable place. These 'engagement hacks' do little other than make your website look cluttered and distracting, which probably gets misinterpreted as 'engagement'.
You can add https://github.com/yourduskquibbles/webannoyances#one-click-... to UBlock Origin as a custom list instead of removing them yourself.
Disclaimer: I've never tried it.
Disclaimer: I've never tried it.
Thanks! Just added it. For others, the list was last updated a few hours ago and successfully makes the sticky headers on ESPN and the NYT's websites (the examples listed on the README) nonsticky while leaving them usable when I'm scrolled to the top of the page.
Thank you! Installed. Commenting so I can find it later and put on other computers.
Please don't comment for that reason. Favorites are intended for things like this. To add a comment to your favorites list, click on its timestamp to go to its page, then click 'favorite' at the top. You can revisit your favorites from your profile.
you can also use uBO's ":style()" function to override css properties and effectively "un-sticky" the majority of header/nav elements if you prefer not removing them completely. I use these two filters to globally un-stick every header and nav element which uses CSS position properties to sticky themselves (which is a good many of them):
##header:style(position: absolute !important)
##nav:style(position: absolute !important)I use a more simplistic solution: I bind a keyboard shortcut to uBO's element zapper so I can just zap sticky headers as I find them. I have to zap for every repeat visit, but the same shortcut works for zapping sticky sidebar videos or other undesirable elements too.
It took me awhile to realize how bad sticky divs are for my users. Justification of using sticky elements was that they were always visible. But why? Because they are frequently accessed elements? Scrolling to top doesn't take much of effort. They might be frequently accessed, but they were also not that hard to access.
It hit me hard, when I saw my user's screen which was relatively small and my sidebar and header were both sticky, leaving only a small area to display the main content.
I've now gone back to mostly non-sticky elements. It's refreshing. Not seeing those "frequently accessed" elements isn't much of an issue. I don't think I ever complained about popular websites not having its header sticky.
Letting users focus on the main content has been by far the most beneficial thing from my perspective.
It hit me hard, when I saw my user's screen which was relatively small and my sidebar and header were both sticky, leaving only a small area to display the main content.
I've now gone back to mostly non-sticky elements. It's refreshing. Not seeing those "frequently accessed" elements isn't much of an issue. I don't think I ever complained about popular websites not having its header sticky.
Letting users focus on the main content has been by far the most beneficial thing from my perspective.
Thank you.
As a user of a laptop with a small screen, I can say that, at least where I'm concerned, making those "frequently accessed" elements sticky is a great way to ensure I won't access them that much. I don't much go for non-enjoyable reading experiences. So I'm either going to hit the reader button to make the header disappear from my life, or, if that's not an option, I'm going to read what I came for and then go somewhere more fun.
As a user of a laptop with a small screen, I can say that, at least where I'm concerned, making those "frequently accessed" elements sticky is a great way to ensure I won't access them that much. I don't much go for non-enjoyable reading experiences. So I'm either going to hit the reader button to make the header disappear from my life, or, if that's not an option, I'm going to read what I came for and then go somewhere more fun.
I just finished studying Multimedia design at KEA (Copenhagen School of Design and Technology), and I was surprised how popular sticky headers were among the teachers. Some even arguing they improved the browsing experience. Clearly they could not be more wrong.
I think part of the issue is, educationally, people gets told that sticky headers and huge font-size or white space is good design. In reality, they are just chasing away people from their websites.
Webdesign trends are so hostile towards users...
I think part of the issue is, educationally, people gets told that sticky headers and huge font-size or white space is good design. In reality, they are just chasing away people from their websites.
Webdesign trends are so hostile towards users...
Web design isn't the solution.
Web design is the problem.
(In fairness: 99% of Web designers give the other 1% a bad reputation.)
Web design is the problem.
(In fairness: 99% of Web designers give the other 1% a bad reputation.)
There are few things that frustrate me more than scrolling down a web page, while trying to read and article, and having the header become sticky and obscure what I'm reading.
As far as I can remember, the _only_ app I've ever seen get this exactly right (in terms of not ever obscuring text) is the New York Times' Android app.
As far as I can remember, the _only_ app I've ever seen get this exactly right (in terms of not ever obscuring text) is the New York Times' Android app.
It's even worse when it only appears when you're scrolling up. You want to scroll up one line to re-read the sentence that scrolled off screen. Nope, now you have to scroll 50px because the navbar spawned. Oh, it's gone again. Nope, it's back, I didn't even mean to scroll up 1px that time.
It's no wonder my girlfriend makes more than I do as a UX professional. Someone on the team that actually has the users' interest at heart is critical. Else you get these ridiculous break-room ideas that nobody spent more than 5 seconds thinking about.
It's no wonder my girlfriend makes more than I do as a UX professional. Someone on the team that actually has the users' interest at heart is critical. Else you get these ridiculous break-room ideas that nobody spent more than 5 seconds thinking about.
What’s funny, there is a good way to do that: just look how ios safari urlbar works. When you scroll up, it collapses and bottom menu slides off-screen too. Then when you scroll up by dragging it (no ‘kick’ up), it remains collapsed. But if you ‘kick’ up, it shows both urlbar and bottom buttons at full size. It’s like that since ios 7, afair.
Websites just show it on scroll-up no matter how you do it, so annoying.
Websites just show it on scroll-up no matter how you do it, so annoying.
What do you mean by "kick up"?
Put your finger on screen, move it quickly enough down, lift it while moving, so content still scrolls inertially. As opposed to put, drag, stop, lift.
Sticky page headers are easy to implement and bad for UX. On the contrary, sticky table headers would be really helpful for long tables and it is impossible to implement them without compromises (fixed column width only, opaque background only or JS-only etc.)
This is a real failure of browsers, by the way. The table HTML has all the semantic information necessary, browsers could use it to improve table usability (such as sticky headers) but none ever bothered to try.
Developers can opt into this with CSS now.
th { position: sticky; top: 0; }
I don't think it would have been reasonable to include/force such functionality at the spec level.
th { position: sticky; top: 0; }
I don't think it would have been reasonable to include/force such functionality at the spec level.
Unfortunately this only works on `th` and not `table > thead` or even `thead > tr` which is annoying because things like `tr` backgrounds won’t be displayed which look ugly if you have cell spacing without a cell border.
For people who would like a more concise source (in ES6 & a bit of functional style):
You can add javascript: links to your bookmark by adding any bookmark & changing the URL.
[...document.querySelectorAll("*")].filter(el => getComputedStyle(el).position === "fixed").forEach(el => el.parentNode.removeChild(el));
javascript:[...document.querySelectorAll("*")].filter(el%20=>%20getComputedStyle(el).position%20===%20"fixed").forEach(el%20=>%20el.parentNode.removeChild(el));
You can add javascript: links to your bookmark by adding any bookmark & changing the URL.
Thanks! That's a lot easier on the eyes!
So I did this:
So I did this:
javascript:(function()%7B(function () %7Bvar i%2C elements %3D document.querySelectorAll('body *')%3Bfor (i %3D 0%3B i < elements.length%3B i%2B%2B) %7Bif (getComputedStyle(elements%5Bi%5D).position %3D%3D%3D 'fixed' || elements%5Bi%5D.className %3D%3D%3D 'awsui-flashbar') %7Belements%5Bi%5D.parentNode.removeChild(elements%5Bi%5D)%3B%7D%7D%7D)()%7D)()
Speaking of "concise", in modern browsers you can replace el.parentNode.removeChild(el) with just el.remove():
https://developer.mozilla.org/en-US/docs/Web/API/ChildNode/r...
https://developer.mozilla.org/en-US/docs/Web/API/ChildNode/r...
Sticky navigation on desktop that is appox the height of the Hacker News nav and does NOT include ads is fine with me. I loathe sites that have a sticky header with a 970x250 ad, however, such as the Washington Post.
Sticky navigation on phones is not OK, but I actually like when the nav pops down when I scroll back up. A "peek-a-boo" nav, if you will.
Sticky navigation on phones is not OK, but I actually like when the nav pops down when I scroll back up. A "peek-a-boo" nav, if you will.
I like the well done hiding nav bar in my browser but the web ones tend to go mental popping up and down randomly. And then it just magnifies the crappiness when you have 2 stacked nav bars from the browser and website which are both trying to hide/unhide.
The ideal hiding navbar is one which is the only one on the screen and one which only pops down as much as the user scrolls so you have to scroll up one navbars worth to get the full thing and not the ones where you scroll up 1 px by accident and the full navbar flys down
The ideal hiding navbar is one which is the only one on the screen and one which only pops down as much as the user scrolls so you have to scroll up one navbars worth to get the full thing and not the ones where you scroll up 1 px by accident and the full navbar flys down
Really? I feel like a navigation stuck to the top on a phone is a must. Scrolling on a phone us much more complicated and tedious than with a mouse; as long as it's small and not intrusive.
That's a good post. The sticky elements is one of the most annoying things on the web. So after getting annoyed enough I made a simple extension that hides them. It automatically hides the sticky elements on nearly all websites, has a whitelist, and handles special cases like sticky splash screens. It runs on desktop browsers and mobile Firefox.
https://github.com/lykahb/sticky-ducky
https://github.com/lykahb/sticky-ducky
It's worth noting that this solution will not work for anything using the relatively new `position: sticky`
> relatively new
sticky has been around since at least 2014
sticky has been around since at least 2014
sticky was originally added to Chrome in 2014 behind a flag, but that implementation was removed and the feature wasn't reimplemented and released to stable until 2017.
Also "relatively new" is still accurate in web terms, which has specifications dating to the 90s.
Also "relatively new" is still accurate in web terms, which has specifications dating to the 90s.
Most other browsers had it for a long time before 2017.
>Also "relatively new" is still accurate in web terms, which has specifications dating to the 90s.
The majority of web features are relatively new under this definition.
>Also "relatively new" is still accurate in web terms, which has specifications dating to the 90s.
The majority of web features are relatively new under this definition.
"a long time" = a maximum of three years?
I think the two of us just disagree on how spans of time should be labelled.
I think the two of us just disagree on how spans of time should be labelled.
[deleted]
Yet this blog post is from 2013, so relative to that, it's new.
Be a dear, and add this to your page.
@media (max-height: 700px) {
.My-Sticky-Header-Selector {
position: absolute;
}
}Yes! Sticky headers sometimes have their place (usually not), but they should never be used on short viewports, such as on phones in landscape mode.
The viewport/scrollbar issue can be fixed by properly setting the css scroll-padding property: https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-padd...
Many try, but nobody quite gets it right.
Sticky headers aren't necessarily full-width, or overlapping the content, which invalidates most if not all of the criticism.
Eg. see the sticky headers in the mobile Google Calendar app (on Android at least).
Even in this very article, which self-referentially demonstrates how a sticky header gets in the way, there are sizeable margins on both sides of the text (something I'm personally not very fond of, but I digress).
Now, the sticky header, should it contain any useful information, could very well be moved to one of these empty areas, without obscuring the text, without disrupting the scrolling experience etc.
Eg. see the sticky headers in the mobile Google Calendar app (on Android at least).
Even in this very article, which self-referentially demonstrates how a sticky header gets in the way, there are sizeable margins on both sides of the text (something I'm personally not very fond of, but I digress).
Now, the sticky header, should it contain any useful information, could very well be moved to one of these empty areas, without obscuring the text, without disrupting the scrolling experience etc.
> there are sizeable margins on both sides of the text (something I'm personally not very fond of, but I digress).
Really? I find having text flow to the full width of the browser to be harder to read. I think there should be some limit.
But I do like your idea of using that empty space when the browser is wide enough to make it available.
Really? I find having text flow to the full width of the browser to be harder to read. I think there should be some limit.
But I do like your idea of using that empty space when the browser is wide enough to make it available.
I don't mean literally 100% of width.
But this website - on my 24" monitor - uses merely 35%; 900 out of 2560px. You (should) know you've gone over the top when the margins end up taking twice as much space as the actual content. What a waste of screen estate, what's the point of a wide monitor then?
That's why the user has to scroll constantly, and we can't read a text comprised of just several paragraphs without taking our finger off the mouse wheel anymore. It's like printing newspapers on till rolls
But this website - on my 24" monitor - uses merely 35%; 900 out of 2560px. You (should) know you've gone over the top when the margins end up taking twice as much space as the actual content. What a waste of screen estate, what's the point of a wide monitor then?
That's why the user has to scroll constantly, and we can't read a text comprised of just several paragraphs without taking our finger off the mouse wheel anymore. It's like printing newspapers on till rolls
But what I'm trying to say is that I think you're looking at it from the wrong perspective. It's not the margins that are too wide, it's the text that's too narrow.
This may sound like the same thing but it's not. It doesn't matter what percent of the page is taken up by margins, so long as the physical line length vs. font size is comfortable to read. Too long and it's harder to follow, too short and, as you say, you have to scroll constantly. If you had the same physical text width but a smaller font, it'd be better (so long as the font was still big enough to read comfortably).
Classical research suggests the ideal line length is somewhere between 45 to 75 characters. For the web it's suggested you can go up to 85 characters, depending on the font. This website sets the maximum width at 36.5em which is on the narrow side of things.
This may sound like the same thing but it's not. It doesn't matter what percent of the page is taken up by margins, so long as the physical line length vs. font size is comfortable to read. Too long and it's harder to follow, too short and, as you say, you have to scroll constantly. If you had the same physical text width but a smaller font, it'd be better (so long as the font was still big enough to read comfortably).
Classical research suggests the ideal line length is somewhere between 45 to 75 characters. For the web it's suggested you can go up to 85 characters, depending on the font. This website sets the maximum width at 36.5em which is on the narrow side of things.
I used to have this in my bookmarks bar as 'defuck page' but decided that name was too awkward for work when projecting my screen.
there's a more advanced version of this that is an extension. it offers a fixed delay, adjustable per site. so you can nuke slide-overs and html5 popups as well. it isn't perfect but it's still a useful tool. sorry i don't have the link handy as i'm not using that extension currently.
there's a more advanced version of this that is an extension. it offers a fixed delay, adjustable per site. so you can nuke slide-overs and html5 popups as well. it isn't perfect but it's still a useful tool. sorry i don't have the link handy as i'm not using that extension currently.
My “kill sticky” bookmarklet gets used dozens of times a each day (that might be an exaggeration, but not by much). I treat my browser profiles as mostly ephemeral, discardable, and instead of browser bookmarks I have https://dotat.at/:/ ... except for kill sticky, which gets added to a new profile right after uBlock Origin and 1Password.
Theres always my extension to toggle the darn things which works sometimes https://chrome.google.com/webstore/detail/zapfixed/jgiflpbko...
Relevant GitHub repo: https://github.com/eemeli/chrome-kill-sticky
I use "Click to Remove Element" Chrome extension: https://chrome.google.com/webstore/detail/click-to-remove-el...
I'm gonna go out on a limb and say that the majority of users don't use spacebar for scrolling in 2019. Besides that (and the screen real estate), I'm not sure it's bad enough to need a bookmarklet to kill it.
The issue that was raised isn't just about the Spacebar. It's about scrolling by full-pages, so PgDown/PgUp would also have the same problem when a page has Sticky Headers.
I guess you can make the same argument that it's possible that people don't use PgDown/PgUp either, but that's besides the point, I think.
Generally, interfaces have a lot of features by default and when a particular interface breaks or removes them for no good reason (and I don't think I've ever seen a sticky header that could justify it), well that at least leaves a very bad impression. It's wasteful.
Same goes for links and buttons which are made to work only when clicking with the mouse, when by default they work with the keyboard too. Same goes for text which is set with a fixed width and necessitates a large minimum window width to read properly when by default text adjusts to a window's width. etc.
Nobody is average, so the world would suck if it only worked for the average.
For the record, I do scroll with the spacebar. I like to skim pages as quickly as possible, and PgDown is in different positions in different keyboards, so I just find spacebar to be super-accessible.
I guess you can make the same argument that it's possible that people don't use PgDown/PgUp either, but that's besides the point, I think.
Generally, interfaces have a lot of features by default and when a particular interface breaks or removes them for no good reason (and I don't think I've ever seen a sticky header that could justify it), well that at least leaves a very bad impression. It's wasteful.
Same goes for links and buttons which are made to work only when clicking with the mouse, when by default they work with the keyboard too. Same goes for text which is set with a fixed width and necessitates a large minimum window width to read properly when by default text adjusts to a window's width. etc.
Nobody is average, so the world would suck if it only worked for the average.
For the record, I do scroll with the spacebar. I like to skim pages as quickly as possible, and PgDown is in different positions in different keyboards, so I just find spacebar to be super-accessible.
Also links that can only be activated and not "Open Link in New Tab". Those onclick script links. Every link should have an actually URL in its href.
Well,
> that the majority of users don't use spacebar for scrolling in 2019
I don't use the spacebar for scrolling, too. But I'm pretty sure there are people who do; and those people care.
> I'm not sure it's bad enough to need a bookmarklet to kill it.
Well, it's bad enough for me that medium.com has a too-giant banner that covers over 30% of the viewport...
At the very least, it was bad enough that I submitted this page, even when I usually don't think that web-trends (like npm, 4MB of JS, 'modern' look of applications, etc...) are bad (opposed to the HN crowd).
> that the majority of users don't use spacebar for scrolling in 2019
I don't use the spacebar for scrolling, too. But I'm pretty sure there are people who do; and those people care.
> I'm not sure it's bad enough to need a bookmarklet to kill it.
Well, it's bad enough for me that medium.com has a too-giant banner that covers over 30% of the viewport...
At the very least, it was bad enough that I submitted this page, even when I usually don't think that web-trends (like npm, 4MB of JS, 'modern' look of applications, etc...) are bad (opposed to the HN crowd).
> the majority of users don't use spacebar for scrolling in 2019
Like halal food, or kosher food in New York, it's not about how many people use a browser feature. It's about how much they care.
Like halal food, or kosher food in New York, it's not about how many people use a browser feature. It's about how much they care.
> I'm gonna go out on a limb and say that the majority of users don't use spacebar for scrolling in 2019
If you are designing the web for people of all abilities, then consideration of space bar scrolling is important.
Imagine the frustration of a user that expects certain behavior of the space bar and experiences something else.
If you are designing the web for people of all abilities, then consideration of space bar scrolling is important.
Imagine the frustration of a user that expects certain behavior of the space bar and experiences something else.
It isn't bad enough to need a bookmarklet to kill it. It is worse. It's bad enough to make a greasemonkey script to kill all of them. Sticky headers also muck up the Page Down button quite a bit.
its my favourite way to scroll, because you can predict where the next line will be (if not for those damn stickies)
Instead of a bookmarklet I recommend using a browser extension like greasemonkey or tampermonkey to autorun the script and have the sticky headers unstuck on page load. No manual work of clicking the bookmarklet.
They explain in the article why they don't like that.
The snippet in article removes the element, while I was suggesting to just change the position type to unstick instead of removing completely.
Another benefit of this is that it improves scrolling performance on old hardware. I sometimes browse on a 2010 Mac mini (using Safari) and killing headers can make a big difference.
I was wondering if the sticky advertisement on this page was meant to be ironic; navigating to the other pages proves it was. Neat touch. :)
One of the most annoying parts of AWS Console is that you can 'x' them but there is no 'hide always'.
OK I updated their script to work with AWS Flashbar. :-)
javascript:(function()%7B(function () %7Bvar i%2C elements %3D document.querySelectorAll('body *')%3Bfor (i %3D 0%3B i < elements.length%3B i%2B%2B) %7Bif (getComputedStyle(elements%5Bi%5D).position %3D%3D%3D 'fixed' || elements%5Bi%5D.className %3D%3D%3D 'awsui-flashbar') %7Belements%5Bi%5D.parentNode.removeChild(elements%5Bi%5D)%3B%7D%7D%7D)()%7D)()Great hack to manipulate the DOM with a bookmark!
Lots of fun things are possible, eg I use a feed reader that does not strip inline styles, but occasionally that is annoying so I have
javascript:(function(){
document
.querySelectorAll(
'[style*="font"]'
).forEach(elem =>
elem.removeAttribute(
'style'))
})()I think they're okay for desktops (still prefer without them), but on tablets or smaller viewports, it just takes up too much screen real estate.
They're not OK for desktops as they break page scrolling.
Yet this site has a sticky header...
That's the point - the header is there so you can remove it with the provided bookmarklet.
That's the joke. It's also giving you a target with which to test the bookmarklet on.
Right click
Block element
Block element
That's beautiful. Well done!
Even without that feeling, sticky headers kill the feeling that I'm moving through a viewport of a webpage. It makes your website look like it's not of the "webpage" medium that I've been familiar with for 20 years. Humans have a very good eye for relative movement. The visual processing part of your brain considers movement much more contrasting than color. So a fixed header when you're scrolling at 1cm/second is visually equivalent to a big bar moving upward at 1cm/second while you're trying to read an article. It's hard not to pay attention to it. But navbars don't contain content, so they shouldn't steal attention from the page content.