Live data from Hacker News

A bookmarklet to kill sticky headers (2013)

alisdair.mcdiarmid.org

61–70 of 91 posts

Re: A bookmarklet to kill sticky headers (2013)

#61

Earlier quoted context omitted.

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()});

Re: A bookmarklet to kill sticky headers (2013)

#62

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?

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

Re: A bookmarklet to kill sticky headers (2013)

#63
post #21

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.)

Re: A bookmarklet to kill sticky headers (2013)

#64
post #42
post #26

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 ensu…

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.

Re: A bookmarklet to kill sticky headers (2013)

#65

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.

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.

Re: A bookmarklet to kill sticky headers (2013)

#67
post #62

Earlier quoted context omitted.

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

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.

Re: A bookmarklet to kill sticky headers (2013)

#68
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.)

Re: A bookmarklet to kill sticky headers (2013)

#69

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

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

Re: A bookmarklet to kill sticky headers (2013)

#70
post #62

Earlier quoted context omitted.

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.

Post reply on HN