gatsby-plugin-transition-link icon indicating copy to clipboard operation
gatsby-plugin-transition-link copied to clipboard

Usage with position: sticky

Open mckelveygreg opened this issue 6 years ago • 16 comments

Hey, Is there a best practice way to use position: sticky elements while using this plugin? I've found that since everything is wrapped in tl-edges with overflow-x: hidden, that any sticky elements inside of that don't stick... I feel stuck because I need both page transitions and complex scroll animations for my client..

Thanks!

mckelveygreg avatar Apr 21 '19 19:04 mckelveygreg

I haven't tried this myself but if you can get me access to a demo repo I might be able to help you get it working.

TylerBarnes avatar Apr 21 '19 23:04 TylerBarnes

Also running in to this issue. If you have any parent div with an overflow, children that are position: sticky won't work. So the div .tl-edges has overflow-x: hidden on it which means any child div loses the ability to be sticky.

Talking about this here: https://github.com/w3c/csswg-drafts/issues/865

ITSjwags avatar Apr 25 '19 04:04 ITSjwags

Hmmm, I guess I'll need to find another way to control the overlapping pages. The reason for adding overflow-x: hidden is that in order to allow for persistent footers, the entering and exiting pages need to be position: relative. In order to allow them to overlap, for the time they're in the browser at the same time, they're both floated left and the second page has margin-left: -100%. Because of this, the wrapper needs overflow-x: hidden to prevent horizontal scroll bars during overlapping transitions. Previously the pages were just always position: absolute; which worked great except that any footer added to a layout would be hidden under the pages since the pages didn't take up any height. For a while I was adding a min-height wrapper to the pages using JS to take up the height of the tallest page but this ended up being buggy under certain circumstances..

It's a tricky one. If either of you have any good ideas for overlapping two elements that take up height but don't cause horizontal scrollbars when animating them horizontally, I'd love to hear it!

Otherwise I'll have to go back to the drawing board and do some more testing and exploration.

Thanks for reporting this!

TylerBarnes avatar Apr 25 '19 05:04 TylerBarnes

So the issue only exists during the transition?

Can we add and remove a class that has the overflow styling? So during the transition tl-edges tl-edges--overflow, when the transition is done we can remove the tl-edges--overflow? Something like that?

ITSjwags avatar Apr 25 '19 05:04 ITSjwags

I think all those sticky elements would unstick for the duration of the transition. You could try it out by adding some global css to override the overflow. If I remember right one of the tl elements in that area get a in-transitionclass (or similar, I'm afk right now so I can't check)

TylerBarnes avatar Apr 25 '19 05:04 TylerBarnes

Yeah that could get janky. Everything would unstick while transitioning, then stick back when it's done. I'll try to think of a solution with ya.

For now, I can reset the overflow for tl-edges on the one page that I have with a sticky element and it works fine with the AniLink cover transition. Short term solution for my specific scenario.

ITSjwags avatar Apr 25 '19 05:04 ITSjwags

The problem with resetting the tl-edges overflow manually is that transitions like AniLink are not working anymore.

If using position: fixed instead of sticky, the matrix transforms render it useless.

@ITSjwags were you able to make the cover transition play well with position: sticky?

deioo avatar May 29 '19 10:05 deioo

The problem with resetting the tl-edges overflow manually is that transitions like AniLink are not working anymore.

If using position: fixed instead of sticky, the matrix transforms render it useless.

@ITSjwags were you able to make the cover transition play well with position: sticky?

My scenario was very specific to only one page of my site. So I kind of threw a hack in to stop the overflow for that page. The cover Anilink transition still worked fine for me.

.hasStickyElement .tl-edges { overflow: unset; } something like that.

ITSjwags avatar May 30 '19 02:05 ITSjwags

Tried exactly the same, but lost all cover animations.

Here's an example with both position: sticky and position: fixed Example - see second page.

Repo

I made position:fixed work by clearing the matrix transform after it's finished https://github.com/deioo/gatsby-transition-with-sticky/blob/master/src/components/layout.css#L632

The downside is obviously if you start scrolling before the transition is done, the container won't be fixed.

Also position: sticky works by enabling this hack @ITSjwags mentioned. But the Anilink courtains are not going to work anymore. https://github.com/deioo/gatsby-transition-with-sticky/blob/master/src/components/layout.css#L624

Not sure what other option would work for position: sticky other than adding a tl-edges--entered class with overflow-x: unset?

deioo avatar May 30 '19 08:05 deioo

I think the best way forward on this one is to add a plugin option for wether or not persistent footer support is required. If it's not needed, then the pages can be position absolute overtop of each other, if it's needed then the pages can use the css they're using now. I'll have a look at it soon. I've been super busy but it's on my list to come back to this project and fix as many bugs / issues as possible.

TylerBarnes avatar May 30 '19 16:05 TylerBarnes

Found that implementing transition-link broke my css sticky elements too, was able to re-implement by making the first element inside the tl-wrapper my 'scrolling' div.

Using height:100vh and overflow:auto

Problem was that IE support for sticky positioned elements is hairy, therefore jumped to the react-sticky package

JPrisk avatar Jun 19 '19 04:06 JPrisk

Have anyone sort this issue in a way that does not affect the transitions smoothness? Tried @deioo solution for the position: fixed scenario and the transitions look choppy.

littlecastrum avatar Jun 29 '19 23:06 littlecastrum

Hello! I was doing some troubleshooting with react-waypoint, and there seems to be a similar issue. I was debugging for awhile before realizing that the scrollableAncestor that react-waypoint uses gets set to the tl-edges div.

I'm going to do a bit more digging but I wanted to post this since it does seem to be related.

jonathanprozzi avatar Aug 08 '19 02:08 jonathanprozzi

Because of this, the wrapper needs overflow-x: hidden to prevent horizontal scroll bars during overlapping transitions.

@TylerBarnes is this the sole reason for the overflow? If so, can one not investigate simply disabling the scroll bars? For example: https://stackoverflow.com/questions/16670931/hide-scroll-bar-but-while-still-being-able-to-scroll

matt-koevort avatar Aug 22 '19 06:08 matt-koevort

Also crashed into this issue.

Perhaps, rather than offsetting the hidden page by 100% x, just absolute position with opacity: 0 & touch-events: none?

EricWVGG avatar Mar 15 '21 16:03 EricWVGG

… now crashed into this issue again on a new, unrelated project

EricWVGG avatar Aug 25 '21 17:08 EricWVGG