So their example use case for `position: sticky` is putting a distracting header onto a space constrained mobile device __where the browsers own address bar has the good sense to disappear__ when scrolling down. Not rise from the page like some pixel craving zombie element.
And let's keep in mind in the real world, it's going to be at least 3 times bigger than that because it's not a sticky bar for ants after all. And it'll be rocking its best friend Mr Hamburger Menu, some social-tracking-sharing-buttons, and a banner ad for whatever was mis-classified from the background of the weighted average of the last 10 Facebook pictures you appeared in.
> distracting header onto a space constrained mobile device
This is my pet hate with Google's AMP mode which most sites seem to be switching to.
On my iPhone 5S it breaks hiding the browser's address bar when you scroll, then you have the AMP 'address bar' of the same size, then you finally get to the site's sticky header and footer. On Huffington Post the content is around 50% the size of my screen. Oh and it breaks Safari's Reader mode, which I assume also means accessibility features.
Well, I do not because I am in a limited connection (~1.5GB per month). I gladly appreciate that sites loads faster when I am using a mobile connection too.
While I understand the pain of (sometimes) having broken sites when AMP is on, this really helps when someone is on a country where mobile internet is expensive.
I agree I hate sites that do that, but changing it to a CSS property instead of some custom half-assed JavaScript is an improvement because now there's at least a hope of being able to block it with some extension.
If you write a mobile SAP, you may need a quick way to change context. Gestures are limited. If at one point you need buttons / links to be always available for the context switch, then a sticky header or/or footer is a logical solution and is what is used in a native apps anyway. It also has the additional benefits of giving you a place to put something helping to identify said context, such as a label, an icon or some shape/color.
On a regular desktop you would not have this problem: you can have a menu far away from the content. You can have tool bars. You have the name of the tab and the URL giving you context, and the page need less context switching because you can just display more instead of requiring to juggle with what the viewport can display. But on the mobile, context switching is very hard to do right, and must be accessible from your thumb.
I wrote that demo. I was a little behind schedule and needed a quick example that highlighted the point. I'm not disagreeing with you but there are plenty of good usecases for this and in the case of my blog it's easy to lose track of the current section in the article.
> I needed "sticky" today for a table header that I want to keep visible as the user scrolls on the page...
Note that what you want is different from what the user wants. I am not alone in thinking that stickies never add value, no matter how convenient the designer thinks they are: https://alisdair.mcdiarmid.org/kill-sticky-headers .
I generally agree with you, but I'd argue there's good use-cases for it. I hate it when sites feel the need to add a top and bottom navbar on my already small mobile device. But on the other hand, when I'm on my desktop using a web app that displays large tables (which is pretty common for me), it's really easy to confuse the column you're looking at. In cases like that, I like having the table headers visible at all time.
I have never, mobile or desktop, seen any use case for it that I like, although I also don't do much mobile browsing; but it is fair to say that my personal preference shouldn't be what determines the future, or even the present, of web design! Despite that, I do think that it is fair to say that designers are much more enamoured of them than users are.
(It's always refreshing how civil disagreements on HN can be. Thank you for your thoughtful reply!)
I agree absolutely that this is exceedingly annoying. That said, it's popular among the people who control design decisions so it's here to stay, for now.
So do we use a javascript solution that also performs like crap, or accept that this is a common use case and provide a standard way to do it?
But plenty of sites already have floating elements that reposition based on scroll listeners. The sticky property just allows it to be done in a performant way.
And let's keep in mind in the real world, it's going to be at least 3 times bigger than that because it's not a sticky bar for ants after all. And it'll be rocking its best friend Mr Hamburger Menu, some social-tracking-sharing-buttons, and a banner ad for whatever was mis-classified from the background of the weighted average of the last 10 Facebook pictures you appeared in.
Just the text please! Viva le reader mode!