When snapper object is "closed", the element has inline style set. If the element contains another element that has position:fixed, it no longer behaves as expected, and scrolls with the page content. Setting the -transform css property to -transform:none fixes the issue.
Why would you have the content element's display set to inline?
Check out Ratchet's template: http://jakiestfu.github.io/Snap.js/demo/apps/ratchet/template.html
@jakiestfu I didn't mention anything about an element's display being set to inline. I was referencing the css -transform you set as an inline style, ie <div style="-webkit-transform:">
I have submitted a pull request that fixes this issue for me.
I wil look into Ratchet's template -- what are the noteworthy differences here?
I understand your issue now, though I have not tested it. Ignore my Ratchet comment, it doesn't apply. When you said inline styles, I assumed you meant inline display, but you mean actual inline styles.
What browsers are you using to reproduce the error?
Chrome Version 28.0.1485.0 dev
Hmm, I cannot recreate it. If you look at the ratchet template, the content area has a child toolbar whos position is set to fixed. Then when you set the content's transform to all 0's, it is still fixed and not absolute...
It doesn't actually change the position:fixed, but the behavior of the fixed element behaves like a static or relatively positioned element.
What I'm saying is it doesn't even behave as if it is absolute VS fixed. The ratchet template's toolbar stays fixed, with translate3d vals set to 0, and content overflowing.
Could you provide a quick JSFiddle or demo of this error?
If that's the case it's likely something on my end. I am also having a weird white "flicker" when beginning to click or drag the Snap element. Very confused.
If you provide an online demo, I can help you out!
It's a quite complex site, hard to break it down into a jsfiddle as of now :(
jakie8 [at] gmail [dot] com, it is my pleasure to help out, I certainly don't mind. If not, I will keep this issue open for a while to keep it in the back of my head
I found out what's causing this: https://code.google.com/p/chromium/issues/detail?id=20574
So, you can't have a position:fixed element that has a CSS transform applied to it in Chrome/Safari right now.
@Lordnibbler 🍻 Damn, must have been bothering you. Good hunting, and thanks for updating this issue with that link
I also fixed the flicker that not having the -transform CSS causes using -webkit-backface-visibility: hidden;
Hope this helps ya and anyone else experiencing these issues.
Just jumping in here and have a quick question: is this why when I set position: fixed on #toolbar it won't stay fixed? Because #content has the transform rule in order to let it slide over?
@jonscottclark You might want to reference @Lordnibbler, I have yet to see this problem in action...
@jonscottclark in my case, the position:fixed not working was a webkit only issue, so for chrome/safari I had to set -webkit-backface-visibility:hidden on the element that refused to stay fixed.
Hey all, I seem to have solved the issue, and I'm pretty sure I was barking up the wrong tree here thinking my shit wasn't working because of a browser bug. I had some markup issues that I fixed by checking over the demos again. Sorry y'all. Thanks for the great script, @jakiestfu
@Lordnibbler my problem is that when I open the menu, my fixed navigation seems to become unfixed and goes back to being relative, any ideas? Thanks for any help you can provide.
@schmolzp This might not help, but just ensure that you follow the markup example that @jakiestfu posts in the readme (https://github.com/jakiestfu/Snap.js/#layout). I had an issue with some extra divs that completely threw off the desired positioning.
@schmolzp I designed my site's main layout around this demo: http://jakiestfu.github.io/Snap.js/demo/apps/ratchet/template.html
If you still have issues, I'd suggest applying the css I mentioned in my previous comment to the elements that are refusing to stay fixed.
@Lordnibbler @jonscottclark Thanks, I'll see if I can figure it out
If :fixed cannot be applied to the anything within -webkit-transform how is it that Ratchet is able to get their "bar-*" to be fixed?
I have looked at this over and over again and I am perplexed. I am not using Ratchet on my project but I am facing this issue of creating a fixed title bar that will move with the snap-content container.
@jaywolters I'm not entirely sure about the fixes headers used in ratchet, but if you want a fixed header that moves with the content, then it needs to be absolute.
I'd almost recommend never using fixed headers with a mobile web app.
I would tend to agree with you however Facebook, LinkedIn, Twitter, Gmail (ios), Pandora, and so many others I cant even list all have a static header at the top while content flows. I am looking to use Snap in a UIWebView for a native iOS application where there will not be any other controls. Im going to take another look at Ratchet and perhaps stop reinventing the wheel. Thanks for Snap.Js Jake!
You can have that if you make the header, content, and footer sibling elements instead of having the header and footer within the content area. It's just more pragmatic CSS than anything
Struggling with this issue as well. Translate3d creates it's own system of coordinates that affects fixed and absolute positions. The only work around this problem would be adding an event listener that would fire a reverse translate3d animation for the fixed child object. The portion of code that triggers translate3d for the content is way to intense for me and I wonder if Jake can help out?
I fixed it by using this code :
first i added this css to snap.css file at bottom so that it will override default transform behaviour:
and in js after initializing Snap, i used this code.
Hope that work-around will help.