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.
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.
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.
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.
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?
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.
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.
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'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.
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.
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.
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
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.
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:
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.
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
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.
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.
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.)
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.)
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.
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.
ashtonmeuser|1 year ago
stevage|1 year ago
It seems there isn't a way to browse existing bookmarklets, other than the small, curated lists?
RheingoldRiver|1 year ago
* https://river.me/blog/bookmarklet-stay-here/
* https://river.me/blog/firefox-keep-bookmark-keywords/
* https://river.me/blog/url-bar-is-a-cli/
m0d0nne11|1 year ago
vidyesh|1 year ago
quickslowdown|1 year ago
crazygringo|1 year ago
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.
Noumenon72|1 year ago
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:
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.aeromusek|1 year ago
gabrielsroka|1 year ago
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.
bschne|1 year ago
eviks|1 year ago
stalfosknight|1 year ago
mrweasel|1 year ago
quantadev|1 year ago
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.
crazygringo|1 year ago
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.
carlosjobim|1 year ago
nfriedly|1 year ago
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/
layer8|1 year ago
That’s hilarious (and sad). It seems to be still in business, since 2012.
nejsjsjsbsb|1 year ago
burgerrito|1 year ago
DaveSwift|1 year ago
Here's a minified version with "sticky" added:
javascript:(()=>[...document.querySelectorAll('body *')].map(el=>["fixed","sticky"].includes(getComputedStyle(el).position)&&el.remove()))();
gabrielsroka|1 year ago
evgpbfhnr|1 year ago
Any idea?
lasarkolja|1 year ago
Just for mobile, where it is very annoying on long pages (Laravel Docs for example) to scroll up just to get the menue button.
skydhash|1 year ago
lucasluitjes|1 year ago
miramba|1 year ago
chrsw|1 year ago
I asked Copilot and searched Google but couldn't really come up with anything.
kevindamm|1 year ago
nightpool|1 year ago
shiomiru|1 year ago
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.)
fatboy|1 year ago
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:
lemonberry|1 year ago
eviks|1 year ago
mlekoszek|1 year ago
Bonus points if the header is absolutely massive and takes up a full fifth of the innerHeight.
bloopernova|1 year ago
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.
wonger_|1 year ago
evgpbfhnr|1 year ago
codingrightnow|1 year ago
urbandw311er|1 year ago
al_borland|1 year ago
unknown|1 year ago
[deleted]
Forge36|1 year ago
nejsjsjsbsb|1 year ago
username223|1 year ago
ggasp|1 year ago
I make it a Shortcut out of it: https://www.icloud.com/shortcuts/8aa788a3acc747169a6d80191a0...
tempodox|1 year ago
I've been using the Kill Sticky bookmarklet for that:
https://github.com/t-mart/kill-sticky.git
stevage|1 year ago
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".
chrismorgan|1 year ago
`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.)
SeanAnderson|1 year ago
dredmorbius|1 year ago
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.)
mrzool|1 year ago
perching_aix|1 year ago
err4nt|1 year ago
zoom6628|1 year ago
bradgessler|1 year ago
carlosjobim|1 year ago
zapkyeskrill|1 year ago
fn-mote|1 year ago
cuttysnark|1 year ago
unknown|1 year ago
[deleted]