181 points | by clockworksoul20 小时前
It seems there isn't a way to browse existing bookmarklets, other than the small, curated lists?
* https://river.me/blog/bookmarklet-stay-here/
- https://bookmarkl.ink/ashtonmeuser/a36be4b6c835276f1a22a8c49...
- https://bookmarkl.ink/ashtonmeuser/a36be4b6c835276f1a22a8c49...
- 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.
thanks!!
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.
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
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.
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
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.)
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/
Here's a minified version with "sticky" added:
javascript:(()=>[...document.querySelectorAll('body *')].map(el=>["fixed","sticky"].includes(getComputedStyle(el).position)&&el.remove()))();
javascript:document.querySelectorAll('body *').forEach(el=>["fixed","sticky"].includes(getComputedStyle(el).position)&&el.remove())Any idea?
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.
I make it a Shortcut out of it: https://www.icloud.com/shortcuts/8aa788a3acc747169a6d80191a0...
That’s hilarious (and sad). It seems to be still in business, since 2012.
Just for mobile, where it is very annoying on long pages (Laravel Docs for example) to scroll up just to get the menue button.
I asked Copilot and searched Google but couldn't really come up with anything.
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.)
Let me guess, in Google's mind, the more ad coverage the better even if sacrificing content?
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)()I've been using the Kill Sticky bookmarklet for that:
Bonus points if the header is absolutely massive and takes up a full fifth of the innerHeight.
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".
`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.)
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.)
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.
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.
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.
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.