Hacker News Reader

Comment by RandomBacon | Hacker News Reader

One of my favorite bookmarklets to remove cookie notifications or other obnoxious overlays:

    javascript:(function(){(function () {var i, elements = document.querySelectorAll('body *');for (i = 0; i < elements.length; i++) {if (getComputedStyle(elements[i]).position === 'fixed') {elements[i].parentNode.removeChild(elements[i]);}}})();document.querySelector('body').style.setProperty('overflow','auto','important'); document.querySelector('html').style.setProperty('overflow','auto','important');})()

View on HN

It does not work with Techcrunch, or yahoo/Oath websites, which just do this at the HTTP level.

This is run in your browser after the page content downloads and renders. It doesn't matter what tricks the server does.

The page does not contain the content. If you don't have the proper cookie, it redirects to a separate consent page; it looks like it's a popup, but the page has no content. It does not matter how much you massage the DOM or CSS: there's nothing below the "popup".

Ah, I see what you mean. Yeah, that wouldn't apply here.

It's likely that simply setting a particular cookie with a dummy value would bypass this.

Washington Post's paywall has a fun variant on this where not only does it omit the content, it changes the current URL so you can't reopen it in another browser or share it with someone. It's exciting seeing how creative services will get when they're trying to get you to give away your data and/or money for something you can't see.

Not to worry, I had a paid subscription and they still tried to track me constantly with 3rd party cookies on top of being able to track me from being logged in (and paying over a hundred dollars a year for the privilege).

Just use NPR and donate the amount you'd willingly pay for the paper to your local station.

> It doesn't matter what tricks the server does.

The server doesn't serve you the content until you accept... so it does matter what the server does.

I'd really like to see an addon that just blocks the css overflow attribute. I've only ever seen it used by websites that try to stop people who are blocking their giant modal popups from scrolling.

It might be that I'm dumb and can't figure out how to add a ublock/umatrix rule to block it, but I'd love a single purpose addon that just deletes "overflow:hidden" in all cases.

document.querySelectorAll('*').forEach(e => e.style.overflow = 'unset')

Nice, I'll keep that as a bookmarket, saves me rooting around in the inspector!

May also need to add others like e.style.overflowY

I think you mean position: fixed or sticky? Overflow controls what happens when the contents of a bounding box exceed it's allowed size, which is usually to hide or make the box scrollable.

'overflow: hidden' is often used to make the content of a page unscrollable on less technically adept news sites where the content is still present on the page.

many sites use overflow hidden on body to disable scrolling until you close the popup

Not a straight block, but a super handy extension is BehindTheOverlay. It gives you a consistently placed button that removes overlays. Instead of hunting for an X or cancel or close button, you use your muscle memory and always hit the same place in the Chrome.

https://chrome.google.com/webstore/detail/behindtheoverlay/l...

https://addons.mozilla.org/en-US/firefox/addon/behind_the_ov...

https://github.com/NicolaeNMV/BehindTheOverlay

Nah, doing this would also break things like carousels/slideshows too, as well as menus that slide in from off screen.

And while it's rarer than those, I've definitely also seen page components which show a preview of the content until you click on them, then expand to show everything else. Those would break as well.

So while you'd certainly block modal popups that prevent scrolling, you'd also break a bunch of things on other sites that use the overflow property for more legitimate reasons.

I prefer carousels and slideshows "broken", so I can use my browsers fast built in scroll rather than the visible slow javascript one. This falls under the category of "stop fucking with my scrollbar", a message I wish I could write on enough cakes to send one to every webdev on the planet.

The slide out menus would be a shame, but I'd give that up to prevent it's rampant abuse everywhere else.

Deleting everything with position: fixed is bad idea jeans!

No, it's not. The vast majority of sites that use it are putting bars across the whole screen to permanently display something that really doesn't need to stick around the whole time I'm trying to read the real content.

I've been using a similar bookmarklet for years now, and I have never seen any 'proper' content deleted by it. The fixed elements of a webpage are overwhelmingly likely to be useless and annoying wastes of space.

They can be menus. It's fine to make the menu scroll, but deleting it may not always be what you want.

In the very rare case that I want to use the menu on a page I'm reading (rather than an app I'm interacting with) I just refresh the page.

Tell me a legitimate use-case for position:fixed on a website. Not a web app, a web site.

How does your blocker know which URLs you are visiting are "web apps" and which are "web sites"?

I don't know which this is (or where the line is), but here's my latest project at my day job, where we used `position: sticky` for a sort of control bar, that I think worked out fairly well. (There are still some UI issues, but I think fewer than most of our peers trying to implement similar functionality).

https://digital.sciencehistory.org/works/4j03d097t

Switch to "transcript" tag, scroll around, click on timecodes to listen to that part of recording, etc.

It's a bookmarklet, which means it only runs when you ask it to, so I don't think it really needs to know the difference between a web app and a web site?

Ah, sure, that makes sense.

(But can someone give me the personal satisfaction of agreeing the project I just finished made a legit and cool use of position sticky, haha).

Good job! Keep building things.

There's a limited number of web apps that I use. That changes rarely and they can be whitelisted. E.g. I can assign some privileges to Google Docs or something like that, but it's perfectly reasonable to treat all random web links to new sites as "not-a-web-app".

Off the top of my head, the easiest one to think of is a shopping cart. A few e-commerce platforms I know of (Squarespace, some Shopify plug-ins, etc) utilize a fixed, floating widget for the cart.

Lightbox

navigational elements like menus or app bars are often fixed to the top. If you plan to actually navigate to different pages on the website, you've removed your ability to do that.

It's also possible that the creator of the site did some weird stuff and the entire body has fixed positioning for some weird reason. You can't predict how people will use innocuous CSS rules, and randomly deleting elements just because they have a certain style is easy but wildly imprecise. Seems better to just set everything with position: fixed to be position: static and unset any overflow rules.

The compose email box in a webmail client, like the one Gmail displays in the bottom right corner.

Alternatively, you can put user options there too, like a sort of floating toolbar. Sites like Medium do this in their WYSIWYG editor, and some of my own sites do this to display such options to logged in users.

Oh, and media players you might want to keep open as you scroll down the page/through the site. YouTube has a miniplayer option for just this, and a site with a music jukebox might want to use the same thing there too.

And yes, those mini carts you see on ecommerce websites when you add a product to your basket.

>> Not a web app, a web site.

> webmail client

> WYSIWYG editor

> media players

So did GP edit their comment, or did you ignore half of it?

Well, your web app vs web site distinction is very arbitrary. For example, imagine if it happened to be "it's a web app if it can benefit from position:fixed". Then your input isn't going to be very useful here.

Also, your accusation isn't warranted. Just because someone doesn't know your arbitrary distinction between web app vs web site doesn't mean they ignored the person above them.

I don't think most people would consider HN suddenly a web app if it upgraded its <textarea> into a wysiwyg markdown box.

> Well, your web app vs web site distinction is very arbitrary.

It's subjective. Your assertion that it's arbitrary is unfounded; you're clearly not even trying to imagine what a reasonable definition of that distinction might be.

> I don't think most people would consider HN suddenly a web app if it upgraded its <textarea> into a wysiwyg markdown box.

I'm pretty sure HN wouldn't need to abuse position:fixed to implement a WYSIWYG comment editor.

Reply on news.ycombinator.com