A bookmarklet to kill sticky headers (2013) | Hacker News Reader

A bookmarklet to kill sticky headers (2013)

alisdair.mcdiarmid.org

219 pointsclockworksoul88 comments

Bookmarklet aficionado and maintainer of bookmarkl.ink here. Took the liberty of posting this bookmarklet: https://bookmarkl.ink/ashtonmeuser/849a972686e1505093c6d4fc5...

Nice, this is very cool, thanks for the work & for sharing :)

Wow, the Doom bookmarklet is kind of cool. https://bookmarkl.ink/ashtonmeuser/04710d3befc446e849108a587...

It seems there isn't a way to browse existing bookmarklets, other than the small, curated lists?

I'm not seeing any way to browse them either. I'd love such a feature.

Thanks! Re: listing bookmarklets, that's something I'd like to do but have yet to find a cheap/easy way to do it. One way would be to search gists for relevant metadata [1] but GitHub does not include searching gists in their API. Another way might be logging paths in an edge function. Open to suggestions/PRs.

[1] https://gist.github.com/search?q=bookmarklet-title

I have a couple bookmarklets scattered in a couple blog posts that you may find interesting / want to add:

* https://river.me/blog/bookmarklet-stay-here/

* https://river.me/blog/firefox-keep-bookmark-keywords/

* https://river.me/blog/url-bar-is-a-cli/

Your wish is my command.

- https://bookmarkl.ink/ashtonmeuser/a36be4b6c835276f1a22a8c49...

Interestingly, in the URL CLI article, you mentioned the difficulty of maintaining such bookmarklets. That was a huge motivator for bookmarkl.ink. You can keep your verbose, commented code in a gist while the actual bookmarklet is tree shaken, stripped of comments, minified, and encoded. As of late, you even get some creature comforts like TypeScript support. Finally, every gist is a repo behind the scenes so you get version control for free.

ohhh I thought it was primarily a repository for people to browse each other's bookmarklets, I am going to check it out if it would let me do my management in a more sane manner! I am still using the system in that blog post with regex and deletion+reimporting when I need to update several at a time (which is not that uncommon) and I still hate it haha

thanks!!

Aficionados will appreciate Jesse Ruderman's bookmarklets at https://www.squarefree.com/bookmarklets/ which have been saving my sanity since the early 2000s.

I love this project! I used to use a lot of bookmarklets, but lost a lot of them and couldn't find all I used to use. Is it possible for you to create a directory or listing for all the hosted bookmarklets, but that might need curation too.

I've been using the Kill-Sticky Chrome extension for years:

https://chromewebstore.google.com/detail/kill-sticky/lekjlgf...

Because it has a configurable keyboard shortcut.

Can't imagine browsing the web without it. At this point hitting Cmd+K when I visit an article is pure reflex.

A bookmarklet would be more secure, but I don't know of a way to assign keyboard shortcuts to one.

You can add a Chrome site shortcut whose URL is a bookmarklet, so it will run the bookmarklet when you type "bm" in the address bar (for example).

Taking it even further so it will run with just one keystroke, on my Mac I used Karabiner to run a terminal script that types the bookmarklet in the address bar for me:

    tell application "System Events"
        keystroke "l" using {command down} -- Select the address bar (Cmd+L)
        keystroke "bm" -- Type "bm"
        delay 0.2  # Let Chrome recognize the site shortcut
        keystroke return -- Press Enter
    end tell

In my script I open a new Chrome window before this because the bookmarklet submits a nag screen from my job, but for stickies you could have it just switch back to the window you're reading instead.

this is awesome. thanks

Chrome bookmarks also show up as items in the Bookmarks menu, which means you can use the built-in macOS functionality to assign your own custom keyboard shortcuts in System Preferences → Keyboard.

> more secure

interesting. that extension's Support section has a link to https://github.com/eemeli/chrome-kill-sticky whose license is MIT, so you could make your own extension. That repo also has a newer version of the code, and that was deployed on the Firefox store, but not on the Chrome store.

Anecdote: I was in charge of a complete rebuild for an e-commerce website a few years back, which included a new design. We were debating various layout options, as it was tricky to get the information hierarchy right and show everything necessary even on smaller screens. Then we had an internal review and the CEO complicated things considerably by insisting it was very important that the header be sticky --- to ensure that the company logo would always remain visible even when scrolling, reminding users of our brand.

CEOs need to be stopped or at least be told to shut the fuck up.

Is it possible to distract the kid in power with a favicon that is always visible in the url bar and allow users not curse the brand due to stickiness?

Most users are on mobile nowadays and don't see the favicon until they want to switch tabs.

It continues to amaze me how many companies believe that customer care about their brand. The brands people care the most about are yet those they actively attempt to avoid, or those who doesn't need to constantly remind people of their existence.

Brands matter a lot, but a CEO who believes the logo should always be visible on the website in pursuit of brand strength doesn't actually understand the first thing about brands.

The whole entire internet is broken.

Specifically what I mean is HTML is flawed. It should never have been a presentation format. It should've always been a DATA format, like JSON, or XML, from day one. The browser itself would then be able to display information (pages) in whatever style, colors, and format it wants.

Probably 99.999% of developers agree with this, but we're stuck in a RUT it seems. I know what I'm sort of talking about is the "Semantic Web", and I'm probably preaching to the choir to bring it up on Hacker News.

But I'm wondering if it's possible to change? What would it take? We'd need some major movement, almost like Web3, or Blockchains, that got everyone to wake up and realize there's an easier way. We're stuck because there's no real incentive for change. It's a chicken and egg problem. No one is gonna be first to design something, unless everyone else is already using it. :( Thanks for listening. That was step one I guess.

Almost nobody wants that though.

Content providers want control over presentation.

Users want pretty sites.

None of this is unique to the web. It's the same reason every magazine has its own attractive layout and formatting, instead of just being a long manuscript in Courier.

I like the fact that different sites have different typography. It's an identity that tells me where I am.

I understand the appeal of "pure information" without any visual variation ever, but I think that for most people, variety is the spice of life, no?

I wouldn't want every site to look the same, for the same reason I wouldn't want everyone to dress like clones. Visual self-expression is part of what it is to be alive.

> I like the fact that different sites have different typography. It's an identity that tells me where I am.

While I do get that and to some extend agree, what we get is light grey on white, skinny fonts and illegible pages. It's one of those things that are awesome when they work, but it's so hard to get right and very few people/teams are able to do it.

That's a good point.

Professionally produced content is generally fine, as long as you've got an adblocker.

The design decisions some personal blogs make can occasionally be horrific though.

Still, I'd rather let people express themselves and make mistakes and learn from the experience, I think.

DrudgeReport is boring as hell looking and was successful for years. Even HackerNews is about as boring as it gets, and we use it because it works. I think the world is ready to move on from the whole entire internet being a massive "MySpace Page" of garbage.

I think part of the data format could be visual related tho. Enough to make sites able to look distinctive, but not enough to allow the chaos we have today. For example, background image for a page, font for a page, whether something should be in a left panel, center panel, or right panel. They would be hints and very limited, and all in one place, in the data format. Unlike HTML where you have anything, anywhere, and total chaos.

I think you underestimate the value the world would place on the gains we could get from this kind of design, not to mention that AI would be able to reason about the pages much better. Just the AI angle along is enough to convince society to go along with the change.

But there will need to be some "Killer App" that does this, which everyone else copies.

It's already been solved and it's called reader view.

I'm using the Bar Breaker Firefox Extension[1], it's particularly helpful on Android devices with smaller screens.

It completely gets rid of the bars, which is sometimes great, but sometimes too much. I occasionally have to turn it off for workflows where the "next" button is in a fixed bar, such as checkout for US Mobile, or saving a Yoto playlist.

[1]: https://addons.mozilla.org/en-US/firefox/addon/bar-breaker/

> There's even a sticky header web startup.

That’s hilarious (and sad). It seems to be still in business, since 2012.

Surprisingly that site has no sticky header. It did trigger a Google login attempt and ask for notification permissions plus had a couple of sticky buttons at the bottom.

It does have one. It takes a few seconds to appear though.

uBlock Origin blocked the website. Gee, I wonder why

Love it! Since it's now 2025, we probably should search for "fixed" & "sticky"

Here's a minified version with "sticky" added:

javascript:(()=>[...document.querySelectorAll('body *')].map(el=>["fixed","sticky"].includes(getComputedStyle(el).position)&&el.remove()))();

Interestingly running this in the console works but from a bookmarklet changes all the page content to false,false,false,.... (on firefox)

Any idea?

Change map to forEach?

document.querySelectorAll('body *').forEach(e=>{if (["fixed","sticky"].includes(getComputedStyle(e).position)) e.remove()});

Firefox expects your script to return undefined, so you can add one at the end (or even shorter: void 0).

Thank you (and neighbors), I didn't know this.

To clarify slightly, bookmarklet behavior across browsers is to call `document.write` with the result of the bookmarklet’s last expression unless that result is `undefined`, and calling `document.write` after page load completes replaces the page’s DOM with the content written. It’s a weird bookmarklet thing, I don’t think there’s anywhere else in JS that accepts a list of statements, not expressions, but cares about the result of the last expression.

People often disable this by making the last expression `void 0`, which evaluates to `undefined`. This is really an anachronism, though, the original point wasn’t actually brevity (it’s only one character shorter after URL encoding, not worth funky syntax) but that just writing `undefined` was broken and sometimes didn’t evaluate to the special value undefined. That’s fixed now, so I would just append `undefined` instead.

Though, really what you should do is always wrap bookmarklets in IIFEs, which avoids stomping around the page’s global variables, lets you write code with early exits, lets you opt back in with an explicit return rather than editing boilerplate, and also solves this issue as a bonus.

even more minified. forEach doesn't return anything, so you don't need the IIFE.

  javascript:document.querySelectorAll('body *').forEach(el=>['fixed','sticky'].includes(getComputedStyle(el).position)&&el.remove())

  javascript:document.querySelectorAll('body *').forEach(el=>/^(fixed|sticky)$/.test(getComputedStyle(el).position)&&el.remove())

Dont hate me, but I would like to have the opposite functionality

Just for mobile, where it is very annoying on long pages (Laravel Docs for example) to scroll up just to get the menue button.

If you’re on ios, you can tap the clock for fast scroll up.

Same here, and I want the sticky Safari bottom tool bar back! Why is that not configurable?

Here you go: javascript:(function(){window.scrollTo({top:0,behavior:'smooth'});})();

These things are so annoying. Is there a website benchmark not for speed, not for security but for "annoyingness"? I guess there is some overlap with accessibility, but that's not exactly what I'm thinking of.

I asked Copilot and searched Google but couldn't really come up with anything.

It is the inverse of what engagement is supposed to be measuring, but it turns out that optimizing for engagement takes you down a darker path...

When I see a site that's clearly over enthusiastic about this stuff, I just close the tab. So their focus on keeping engagement with shenanigans actually shortens the engagement ending in a lost potential.

That depends on what's being measured, most especially by way of survivor bias.

If the only people whose time-on-site is measured are those who 1) don't blacklist the site, 2) don't disable JS, and 3) don't immediately leave and never return, then annoyances may well give apparent measurement of longer time-on-site as the remaining readership is curated to those who will tolerate (or have no alternative to) such bullshit.

Web metrics are very poorly understood even now. YouTube's infamous experiment where latency improvements degraded apparent site performance ... because people with exceedingly marginal connections could now actually use the site if even very poorly.

(I can't find that story though it's from ~10--15 years ago. Both my DDG-fu and FastGPT-fu (Kagi) are failing me. I'm pretty sure HN has discussed this at least once.)

My policy is "if it doesn't improve upon Reader Mode, don't add it".

CLS was roughly designed to measure annoyingness in terms of "moving layout elements". I'm sure Google has even more nuanced signals to measure e.g. ad coverage vs content coverage

> I'm sure Google has even more nuanced signals to measure e.g. ad coverage vs content coverage

Let me guess, in Google's mind, the more ad coverage the better even if sacrificing content?

In my text browser I came up with a way to implement these that doesn't move boxes around the page.[0] In short: treat "position: fixed" as an absolute child of the root box, and ignore "position: sticky" (mostly).

This doesn't completely eliminate sticky headers/footers (problematic when you actually want to use them), but they behave like normal elements at the start/end of the page (instead of the screen).

I initially did it this way for technical reasons, but now I kind of prefer it to what mainstream browsers do.

[0]: https://git.sr.ht/~bptato/chawan/tree/e56399f92d2323f9af95e0... (not a great explanation - it says "bottom", but like "position: absolute" it's placed at the top if only "top" is specified, etc.)

I have a (badly made) variant of kill sticky that I use on my phone. It kills sticky, then messes with any code blocks it finds to make them full width and use a smaller font.

It drives me mad when I'm reading articles with embedded code blocks where the code has less room than the prose and sometimes a bigger font!

It works well on eg this page (https://www.programiz.com/swift-programming/inheritance), but maybe someone that knows what they're doing can make it work on GitHub. It'd be nice to not see those line numbers taking up half the width.

I'm on my phone so I've only the bookmarklet to hand:

   javascript:(function()%7Bvar%20i%3Bvar%20b%3Ddocument.querySelectorAll(%22body%20*%22)%3Bfor(i%3D0%3Bi%3Cb.length%3Bi%2B%2B)%7Bvar%20el%3Db%5Bi%5D%3Bif(getComputedStyle(el).position.match(%2Ffixed%7Csticky%2Fgi))%7Bel.parentNode.removeChild(el)%3B%7D%7Dconst%20c%3Ddocument.querySelectorAll(%22html%22)%3Bfor(i%3D0%3Bi%3Cc.length%3Bi%2B%2B)%7Bif(%22hidden%22%3D%3D%3DgetComputedStyle(c%5Bi%5D).overflow)%7Bc%5Bi%5D.style.setProperty('overflow'%2C%22scroll%22%2C%22important%22)%3B%7D%7D%7D)()%3B(function()%7Bvar%20i%2Cj%2Cb%3Ddocument.querySelectorAll(%22pre%22)%3Bfunction%20setPropertiesOuter(el)%7Bel.style.setProperty('margin-left'%2C%22calc(-50vw%20%2B%2050%25)%22%2C%22important%22)%3Bel.style.setProperty('margin-right'%2C%22calc(-50vw%20%2B%2050%25)%22%2C%22important%22)%3Bel.style.setProperty('font-size'%2C%2211px%22%2C%22important%22)%3Bel.style.setProperty('text-indent'%2C%220%22%2C%22important%22)%3Bel.style.setProperty('border-left-width'%2C%220%22%2C%22important%22)%3Bel.style.setProperty('border-right-width'%2C%220%22%2C%22important%22)%3Bel.style.setProperty('border-radius'%2C%220%22%2C%22important%22)%3Bel.style.setProperty('padding'%2C%2210px%22%2C%22important%22)%3Bel.style.setProperty('width'%2C%22100vw%22%2C%22important%22)%3Bel.style.setProperty('max-width'%2C%22100vw%22%2C%22important%22)%3B%7Dfunction%20setPropertiesInner(el)%7Bel.style.setProperty('font-size'%2C%2211px%22%2C%22important%22)%3Bel.style.setProperty('text-indent'%2C%220%22%2C%22important%22)%7Dfor(i%3D0%3Bi%3Cb.length%3Bi%2B%2B)%7Bconst%20el%3Db%5Bi%5D%3BsetPropertiesOuter(el)%3Bvar%20descendants%3Del.querySelectorAll(%22*%22)%3Bfor(j%3D0%3Bj%3Cdescendants.length%3Bj%2B%2B)%7BsetPropertiesInner(descendants%5Bj%5D)%7D%7D%7D)()

The only sticky headers I like are the ones that disappear while scrolling to the bottom of the page but reappear when scrolling back up. Preferably while scrolling up the user is only seeing the navigation and logo. Otherwise, they're super annoying.

Unless you're reading at the top of the screen (i.e. on a phone), scroll up to recap on something you missed, and then the header slides in and covers the exact thing you were trying to read.

Bonus points if the header is absolutely massive and takes up a full fifth of the innerHeight.

These are just as bad, at least their default implementation that triggers on tiny up movements as it covers content you tried to re-read or just annoyingly pops up on inadvertent finger movements

Is there a way to get this working on Firefox Android?

The bluesky sticky header is annoying, and I haven't seen a way to just switch it off.

EDIT: solved: drag kill sticky to bookmarks on desktop browser, then access bookmark from sync'd Firefox on Android.

There's another way! Instructions: https://paul.kinlan.me/use-bookmarklets-on-chrome-on-android... Summary:

  1. bookmark any page
  2. change the url to your code
  3. give it a title like !script
  4. to activate, tap the address bar and type !script

Works on Android Chrome and Firefox, and probably other browsers too. More people ought to know about mobile bookmarklets.

If someone has one for the "share this" popups when you select some text in way too many articles/blogs I'd love to add this to my collection...

He can't hate them that much he put one on his website.

It makes for a good test

I think that’s kind of the point. He puts a button just down from the top that kills it.

That's called irony.

I saw this as a feature. I was able to click the button and make it go away, to see it work.

A "kill-fixed" bookmarklet that kills anything with position "fixed" or "sticky" is essential to making websites usable. The "best" is Substack, where I load the page with JavaScript disabled, then enable it to kill the red fixed-position bar telling me that JavaScript is essential.

Perfect little tool I’ve been using but I completely forgot.

I make it a Shortcut out of it: https://www.icloud.com/shortcuts/8aa788a3acc747169a6d80191a0...

Nowadays even more vital than 12 years ago. Things have not gotten better in the meantime.

I've been using the Kill Sticky bookmarklet for that:

https://github.com/t-mart/kill-sticky.git

So it works by removing elements with "position: fixed".

But do all sticky headers work like that? In sites that I build, I tend to just have a normal div at the top, followed by a div for the main body with "overflow-y: scroll".

Please don't implement things like that: among one or two other related problems, it breaks keyboard navigability, because the document then isn't scrollable. So users have to focus your div by clicking or tabbing to it before things like Space to go down one pageful will work.

`position: sticky` or `fixed` are the only acceptable techniques to implement sticky headers for typical websites. (There are definitely app scenarios where you need multiple scroll areas and don't want any of them to use the document scroll area, e.g. a multi-pane email client; in such cases you should then manage focus just a little so one pane gets focus when everything loses it.)

As a web developer, I'm well aware that pretty much every single thing I do has a better way of doing it. That's the world we live in.

This might not be what you intended, but the impression I’m getting is that you’re dismissing my objections by saying “the world isn’t perfect so I won’t even try”. That’s a cop-out. Probably most of the thing you do don’t have an unqualifiedly better way of doing it.

This is a case where the solution you’re coming up with, which has never been the normal solution on the web but people definitely try it from time to time (perhaps because it is how you’d implement such a thing in almost every non-web GUI toolkit), causes certain very specific problems which render it unsuitable for general web content, particularly making life harder for quite a lot of desktop users (where Space/Shift+Space for scrolling is very common).

This is not a case of “well akshully” correctness, where the difference is immaterial. It’s a specific, concrete thing where it’s good to learn the behaviour of the platform, so that you work with it rather than against it, and not cause unnecessary difficulties to normal users.

>but the impression I’m getting is that you’re dismissing my objections by saying “the world isn’t perfect so I won’t even try”. That’s a cop-out. Probably most of the thing you do don’t have an unqualifiedly better way of doing it.

It would be truer to express my position as "my capacity for improving my practices is limited, and there are much higher priority areas than this one".

>causes certain very specific problems which render it unsuitable for general web content, particularly making life harder for quite a lot of desktop users (where Space/Shift+Space for scrolling is very common).

I'm skeptical that "a lot of desktop users" use keyboard for navigation. I'm a pretty keyboardy person, and I don't even know what this "shift+space" pattern is that you refer to. I don't think I've ever seen a person navigate a scrolling area with anything other than a mouse or touchpad.

>This is not a case of “well akshully” correctness, where the difference is immaterial. It’s a specific, concrete thing where it’s good to learn the behaviour of the platform, so that you work with it rather than against it, and not cause unnecessary difficulties to normal users.

I'm not very convinced that "normal users" are affected either way, but I appreciate your point and good-faith effort, nonetheless.

To be honest, when I think about it, I rarely implement sites that have a scrolling main body, so it doesn't come up much.

This article is about removing all fixed elements on a page. Not only do other elements catch strays, fixed isn't the industry standard way of making sticky headers in 2025!

Fixed isn't the industry standard way of making sticky headers in 2025

What is? Flexbox? Or something else?

(Not a FE dev, though I'm vaguely conversant in CSS, mostly by using it to fix site annoyances on my own via stylesheet management extensions such as Stylus.)

There's `position: sticky` now for headers. It has better ergonomics than fixed and it's nice than it's supported by all modern browsers.

https://developer.mozilla.org/en-US/docs/Web/CSS/position

Thanks!

It's a huge improvement for sticky sidebars that are only scroll within their parent element. For example, it's what I use on this page: https://allaboutberlin.com/guides/public-transit

I still use this daily.

the website has a massive, undismissing sticky header on top on mobile with js disabled. it's also the useless kind. rather ironic.

Presumably so you can test it on-page

Kill Sticky is brilliant. Been using for years.

If only sticky headers didn’t convert so well!

Convert to what? Not to actual sales for sure. But maybe converting well to annoying and confusing the potential customer, which seems to be much more important than making sales.

Click-throughs, signups, etc. and eventual sales.

2025 and it still works, even on mobile

(2013) but I will give it a try.

Since then we've gotten: position: sticky — which is like fixed but only "fixes" itself once its Y offset is satisfied. Updating the bookmarklet to also check for that, in addition to position: fixed would help modernize it a bit.

Reply on news.ycombinator.com