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