Hacker News Reader

Comment by benjaminjackman | Hacker News Reader

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.

Just the text please! Viva le reader mode!

View on HN

> 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.

http://i.imgur.com/PNOQ4Hk.jpg

If anyone from Google is here, please do something about this as it is ridiculous.

Google fix = buy a bigger phone, so you'll see same amount of content then 4 years ago.

And in case if someone from Google is listening, give the option to opt out of this AMP crap, I'll gladly pay for extra bandwidth.

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.

Which is why an option was suggested

> And in case if someone from Google is listening, give the option to opt out of this AMP crap, I'll gladly pay for extra bandwidth.

How exactly do you land on AMP pages? Can't you just use Firefox on you phone?

Even AMP own page suffers from headers taking up 1/3 of the screen on mobile devices. https://www.ampproject.org/

> On my iPhone 5S it breaks hiding the browser's address bar when you scroll

I believe this is actually due to Safari iframe bugs. See: https://medium.com/@dvoytenko/amp-ios-scrolling-and-position...

Or, instead of using iframes, they could have just redirected via link to the actual site.

But that'd be crazy, right?

No, just way slower

Way slower? Linking to a page would be way slower than embedding the same page in an iframe?

Since when?

They use iFrames since they also have the swiping side to side interaction for multiple pages on the same topic.

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.

It doesn't bother me so much, but one thing about context that I would appreciate is date and author.

It would also reduce the number of old articles submitted to HN as a nice side-effect.

I needed "sticky" today for a table header that I want to keep visible as the user scrolls on the page...

Works already in Safari, but alas only in Chrome Beta.

It is a lot simpler and more robust than the Javascript approaches I found.

> 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!)

It's also broken for tables in Firefox despite it reporting that it supports the style: https://bugzilla.mozilla.org/show_bug.cgi?id=975644

position-sticky is still only conditionally supported in Firefox' environment, and IIRC still only behind a flag.

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 a banner ad for whatever was mis-classified from the background of the weighted average of the last 10 Facebook pictures you appeared in

Please install an ad blocker. uBlock Origin works wonderfully in Firefox for Android.

position:sticky is really awesome for table headers. Emulating that behavior with JS and CSS is ridiculously complicated.

I think you're forgetting the cookie warning.

Their css example is badly done but why not.

Reply on news.ycombinator.com