TylerBarnes / gatsby-plugin-transition-link

A link component for page transitions in gatsby
537 stars 70 forks source link

Usage with position: sticky #77

Open mckelveygreg opened 5 years ago

mckelveygreg commented 5 years ago

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!

TylerBarnes commented 5 years ago

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.

ITSjwags commented 5 years ago

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

TylerBarnes commented 5 years ago

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!

ITSjwags commented 5 years ago

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?

TylerBarnes commented 5 years ago

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)

ITSjwags commented 5 years ago

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.

deioo commented 5 years ago

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?

ITSjwags commented 5 years ago

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.

deioo commented 5 years ago

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?

TylerBarnes commented 5 years ago

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.

JPrisk commented 5 years ago

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

littlecastrum commented 5 years ago

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.

jonathanprozzi commented 5 years ago

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.

matt-koevort commented 5 years ago

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

EricWVGG commented 3 years ago

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 commented 3 years ago

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