This is my most useful bookmark, I use it everywhere (it's even practical on an iphone)
So many sites have a top banner that disappears as you scroll down a page, but as soon as you scroll upwards even a little bit, it pops up again. This is immensely frustrating because I tend to read at the top of a page and scroll down as I'm reading. So if I scroll down slightly too far and then correct myself, the banner will instantly obscure the bit of the text I'm trying to read. It's very satisfying to be able to click on the bookmark and fix the site's crap design!
One of the banes of my existence! There's no place for these stupid effing banners when browsers have inertia scrolling and infinite-scrolling sites have fixed headers (or footers) visible all the time. Maybe I wouldn't be so frustrated if the tolerance for what makes a header reappear wasn't ~3px, which is what I often perceive it to be. It totally misunderstands human behavior, which isn't to read an article word by word all the way through like a robot but to reread things to better comprehend them and jump around an article to make sense of connected ideas.
Just disable javascript in ublock origin for the site and you don't have to even worry about clicking anything. Lots of news sites deliver the content and then try to block access to it using javascript.
You don't need uBo to block JavaScript, you can do that right in the browser.
But often blocking JS means parts of the article don't display or the site breaks in other ways. Washington Post for example only shows blurry placeholder photos with JS off.
The kill-sticky or the element zapper in uBo can sometimes do what blocking JS cannot.
Yes, yes, yes! I am so sick of sites putting fixed top bar, and fixed side bars as well. Add "clever" bar animation in as well, and you get the awful UX we have today. Classic case of people inventing a problem to solve.
It's not just the awful UX of today. It's the awful UX of yesteryear, except this time it's the website owner's fault. https://i.stack.imgur.com/pOAAU.jpg
yes I mean on desktop. Original comment was something along the lines of all position fixed is bad, which I don't agree with. If it doesn't cause distress, doesn't distract the user, I don't take issue with it.
I've heard them called "vanity flaps", which seems to describe them perfectly.
I guess they're useful when the content is of low quality but you're desperate to keep eyes on the name of your site.
I hate them.
About the only thing worse than self-hiding vanity flap is a floating side bar using a slow animation to slide back into your field of view, just terrible.
slow animation to slide back into your field of view
I have a special section in my uBlock user rules, and it is full of annoyances like this.
Another one is an element with popup on hover, but you can only close it by hover-unhover a popup itself. Fly across such element by accident and enjoy your semi-modal “no idea how to get rid of”-popup without even clicking anywhere.
I believe this is a collective failure. First, developers praise the web/html/css ways to do things and want nothing more. Then they meet a complex layout problem (page-scrolling of an element which is partially covered) and find no solution, because they got what they wanted and nothing more. Nobody reports it as a bug or a FR, or it gets scrutinized as “Do we really need it? Here is a complex way to do that, incompatible with most designs, but doable, right?” and then gets closed as inactive, cause nothing adequate can be commented upon it. Developers develop selective blindness to very obvious layout bugs. The cycle repeats.
So many hours spent on nothing when a simple `viewport-offset-{top,…}: 20px` could solve it once and for all. Instead we will support global nonsense described in the article for years, despite it stays nonsense at any angle.
I was so happy to discover this. Went and tried it on Firefox on iPhone... Nope. Apparently it works on all other browsers on iPhone. Just not Firefox. Sigh. I found that the bug report for doing javascript bookmarks was already filed years ago, and Mozilla just ignores it. Mozilla has a bizarre decision making structure.
I suspect most of them are not like this. But their customer is not you; it's the website manager. And that manager gets promoted not by providing a great user experience but by shoving the company's name into your face as much as possible. (And also by maximizing conversions, ad clicks, and engagement. Oof. Writing that sentence makes me want to throw up.)
It is okay and works as intended. The logical move is to fix the platform, which is obviously broken. Not to blame developers. If you have external rules which motivate people to do more X sacrificing Y, but your goal is more Y, make Y one-liner and only then they will follow Y at their workplaces. On a web scale everything becomes a market and you can’t regulate a market by “don’t do that because it’s bad”. They will never have enough time for that.
I'm an enthusiastic supporter of auto-hiding headers and have added them to sites. I don't understand the hate? It's easy to scroll back down again and have the header re-hide (ie overscroll when you see it happening and then scroll down).
To me, this is better usability. I agree - fixed headers obscure the page and it's bad. But simultaneously, it's nice to be able to access the header and navigation instantly. This seems like a good compromise?
How often do you really need to access the header and navigation "instantly"? In comparison, how often do you need to reread or verify information from a previous paragraph, or review a chart or graph you viewed earlier?
It's fairly obvious which one is actually more important in the majority of cases and it's going to be the actual information you're currently reading through. Obscuring the actual content in any form is a direct reduction to page usability.
I want to access the menu 100% of the time that I'm using the site I've added the header to, after some scrolling. I re-scroll 50% of the pages that I visit.
Seems like a definite win to me? Maybe your usability desires are different than other users desires? In the case of an autohiding header - it doesn't seem like a big reduction in page visibility?
It's invasive and takes up valuable screen real estate. On top of that, it's very distracting to keep having an element bounce into view. I have a very hide time dealing with even minor distractions on my screen, personally.
I straight up permanently remove most sticky headers with Ublock Origin. 90% of the sites I read content on, I didnt get there by internal site navigation, I got there from a kagi search or HN link. The rare exception are documentation sites; I use their internal navigation often. Thankfully, though, very few of these sites use sticky headers. I just quickly scroll to the top or use the pagination buttons at the bottom.
I mostly spend time on sites that I use multiple times a day. I prefer that those sites are designed for people who use them multiple times a day, not for people who visit once, from HN.
This might be targeting a minority of users - it’s design for power users. I’d expect HN to be supportive of this sort of design.
If I am on my pc with a mouse getting to top is either a click or button combo away, so this popping up stuff is a net loss.
Its even worse on the phones where you sometimes get header plus some commercial and maybe a cookie banner, interacting with each other trying to figure out how to close them in order is a puzzle.
There have been maybe 1 or 2 sites out of all that i have visited, that I didn't immediately hate the banner.
To me it become a "site smell". So if I have an option I'll go elsewhere for my needs.
What's wrong with a small ▾ icon you could tap to bring up the menu? Then tap again to hide it? Crucially, without changing what content's scrollTop with either action? I'd expect (haha) power-users to be capable of tapping on an indicator to bring up (or down) the menu...
I don't think I have ever clicked anything on one of those headers on a website in my life. In fact the anti pattern is so obnoxious I literally couldn't tell you what's even on them.
I don't get who clicks those at all, this design choice is mostly on like blog and news pages and it makes me mad every damn time I have to scroll weird to get it to disappear again.
Honestly, if they have those elements on a page, usually the content is not worthwhile enough for me to suffer through their design. I usually just leave the page.
I can access the header and navigation instantly by pressing the home key on my keyboard, or near-instantly by flicking my phone's screen downward a few times. Having a navigation header appear is like reading a book that covers half my eyesight with a hologram of the index every time I look at the previous sentence.
I read from the top of the screen and scroll the page so that I'm always reading at the same position without much vertical eye movement, and occasionally flick back a sentence or two for context, which is why it's annoying for me. For a reader who read down the page and occasionally scrolled it would be much less annoying.
It would be ok if the header was kept just above the viewport edge and kept there (ie. slowly getting into view) when scrolling up. You still have near-instant access to the header, but it doesn't jump out at you at the tiniest hint of scroll up. The problem with "scrolling back down to re-hide" is that most of the time, scrolling down enough to hide the header also scrolls the start of the content out of view. That means you need to scroll up enough to account for both the header height and the underlying, obscured content to stay within the viewport once the header disappears. I never once in my life got it on my first try, and it often takes 3 or even 4 tries to put the first line of the paragraph at the beginning of the viewport without it getting obscured.
To me, the idea itself is not that bad and there are some usability gains to be had, but the implementations are just horrible, lazy, and user hostile.
Why is scrolling tied to changing the visible state of an interface element anyway? Scrolling down to hide and up to reveal /makes no sense/ to anyone other than the guy who wrote it (read: you).
Interface elements that pop in and out are /bad/, especially for people who aren't completely familiar with computers. Elements that change, especially ones that do so seemingly at random, are very disruptive, distracting, and hard to grasp.
An interface that is easy to understand and use has as few changing interface elements as possible, the more static the interface the better.
This method is just bad and annoying aff, even if that header makes sense to appear. Program in a hysteresis at least and only pop it up after 20-30% of upscroll.
Most implementations do the inverse: you overscroll a little, want to fix it, but the header appears. You want to scroll it away, but it persists for a while, so you lose track of where to start to make the line you needed to the top. Because user humiliation is a MUST for a modern site, I guess.
iOS Safari does it much better than a simple hysteresis for its URL bar, but I’m not sure web has enough event detail to implement its way: pull down does nothing, only “kick” down shows the bar.
I neither need nor want animated headers for anything ever. On mobile I can top the top of the screen to scroll to the top, and on PC I can use ctrl+home (on OSX Cmd+Home) or hold down middle mouse and speed scroll to the top.
The only thing that auto-hiding header does is cover up something I was trying to see.
Interesting that `javascript:` bookmarklets work on iPhones, given Apple's track record of locking everything down. Neat!
Browser extensions are still notoriously difficult to get on mobile for some reason (even on Android, which is open source-ish). So far the best method I've found for injecting JS into sites on Android is the Bromite [1] browser, a Chromium fork that allows you to install userscripts (which are like "diet" extensions). It also enhances privacy and comes with an adblocker.
In that case I’d suggest having a look at Orion, its a webkit based browser just like Safari and it tries to be close to Safari. The big difference is that you can install all extensions from Chrome and from Firefox.
Whether all extensions work is a different story but its very neat!
Its available on MacOS and iOS, both supporting extensions.
Honestly I have uBlock set in a way that blocks most of this stuff by default. I have several "steps" of permissivity:
1) (default) block all JS completely
2) Block 3rd party js
3) Permit all js (rare)
If the web fails to render in (1) and I do not necessarily need anything on that web I can get elsewhere, I just leave the web. F that web and F that creator. If I have to (webshop etc) I usualy just enable (2) which works most of the time. (3) is basically only for special webs like banking etc which is just PITA to debug as you have to be logging in constantly etc.
Websites today are just full of unnecessary crap and are downright unusable when on slower connection like 3G. Most of the webs now require your browser to download 2M of JS to have "slide out menus" or some other stupid stuff. uBlock is a must, because without that you will run out of data plan almost instantly.
And to make things worse, Chromium-based browsers will make adblocking much harder with Manifest v3. As soon as this happens, I will go to Firefox. And after that probably Links (unironically).
Btw spinning up a docker to shrink 1 JS function to a oneliner is perfectly capturing the essence of what's wrong with web nowdays :-D
Yea, it's amazing how much faster everything is when blocking 3rd party javascript with uBlock Origin by default.
I expected many websites would stop working, surprisingly though many sites work times, and i simply:
- hit my shortcut to set uBlock Origin to "relax" mode whenever needed
- exclude a few CDN's
- use a different browser (in private mode) for shopping and such
I use this all the time, it's invaluable. I also use it to remove sticky headers, which I find to be deeply annoying because they waste space and often break keyboard scrolling by scrolling the next few lines of text under the header.
In Firefox I've assigned it a keyword shortcut, so I can type `ctrl + l` to select the address bar, then `ks` `<enter>` to execute the JS without having to click.
I feel I'm getting close to the point where I'm just going to start disabling CSS and JS for normal web browsing, only whitelisting certain sites that 1. I have to use and 2. Simply don't work at all without CSS/JS. IMO browsers have abandoned their role as the "user's agent" and handed over entirely too much control over style, presentation and function to web developers. The fact that you need plugins, extensions, adblocks, bookmarklets, and so on, just to regain this control should be troubling but I guess progress has to march on.
I know I'm in the tiny minority here and firmly in the "yelling at the clouds" territory, but I really wish we could go back to the simpler times of the web being hyperTEXT documents linked together and that's it.
You're not alone, I use noscript on firefox for exactly that. It makes some websites unusable, but for normal browsing, that's what I use. If the website is unusable after allowing a few scripts, then I don't want to be there. It is horrifying when you see how much JS some websites try to pull in.
Many “content” sites are so annoying to use now that I almost reflexively click the “Reader” view and/or save it to Instapaper. If that doesn’t work, I abandon the site.
I have reader mode on by default in Brave, but it doesn’t always work and (at least sometimes) doesn’t display images from the article. reader mode is extremely non-trivial to implement
I'm not sure about Firefox, but Safari let's you set reader mode as default for a domain — and since Safari 16, this setting is synced to all your devices.
It's pretty surprising that sites optimized for Lynx first aren't a thing by now among curmudgeonly hackers. Not as a "best viewed in Lynx" joke badge, but a genuine movement. Why shouldn't you be able to provision resources or tweak infrastructure settings by clicking/tabbing around in VS Code's terminal pane, for example?
Sometimes I use Pocket for this purpose, if a site is obnoxious I tend to just click save and head over there to read. It's annoying but I haven't found a better solution for me on the phone yet.
I am already doing that (with NoScript), since browsers started supporting video, but not supporting reliable way to stop autoplay.
OTOH, i see why things like adblocking is extension. That makes browser neutral with regard to content, while different plugins can bring different policies.
> video, but not supporting reliable way to stop autoplay
It's an almost incredible situation. Firefox and Safari have a setting to stop autoplay, but much of the time it doesn't actually work, and Chrome doesn't even seem to have a setting.
It's also amazing how when enough users decide that they hate some obnoxious web site behavior (pop-up windows, autoplaying video, etc.) enough to block it, the web site designer's response isn't "maybe we should be less obnoxious" but "how can we circumvent the user's preferences?"
If I may self-promote, my extension is the best in the business at stopping video autoplay, as far as I can tell. I've been refining this feature for several years. https://underpassapp.com/StopTheMadness/
Recently i found that while basic stop autoplay option in Firefox does not work reliably, if one also sets media.autoplay.blocking_policy = 2, it works much better than the default policy.
But it seems it is still just a heuristic that blocks some JS play commands, while allows them in some context.
I'm very curious about this. It absolutely cannot be halting-problem-tricky for a browser to deduce that it is downloading multiple frames of video/audio and simply stop it. The MIME types alone should be almost a complete answer.
Firefox has never failed to stop autoplay for me. I don't have it set to stop all autoplay, because I watch an extreme amount of Youtube, but any tab that opens in the background or isn't focused has never failed to "Autoplay Blocked"
Just use NoScript. It's designed for exactly that, and it's great. Permanently allowlist the sites you use frequently, temporarily allowlist stuff as needed until the site starts working. It sucks, but leagues it's better than the unfiltered web.
Seems kind of pointless. Browsers are basically just virtual machines that run web applications at this point. I can’t even think of any plain text and image websites besides my own.
Exactly. I never understood all these "I don't enable js" comments. You kinda usually don't need to disable js on sites that are usable without js. And if you feel the urge to disable it, it is most likely that without js it's an empty page anyway.
It's difficult to tell whether the site will be usable with js before opening it, so js disabled by default provides better UX: it makes both usable and unusable sites usable. Then after the site proved itself, you can enable js if you know what you miss.
slightly unrelated, but I would really like to be able to block google’s cookies on every website except google. I do not want them tracking me across the web, but they make their site unusable if you block cookies. I tried using different search engines, but was less than impressed by any of them
uMatrix was good for this as you could block cookies. I do this in uBO, but it is a little more complicated. I block all third party JS with the following line:
*$script,redirect=noop.js,3p
and then allow google.com for google sites such as google.co.uk with:
I use JS whitelisting but haven't gotten to the point of CSS off by default yet; I suppose on the majority of sites I come across, the CSS hasn't been bad enough to warrant it.
i think it would be cool to start over with a whole new markup language. Probably keep http, but html and css and javascript are out the door. The new "browser" could be more like a container/sandboxed thing that fetches some markup and code and does who knows what.
Browsers were able to fight window.open popups back in the day by intercepting/blocking the window.open API. This was, iirc, one of the killer features of firefox back in the day. But cat and mouse: websites are now abusing CSS to recreate the popup experience.
Bookmarklets like this are helpful (and this is a great successor), but bookmarklets are very difficult to install and use for the average internet user. I could not figure out how to install this on my iPhone without using desktop Safari to sync bookmarks.
Is there any hope of browsers being able to combat popup modals and other sticky gross things in an automated (and on by default) way that doesn't totally break sites that require sticky items for navigation or other, non-hostile features?
One way or another, the endgame is going to be websites which are nothing but a fullscreen WebGL canvas driven by webassembly.
Things will steadily devolve for users from that point.
Then we’ll need about ten years for the next generation of hypermedia to surface, which hopefully won’t have Turing-complete scripting on principle. But I’m not sure whether developers are smart enough to avoid repeating the same mistakes again and again…
That may just be the day I stop using the web. I can picture it now: Me, neo-luddite, weathered and bitter, strung between the maw of capitalism and the precious tranquility of my crafted world.
...and now its replacement is back with a vengeance.
At least when Flash was common, full-Flash sites were not really as common as JS-only SPAs today, and it was easy to just block embedded plugins by default and only enable when necessary for some particular interactive element. In other words, plugins provided a clear separation between the "document browser" and the "very interactive", but with today's "JS everywhere", that distinction is getting more blurred and difficult to tease apart.
But I don't think this will be the business model of the Web at large. Server costs would be too high. Webassembly blobs with WebGL gives you the sweet spot by offloading the compute cost to the user while stripping them practically all of their freedoms.
There’s a motion to add first class support for in-page popups. Ironically that could take us back to the good old days of having a consistent target to block.
The problem is not technical - there's already a supercharged version of the old popup blocker: uBlock Origin, and it is permissively licensed such that any browser can embed it by default.
The problem is commercial - companies that make browsers have gone all-in on "growth & engagement" and the "attention economy" and rely on the web being terrible to make their money, either directly (Google, Edge) or indirectly (Mozilla, funded by Google and thus unlikely to bite the hand that feeds).
Browser makers have given up on serving their users because it turns out you make more money by exploiting them.
You can add this on iphone by adding another webpage as a bookmark using the share menu in safari and then going back and editing the bookmark so its what you want it to be.
You don't really have to. It's just minification and stuff, just a build step, I suppose the owner could do that as well, if your contribution has any value, but you didn't do it properly. Do you know a better way to build/minify js? Perhaps you have all these npm packages installed on your PC already? I don't, and I don't want to. If Dockerfile wasn't included I'd have to make my own just to run any fucking build-tools it requires to make a bookmarklet (which I most likely wouldn't bother to do). And, yeah, it requires them, this is not some optional stuff that author did just to be fancy.
You could set up some CI to make automatic builds after merging to master, but that still wouldn't solve the problem of contributor wanting to test what he wrote.
I've never used Docker (nor make). From the outside, it feels like some heavy VM thing for building isolated systems in the cloud. It's not something I'm used to seeing in the client-side ecosystem.
I just took a second look at the repo, and realized there's no package.json. Typically, an open-source JavaScript project would have one. It would enumerate the dependencies and how they work together to generate the final output.
As a JavaScript contributor, I expect to be able to type
yarn
yarn run build
into any repo to generate the output (and test any changes I've made).
I suspect the interactive web is not the author's primary platform. That's fine - it's his project; he can structure it however he wants. I was just surprised to see an unfamiliar, nontrivial dependency to concatenate a handful of lines into a bookmarklet.
Since you asked "Do you know a better way?" you can port the `npm install` line to a dictionary of dependencies in package.json. You can use wireit in that same file to chain the CLIs together, accomplishing what's currently the ENTRYPOINT line in Dockerfile.
It does the same thing that the current setup does, but it follows the conventions of the ecosystem. This makes it more available to external contributors, because they don't have to learn/install tools like Docker that aren't typically seen in JS.
Parent comment probably not worth engaging with .. but mentioning yarn / npm / node feels like some serious flamebait overkill here too :?
If it were my project I'd just be assuming contributors had internet access and advising in the readme to "search for a good 'bookmarklet generator', paste in your code, then test it". I'd then test their tested bookmarklet code before accepting any PRs. Thus reducing the repo to two files and 1% of current complexity, most of that being in the readme itself.
It does not "follow conventions of the ecosystem", it requires me, a contributor, to make sure by myself that I have some trash installed and properly configured that you, the maintainer, consider to be "conventions of the ecosystem" (which surely never is, because there are about as many of such "conventions" as there are developers). I don't need yarn in my shell (and, apparently, neither did the maintainer), so I would have to make Docker container to use it. Here the maintainer did it for me, so I am grateful for that.
If you happen to already have all this trash installed in your user space and you like typing several commands instead of 1 command (make): great, just run it without Docker, nobody forces you to install it. What's even the problem…
> From the outside, it feels like some heavy VM thing for building isolated systems in the cloud
I use Docker for everything locally. As a Python dev tired of fighting with different versions, virtual environments, wheel-issues etc...
> This makes it more available to external contributors, because they don't have to learn/install tools like Docker that aren't typically seen in JS.
I feel it's a bigger burden on me having to install whatever tools a random project expects. I vastly prefer a Dockerfile that just works, without me having to spend hours matching their setup, and also has the benefit that it doesn't pollute my system with lots of stuff.
Just depends on what you expect your contributors to be more familiar/comfortable/ready for. For most JS projects, package.json is the expected onramp for new contributors. We all have node installed.
This is the dumbest conflict between two opposing parties that are equally-wrong-but-equally-dug-in that I've seen in a while.
Not everyone has NodeJS. And not everyone has Docker, either. You know what we all do have?
A Web browser. The World Wide Wruntime.
You know—it's the thing that you're using to look at the README on GitHub (and this comment, probably), and is the reason that JS and bookmarklets even exist in the first place. It's widely popular exactly for its ability to publish/share content and apps without any onerous install step. (It's pretty nifty. NodeJS programmers should really consider looking into it sometime.)
Build.app.htm. Double click and then drag and drop the project source tree onto the browser tab. Done.
> Do you know a better way to build/minify js? Perhaps you have all these npm packages installed on your PC already?
If only there were some sort of ubiquitous platform—a World Wide one, even—that we could reliably depend on to fetch remote resources and that was especially suited for executing JS. It would need to run the code in a sandbox of, course, to ensure that it's acting in the interests of the user—a sort of "user agent"—and not just executing arbitrary code with full rwx privileges in the interests of the script author.
What sites do you visit that don’t have sticky elements?
I’m curious because I’d love to visit sites like these too. Meanwhile most social media, blogs, news sites and probably most HN submissions too have some.
I seriously don't understand why some people seem to like position:sticky so much. It's really offensive when the element I'm trying to scroll out of the way refuses to leave and clings to the edge, almost mockingly.
I've had a "replace sticky with relative" filter in my MITM proxy since the day that CSS misfeature showed up in browsers.
position: sticky; makes tons of sense for web apps. It’s very common to want toolbars or menus always visible. I don’t think anyone in their right mind would claim that, for example, MS Word would be better if you needed to scroll to the top of the document to see any of the controls.
I don’t think anyone in their right mind would claim that, for example, MS Word would be better if you needed to scroll to the top of the document to see any of the controls.
That's position:fixed or perhaps position:absolute, not position:sticky. And honestly, the former two are far less annoying to experience because they're there from the beginning, while the latter trick you into thinking they can be scrolled out of sight, but don't.
I'm convinced that position:sticky wouldn't exist if browsers weren't beholden to advertising traffic. Someone needs to create a rival foundation to Mozilla, with some advertising and transaction processing chops, figure out how to sustain enough revenue to tax deduct enough smart promotion, and ideally, I'd personally wish, fork Pale Moon.
The German Zugabeverordnung law was very strict against any "free" commercial offer tied to the obscuring of linked purchases. But instead of being extended to embrace the creation of sponsored funnels providing free entertainment websites, as is probably now long forgotten but fallacious doctrine, the internet instead made "free", "free".
The law was scrapped in 2004, unlikely [ed] not [/ed] coincidentally with establishing peak web commercial libertarian lobbying, the more political and in earnest post dotbomb.
I used that for a while, but I was using it so often that I installed https://addons.mozilla.org/en-US/firefox/addon/alwayskillsti.... Sometimes I see things flicker briefly into view and I'm reminded that it's working. I've had to whitelist several sites that I use regularly, but it's pretty low maintenance after that.
It does the same thing, and in addition also prevents any async JS from running. It also can be easily toggled per-site; just click the extension icon! Unfortunately I didn't have time to put a GIF in the README. OP did a better job of explaining what their project does!
Would love feedback on it + hope it helps someone as well!
Is there a way to do this on mobile? Probably not an easy one, but if mobile Safari had an extension, I'd install it immediately.
The worst is when you use the top edge of the screen to read, but the site has a navbar that only shows up when you scroll up. So if you scroll slowly upwards, the navbar creeps slowly downwards, and keeps hiding the text you're trying to read. Thankfully such design choices seem to be getting rarer.
Do sticky headers measurably increase conversion rates, or is it a fad? If there's data to support why people keep making this decision, I guess I could be persuaded to feel that it's not a case of "Everyone likes to do it their way, and you like your way."
I spent an afternoon trying to figure out how to detect when an element had its display or transform properties changed when it was also the full size of the screen. This was my proposed heuristic for deciding when something was a full screen popup, in the process of taking over your window. The idea would be to zap these elements when they were triggered, so that you'd not have to encounter them in the first place.
Cool story huh? Anyway, that never went anywhere, but I'd donate to an open source project if a better programmer than me wanted to take on this noble struggle.
I use this often. However I sometimes want the sticky part to stay where it initially rendered on the page, like a nav bar. Perhaps I don't know enough CSS but anyone know how I can do that?
I use an addon called "nuke anything" that lets you right click and remove pretty much anything (only until the page is reloaded). It's a lifesaver when you browse with JS disabled since that can cause pages to display poorly (menus spewed all over the screen for example) but it comes in handy a lot for sticky elements. I have seen a few sites that manage to prevent certain things from being selected though. It's nice to have yet another tool to fall back on if I need it.
Yeah, I put that to work a lot too, but nuke anything is great for sites you're probably not going to visit more than once since it doesn't clutter up your filter list just to get something out of your way (I'll even remove images or menus if they're distracting me from content while reading). If I do add a random one off website to uBO it's usually because they did something really obnoxious and I was like "Never again!"
It also supports a keyboard shortcut to enter the zapper picker mode, but depending on your browser you may need to enable shortcuts for the extension.
On Unix, when you have Node.js installed, you can avoid the Docker overhead for creation of a bookmarklet from a JS file with a shell script like this:
I sometimes end up on pages that I can't scroll. It turns out some pages show a sticky div with a cookie consent dialog, and uBlock has removed it but left the overflow: hidden on the body tag that the site owner found necessary to put there until I click on the now removed div for some reason.
Unfortunately, bookmarklets don't work on Firefox mobile. Fortunately however, the "Hide Fixed Elements" and "Scroll Everywhere" add-ons do work on mobile:
> This bookmarklet worked for me using Firefox on Android
do you happen to use some other version of Firefox? I tested for stackoverflow and it didn't work. There's also a open bug about bookmarklets not working on android Firefox https://github.com/mozilla-mobile/fenix/issues/2871
Tried this script on a handful of different websites - news, tech, forums, reddit. In 100% of cases this scripts nukes top header completely, leaving me without navbar or menu. So it is a very enticing tool, but unfortunately not usable.
Sticky positioning on mobile devices is rarely a good experience. (Though it might be my tiny phone screen.) I would love for it to get special treatment on mobile so it could always be dismissed or something.
i wish there was a way, with CSS only, to specifically target existing css rules, and have one rule change to another rule, globally. for instance, something like: [position:fixed] { position:relative }. i.e. that is different than * { position:relative }, because it doesn't apply position:relative to everything, it only changes position:fixed to position:relative.
So many sites have a top banner that disappears as you scroll down a page, but as soon as you scroll upwards even a little bit, it pops up again. This is immensely frustrating because I tend to read at the top of a page and scroll down as I'm reading. So if I scroll down slightly too far and then correct myself, the banner will instantly obscure the bit of the text I'm trying to read. It's very satisfying to be able to click on the bookmark and fix the site's crap design!