A thing that I’ve seen succeed pretty well before is to put make the page anchor which is intended to be the target of a URL fragment start one-fixed-header-width higher than where it looks like it starts. i.e. each fragment target has a hidden invisible bit that pokes up by a fixed-header’s-height in order to cancel out the fixed header when scrolling to it.
TBH fixed headers are kind of… ewww? I suppose things like floating table headers exist as benign examples, but these days the majority of the fixed onscreen elements I see on a day to day basis on sites are dickbars.
(Aside: isn’t it just atrocious how ugly Medium is to look at? especially for a site which claims to be all about design and typography.)
Want to know what’s really annoying? Medium’s top bar switches to “Chrome-for-Android-style” auto-hiding, and the bottom bar goes away entirely, when you are logged in. They are persistent if you are logged out.
They are trying to incentivize you to make an account. Which, now that I think about it, is a dirty tactic and I should probably delete my Medium account now that I know about it.
I didn’t know this because it has never, ever for even one nanosecond occurred to me to actually make a Medium account. I’d rather step on a Lego brick barefoot.
Good point, yes. In fact this is true for that link if you’re logged in to WordPress, because WordPress uses a fixed header. (I always wondered why that happened…)
In my own app this wasn’t such a big deal, but it did make element.scrollIntoView() a bit challenging. I ultimately had to call scrollIntoView(true) and then immediately update the scrollTop to account for the height of the nav header. Not unworkable, but not ideal either.
This also fixes tap top of screen to return to top, which breaks when content is scrolled inside an element. (Glaring at you, amp.)
Great point, yes, this also improves usability on iOS. :) I added a note to the bottom of the post.
Warning:
This trick can break fragment scrolling (like https://nolanlawson.com/2018/11/18/scrolling-the-main-document-is-better-for-performance-accessibility-and-usability/#respond, though this page doesn’t have a fixed header, so it doesn’t manifest the problem). Sure, it’ll still scroll to it, but the fixed header will end up covering up the top of the section that you scrolled to.
A thing that I’ve seen succeed pretty well before is to put make the page anchor which is intended to be the target of a URL fragment start one-fixed-header-width higher than where it looks like it starts. i.e. each fragment target has a hidden invisible bit that pokes up by a fixed-header’s-height in order to cancel out the fixed header when scrolling to it.
TBH fixed headers are kind of… ewww? I suppose things like floating table headers exist as benign examples, but these days the majority of the fixed onscreen elements I see on a day to day basis on sites are dickbars.
(Aside: isn’t it just atrocious how ugly Medium is to look at? especially for a site which claims to be all about design and typography.)
Want to know what’s really annoying? Medium’s top bar switches to “Chrome-for-Android-style” auto-hiding, and the bottom bar goes away entirely, when you are logged in. They are persistent if you are logged out.
They are trying to incentivize you to make an account. Which, now that I think about it, is a dirty tactic and I should probably delete my Medium account now that I know about it.
I didn’t know this because it has never, ever for even one nanosecond occurred to me to actually make a Medium account. I’d rather step on a Lego brick barefoot.
Good point, yes. In fact this is true for that link if you’re logged in to WordPress, because WordPress uses a fixed header. (I always wondered why that happened…)
In my own app this wasn’t such a big deal, but it did make element.scrollIntoView() a bit challenging. I ultimately had to call scrollIntoView(true) and then immediately update the scrollTop to account for the height of the nav header. Not unworkable, but not ideal either.