[stevage]

So it works by removing elements with "position: fixed".

But do all sticky headers work like that? In sites that I build, I tend to just have a normal div at the top, followed by a div for the main body with "overflow-y: scroll".

[chrismorgan]

Please don't implement things like that: among one or two other related problems, it breaks keyboard navigability, because the document then isn't scrollable. So users have to focus your div by clicking or tabbing to it before things like Space to go down one pageful will work.

`position: sticky` or `fixed` are the only acceptable techniques to implement sticky headers for typical websites. (There are definitely app scenarios where you need multiple scroll areas and don't want any of them to use the document scroll area, e.g. a multi-pane email client; in such cases you should then manage focus just a little so one pane gets focus when everything loses it.)

[stevage]

As a web developer, I'm well aware that pretty much every single thing I do has a better way of doing it. That's the world we live in.

[chrismorgan]

This might not be what you intended, but the impression I’m getting is that you’re dismissing my objections by saying “the world isn’t perfect so I won’t even try”. That’s a cop-out. Probably most of the thing you do don’t have an unqualifiedly better way of doing it.

This is a case where the solution you’re coming up with, which has never been the normal solution on the web but people definitely try it from time to time (perhaps because it is how you’d implement such a thing in almost every non-web GUI toolkit), causes certain very specific problems which render it unsuitable for general web content, particularly making life harder for quite a lot of desktop users (where Space/Shift+Space for scrolling is very common).

This is not a case of “well akshully” correctness, where the difference is immaterial. It’s a specific, concrete thing where it’s good to learn the behaviour of the platform, so that you work with it rather than against it, and not cause unnecessary difficulties to normal users.

[stevage]

>but the impression I’m getting is that you’re dismissing my objections by saying “the world isn’t perfect so I won’t even try”. That’s a cop-out. Probably most of the thing you do don’t have an unqualifiedly better way of doing it.

It would be truer to express my position as "my capacity for improving my practices is limited, and there are much higher priority areas than this one".

>causes certain very specific problems which render it unsuitable for general web content, particularly making life harder for quite a lot of desktop users (where Space/Shift+Space for scrolling is very common).

I'm skeptical that "a lot of desktop users" use keyboard for navigation. I'm a pretty keyboardy person, and I don't even know what this "shift+space" pattern is that you refer to. I don't think I've ever seen a person navigate a scrolling area with anything other than a mouse or touchpad.

>This is not a case of “well akshully” correctness, where the difference is immaterial. It’s a specific, concrete thing where it’s good to learn the behaviour of the platform, so that you work with it rather than against it, and not cause unnecessary difficulties to normal users.

I'm not very convinced that "normal users" are affected either way, but I appreciate your point and good-faith effort, nonetheless.

To be honest, when I think about it, I rarely implement sites that have a scrolling main body, so it doesn't come up much.