Kill sticky headers (2013) | Hacker News Reader

Kill sticky headers (2013)

alisdair.mcdiarmid.org

267 pointsokket116 comments

Combine this with the recent surge of sticky footers as well, especially on small/mobile devices. Vice is a particularly bad offender: http://i.imgur.com/ltqYRX9.png

That's a 60px sticky header + a 50px sticky footer on a 480px-tall screen. 23% of my screen space is lost to sticky elements. The footer is only two buttons, "Share" and "Tweet".

Every time you scroll down, the header slides up, and then back down again. It's an incredibly distracting experience.

The icing on the cake is the ad in the middle of the article, it's in an iframe that hijacks your scrolling, until you swipe through all 5 slides you cannot continue scrolling through the article.

Why would I ever subject myself to consuming content this way?!

I just leave those sites immediately. It's too infuriating.

Reader view on iOS Safari makes the web usable on mobile.

For my fellow Android users out there, Firefox also has a reader mode.

For me, it's more like "reading mode on Firefox makes the web usable" on all devices.

https://outline.com if reader mode not available -- works in pretty much any (JS-supporting) browser.

A small set of sites fail to render, including Google's Blogspot, using dynamic themes, which are abominations to the Web. No "fix this site's fucked CSS / styling" tools seem to be able to handle that.

Clever. Thanks for sharing.

Related: looks like direct links to imgur-hosted images now redirect to html content that have... semi-sticky headers and footers.

Maybe only on mobile. When I tell Firefox to load the desktop version, it goes directly to the image. Normally I would say that loading a HTML page plus an image instead of just an image seems like a strange choice for mobile. However, it does seem that the HTML version pulls a resized image. The source URL has a "maxwidth" parameter, so there's probably some bandwidth savings in there.

The site could just as easily serve you the resized image directly instead of an HTML page which will then embed the same resized image. I've already seen Imgur tell the difference between page visits and appearing in src="", so it wouldn't need to break anything.

Only when the request includes a referer. Without one, it just loads the image.

Been using Firefox mobile for a while now with uBlock Origin... Creating rules to hide annoying elements on sites that I use a lot.

Most times when I try to browse pages on a family members phone I want to throw it... Guess I really don't know how bad things are most of the time.

I'm usually just bitching about the sites that are sniffing for webkit UA's and therefore don't show me a mobile experience.

If I'm honest, I usually don't mind the slide up and down header if the navigation is there, means that it is always close by. I do disagree with sticky footers though, especially if it adds no value to me as the user.

My gripe is the disappearing header that reappears at the slightest twitch of reverse scrolling. The behavior needs to work more like drag down to refresh: only reappear with a deliberate and significant scroll "up" (a drag down with the finger) or just stay at the very top where it belongs (it only takes one tap on mobile to get back there).

With most of them if you need to backtrack and read a few lines up, you have to scroll well past the point or the exact text you want to read gets covered by the header.

Or the behavior should, y'know, go away entirely. It's the bane of everyone who uses the top edge of the viewport to help them read.

I agree... I always move the current line to the top of the page for some reason. that's actually why I don't like most ebook readers because they are paginated.

I suspect the pagination is more about saving battery (only need to re-render once per page) vs a smooth scrolling experience.

I don't own a kindle or any e-ink reader though and all the Ebook apps are paginated on my iPad and Mac.

iBooks, at least, offers a scrolling option (same menu where you select font size)

interesting... most of my ebooks that I have opened in iBooks on the iPad are pdfs which don't have that option so I assumed they didn't have the scrolling option but I was able to do it with an actual ebook. It would sure be nice to have continuous scrolling on pdfs as well.

edit: iBooks on mac os doesn't have a continuous option.

Documents by Readdle is a fantastic PDF reader for your iPad. It does have a continuous scroll option as well as pagination.

Or just don't re-appear, and leave scrolling alone. If I want to view a header, I'll scroll to the top of the page.

Are you on iPhone? It's easy to scroll up on iOS (tap the top bar), but hard on Android. That might be one reason why sticky headers are popular.

No, sticky headers are popular because site owners hope for people to browse the site some more.

And people do use them.

My theory is that analytics is to blame for all of this. You can track how many people clicked the button in your share header. You can't reliably track how many people left because of it (there could be a million reasons for leaving the page).

So your analytics shows an uptick in engagement by X%, and no clearly discernable downtick. So the header stays.

All it would need is an A/B test or two, but easier said than done...

a.k.a survivorship bias

Until you are on, say, YouTube, where the home key is hijacked into restarting the video...

The native iOS behaviour is to only do that when flicking (ie. scrolling and letting go). Didn't see anybody copying that yet. However, it makes a huge difference in usability.

anything that hijacks ordinary scrolling behavior is going to ruin the experience for most users. More and more web pages have found some way to break page down -- either by initially stealing focus or by making scroll completely JS-based.

Sticky headers make pgup/pgdn worse by make the visible size of the page smaller than the window size, so you lose a line or two and have to rewind. The ones that reappear when you scroll up are even worse.

Even worse, when you click to an anchor section on a sticky-header page, the title of the section is hidden by the sticky header.

Take me back to the static web.

NYT actually takes the page-down/lines of text problem into account. Odd that others haven't copied.

Now that both position: sticky and Scroll Snap Points from CSS are landing in browsers, those complaints will hopefully be resolved. Scrolling is much better off left in the hands of CSS than JS.

NYT is pretty obnoxious in other ways, though, especially with a touchscreen. If you click and drag to highlight something, it navigates to a different article. If you double-click to select a word, it changes the text size. If you accidentally hit the left or right arrow key while trying to scroll up or down, it again tries to load the next article.

And it's not possible to select text at all on Mobile.

I've taken to using alternative links (archive.is, archive.org, outline.com) for sharing the articles simply because it's too much of a PITA to manage the NYTimes.com page itself.

nytimes.com also hijacks the left/right arrow to advance to the next article, and used to do a thing where if you multi-click to select a paragraph it would jiggle the font size.

Firefox takes full-width fixed headers (and footers?) into account when you scroll with page up/down or space bar.

> Even worse, when you click to an anchor section on a sticky-header page, the title of the section is hidden by the sticky header.

This, especially. If the browser were somehow informed about the header in a semantic way, it could avoid this.

The fix is to shift the anchor to above the header.

Can you elaborate on what you mean by this? Because I can think of a couple of meanings of "above" there, none of which seem like they'd have the desired effect.

It confused me at first too, but now I think I know what he means. Before the header you're linking to - h3 or whatever. Link to some content enough above that header to compensate for the sticky header.

That seems like an awkward semantic break to compensation for presentation, as well as error-prone in size-matching.

Better if the browser knew about the header and could position the linked anchor accordingly. In the absence of any facility to do that, just ditch the header.

It actually is possible to do - you can use CSS to move the position of the anchor tag. If I recall there were some extra CSS properties needed to make it work, but it can be done.

Or, add padding to the top of the H3 to compensate for the sticky header.

yeah, or just

  * {margin:2em}

That would break the most common method of centering the main content (margin-left: auto; margin-right: auto)

Not necessarily. A more specific selector overrides a less specific one, and a later selector overrides an earlier one.

> Take me back to the static web.

I used to enjoy doing Web 1.0 development.

Nowadays I always push for native applications, unless the customer wants otherwise.

Browsers should have stayed pure HTML/CSS.

FWIW sticky headers are completely doable in pure HTML/CSS.

  .header {
    position: fixed;
    top: 0;
    left: 0;
    width: 100%;
    background: goldenrod;
  }

They're popular because clients beg for them. You can show them a thread of people ranting about a particular layout practice, and you can speak passionately against something, but if they want it, they do not relent.

"^top" links, share icons, all that stuff - clients will not give up until they get it all.

(Source: Designed sites for clients since there were first images in web browsers 20+ years ago.)

Speaking of anchors. HN behaves a bit oddly there when going back to a specific comment in a tree with folded branches. Also, the search page hijacks the up key to send me to the top of the page...

Reddit is even worse with their sticky footer that takes up 50% of the screen. It tells you to install their official app (which is by far the worst Reddit app I've found on Android) to continue. However the footer shows a big orange "Continue" button (implies that you continue through the site, the heading above this saying it will install the app is much less visible than the button's text). Below this, in tiny grey text, it says "Or go to the mobile site" (implying it will redirect to the website, which is in fact the opposite of what actually happens). This is blatantly attempting to confuse users and every time I end up on the reddit site in a mobile browser it revives my hatred for reddit: the company.

Is the reddit app even an a real app? It feels like they just packaged their equally awful mobile site. It's really amazing that they can mess things up so badly when there are multiple apps that already do the same thing much better.

It's even worse than that. Alien Blue was by far the best Reddit client I've used. They bought it and for some reason then went on to build the worst Reddit client I've used.

Quite a shame because even though I've found other apps that do a good job, I still miss Alien Blue.

Anyone know why they'd do this?

This is why I append .compact to the desktop URL to browse with their older mobile version. I find it much more usable.

You're my hero

And mine!

>It tells you to install their official app (which is by far the worst Reddit app I've found on Android) to continue.

Reddit's mobile website is also by far the worst website I've ever seen, bar none, for reactivity. Pressing the back button regularly takes 30 seconds to do anything, during which you get no status bar. If you mistake that lack of reaction for it not processing your request and hit back a second time, it'll go back two pages once the 30 seconds are up. Trying to go forward takes another 30 seconds. Opening multiple tabs does not work, they wait until you look at them, and /then/ start loading.

I have come to the conclusion that they have deliberately crippled their own mobile site to try to force people into the app.

AMP is a horrific web standards breaking power grab but if there's one thing that's going to kill it it's that google can't help but put a dang sticky header at the top of every page.

Drives me nuts. That's why there's a back button built in to the browser

Finally I see something posted about this.

If any of you are interested, I have been maintaining a filterlist that works for uBlock origin that attempts to pin (so they won't move when you scroll down) these sticky headers to the top and remove additional screen real estate hijacking web elements.

It may be a losing battle but I update the list almost daily with all new instances of this web plague that I come across. It also works on Firefox Mobile for Android if you have uBlock Origin installed there.

If you'd like to subscribe, enter the following link[1] into your 3rd party filters menu within uBlock Origin - just paste it into the 'Custom' URL entry at the bottom of the '3rd party filters' menu option.

The project homepage is at: https://github.com/yourduskquibbles/webannoyances

Cheers!

[1] https://raw.githubusercontent.com/yourduskquibbles/webannoya...

Thanks so much for working on this!

Thanks for this!! It's unbelievable how OCD I am about this particular detail. It feels like I'm physically constricted as I scroll through a webpage. The other gripe is a webpage taking up 100% of the width of the page. I feel like everything should have at least a small border so I know I'm not missing content outside the width of the page.

> The bookmarklet just finds all fixed-position elements on the page, and removes them.

That will do quite a lot more than remove sticky headers.

True, but remember this is a bookmarklet, not an extension. So you use it on a site that is actively annoying you. If it breaks the site, you can refresh.

I'm not sure what you mean, but I've used Kill Sticky every day for the past year or two and it's worked flawlessly. Any time I have any crap following my viewport around, it gets rid of it.

Yea, but in the context of reading an article it rarely matters.

> Finally, I just don't care right now about navigating your website, or following you on Twitter. I'm trying to read. Let me focus on that for now, please.

Agreed. Those sticky headers almost always wind up on sites like blogs and text articles where they have no place and just reduce usability.

I don't really mind the slim ones on desktop, but they seem to be trendier than ever and particularly annoying on mobile.

What drives me mad on mobile is the headers that expand/collapse depending on whether you're scrolling up or down, except without any hysteresis which makes them randomly activate as I scroll down. This, combined with the additional lag caused by JavaScript, occasionally makes me ragequit from reading an article. I don't know whether this is just my device (mid-end Xiaomi) or a complete lack of usability testing.

A lot of stuff works amazingly well when you're on the same wifi network as the development server and use a top of the line iPhone 7. I assume most "usability testing" from such websites are done like that.

Until some bozo forgot that not everything is 16:9, and the "slim" header linebreaks into a double height version...

Great minds think alike - I also have an 11' macbook and got annoyed enough to make a chrome extension https://chrome.google.com/webstore/detail/zapfixed/jgiflpbko...

I think his one may be better. Mine toggles using jquery.

You can use this userscript [1] to hide most floating headers when you scroll down the page. (When you scroll up, the header is displayed again, so the site doesn't become unusable.)

[1] https://iwalton.com/wiki/#NoFixed

Sticky headers bother me especially when trying to read news sites on a laptop. Similar bookmarklets I have found helpful are "static ding" and "static nuke" (staticding.org). Static Ding just changes "fixed" DOM elements to "relative". They remain in the DOM and visible but they can scroll off screen. I use that to read (for example) New York Times op eds because a NY Times' link to view comments is on the sticky header itself. If I don't need continued access to a sticky header, I use Static Nuke, which sets "fixed" DOM elements to "display: none", similar to the posted bookmarklet which removes them from the DOM.

Why not set the position to absolute instead of completely removing the element. The solution to losing the navigation is reloading the page, seems unnecessary.

Oh cool, the bookmarklet also works on medium.com to remote the utterly annoying bottom bar. Bookmarked and will be used.

With a 15" laptop screen the medium.com "Never miss a story from ..., when you sign up for Medium."-bar takes up like 10% of vertical space.

I'd love to have such a feature, but this doesn't work for me. On Chrome, it's in my bookmark bar but it has no effect. On Firefox, it doesn't allow dragging to the bookmark sidebar. (I actually don't see how it could possibly work - how could something sitting in the bookmark bar have such an effect? But I'm happy to grant the possibility there are things I don't know about how browsers work.)

What am I missing?

You have to click it to make it do anything. It's a bookmarklet.

Here's the introduction:

https://support.mozilla.org/en-US/kb/bookmarklets-perform-co...

When you properly install it, instead of the link, there should be an executable code in the bookmark (if it starts with http: or something, it isn't). To activate the code, first you visit the page on which you want the code to work, then you click at the bookmarklet.

Ah! That works, thanks!

Reminds me of a bookmark I made for work to override a JavaScript function that clears a form. So test input on our live site will stay in a form and we can stop typing it in over and over. the nice thing about the web is being able to manipulate the front.

Heh, walking the dom to evict these kind of elements is a pleasure of mine.

I have too bookmarklets very similar. Makes for a nice tree recursion thinking exercise at first.

ps: yes sticky is subtle and nowadays it's often wasting space.

The problem is that they convert, so they are going to keep being used.

Citation? I ask this because data at my company has shown that virtually nobody taps on the header, especially on hamburger menus.

Guess my citation is also anecdotal, we have a series of extremely high converting sites in the rehab market that drive calls from the sticky header.

Is there a way for bookmarklets such as this to work in a mobile browser?

I find that they don't, because I don't have a bookmarks bar I can add the bookmarklet to.

It does, however, work within the demo page itself.

In iOS it would require a Safari action extension that lets you load arbitrary JS. In Android I’m sure there’s a bunch of apps that do something along those lines.

Edit (no affiliation): Safari Snippets by ydangle https://appsto.re/us/biIhdb.i

So simple, yet so useful! How have I not found this before? It even kills the annoying "Log In/Sign Up" pop-up dialog on facebook pages!

I must say I dislike just as much the very similar trend with mobile apps to save a few lines of screen space, particularly with mobile web browsers.

In Firefox you you can go to about:config and set layout.css.sticky.enabled to "false", which is helpful.

And one day someone will invent sticky body. Oh, wait, it is called flash :)

1Blocker recently added a 'tap to remove elements' feature.

> I use an 11" MacBook Air, which means that I don't have much vertical screen space.

Maybe that's the problem? I use 27+ inches monitors at home and office, and never had any issues with sticky headers.

Leave them alone! :)

Your answer to a problem no one should be forced to deal with is to spend more money on a bigger monitor?

Not only does that not address the issue in the slightest, but that's very much like saying if you don't like the banner ads run across the bottoms of t.v. shows you should buy a bigger t.v. so it feels smaller.

Sticky headers ave their place, but they should be minimal and supply links to other locations on the site. They should never be used for advertising.

But… I like them. It makes navigating easier. I’m talking about just the nav bar though—like the one here on HN.

Right. But the nav bar on HN isn't sticky.

Is this being reposted as satire? Mcdiarmid.org has a sticky header on mobile in 2017...

Afaik, only this one article uses a sticky header - and only then it seems to be to show off the bookmarklet

That one is probably there for illustrative purposes.

I think it's so you can test the bookmarklet

getComputedStyle = undefined

Don't visit websites you don't like. That's the only way.

I passionately hate my uni's automation website, it's a great example of haphazard overkill, but I need to choose my lessons each semester. What should I do, switch schools?

Honestly, this is an issue with having absolutely terrible browsers. This sort of thing should be easy to do without having to know javascript. The user just has so little power with the user interface they're given for interacting with the internet. Obviously, this will change over time, but the transition period is very frustrating.

A trouble is it's a moving target. As soon as you sort one annoyance they'll invent a new one. That said Chrome could really do with a simple do not autoplay video setting.

> do not autoplay video setting.

Not to mention sound.

At least they added the feature to mute a tab. No more hunting for that one ad that's making sounds.

I'm sympathetic, but forcing style calculation for every element on the page may not be the most performant solution.

It doesn't need to be. It's a bookmarklet.

You click it when there's a sticky header. If it takes 200ms to run, that's not a problem.

If it were a browser extension running on every page, sure, that's a disaster.

A lot of blanket statements in here, but there are sites out there that have tested them and found sticky headers useful in some way. We're not the only demographic.

I personally don't like them either, but I also know how to scroll. I've seen instances on long pages where there are audiences who have a hard time navigating through a lot of content without a constant point of reference.

Nobody mentioned the yellow sticky header on the "kill sticky headers" page...?

It's to help you test out the script on the page

Well this blog post is _really_ shortsighted for a couple reasons:

1. There's position: sticky; recently added to CSS: https://drafts.csswg.org/css-position/#sticky-pos

2. Position: sticky; is gaining browser support fast: http://caniuse.com/#feat=css-sticky

So what I draw from that are the following insights:

3. The author of the bookmarklet should update the code to also check for elements now using position: sticky;

4. Sticky elements haven't peaked on the web, the deluge is _about_ to begin actually. Brace yourselves…

(3) That doesn't make the blog post "shortsighted", just missing a new trick, that's not much used yet anyway.

(4) The websites that wanted to have a sticky header would have done it already with one of the several available current methods. The appearance of an easier way to do it with a single CSS rule is not gonna increase their number drastically.

This article was written in 2013, almost 3 years before any browser supported "position: sticky". I disagree that the blog is shortsighted, but as you mentioned, the bookmarklet should be updated.

The blog post was written in 2013.

Does this little update to the bookmarklet solve the issue? I'm not a webdev, feel free to fix it.

(function () { var i, elements = document.querySelectorAll('body *');

  for (i = 0; i < elements.length; i++) {
    if (getComputedStyle(elements[i]).position === 'fixed') {
      elements[i].parentNode.removeChild(elements[i]);
    }
    // 2017 update:
    if (getComputedStyle(elements[i]).position === 'sticky') {
      elements[i].parentNode.removeChild(elements[i]);
    }
  }

})();

Almost. This modification would cover it:

    ...
    for (i = 0; i < elements.length; i++) {
       if (getComputedStyle(elements[i]).position === 'fixed' ||
           getComputedStyle(elements[i]).position === 'sticky') {
         elements[i].parentNode.removeChild(elements[i]);
       }
    } ...

There are probably more clever ways to go, but this will do the trick. BTW haven't found many sites using "sticky", but good to be ready just in case.

Reply on news.ycombinator.com