data-start: The element will become fixed when the viewport bottom offset has reached this distance.For learning purposes, I've also shown the distance the viewport (the window) has been scrolled, and the distance of the element from the bottom of the viewport, as these values are used in the logic to start/stop/calculate the position of parallax elements.įor this demo we are using a simple, which has the following data attributes set which define the parallax effect (all values are in pixels):.The CSS position value is shown inside the brick.We'll set bounds on the parallax effect, so the brick always stays within it's container. Update 2: Check out my demo showing the scroll event problems on mobile! Demo time: Let's make the red brick fall down the page as we scroll! RequestAnimationFrame is only available in iOS6, so stay tuned for an update for mobile performance, or feel free to help me out in the comments! I've investigated using setInterval hacks to keep checking the scrollTop position of the window, but this feels dirty, and is still unreliable considering how infrequently the value is updated. Update: haven't been able to get this working correctly on iOS devices yet :-( If the overlapping element is tall enough, it should provide enough time for the scroll events to fire and position the brick relatively in the correct position. Consider placing an overlapping element with a higher z-index at the end point, so even if the brick overruns, it will be behind the higher element. The bug you'll see is when you swipe past the end of the container and release your touch before the brick has hit the bottom, it overflows the container, and position: relative is only applied when the queued scroll events are fired when the scroll transition has ended.Ī solution for this problem (well, more of a workaround), is to design your parallax effects with this in mind. For this reason, I've decided to bind both the touchmove event and the scroll event. Binding scroll and touchmove eventsĪs touchmove events stop when your finger leaves the screen, but the browser will continue to scroll for around a second as part of the 'slowing down' easing effect. Instead, we have to tie our animation logic to touch events if the browser supports them. This is going to result in extremely jerky animations if we rely on the position of these events. Unfortunately, we have to deal with the following problem: iOS devices freeze DOM manipulation during scroll, queuing them to apply when the scroll finishes. Previously I've referred to scroll events. When we get to dealing with the speed property, we'll look at using transform properties to enable supported mobile devices to use the more powerful GPU to perform the animations. Mobile devices are less powerful, which can cause jerkyness when dealing with animations applied dynamically through JavaScript. For more complex animations, use hardware accelleration where possible.The parallax settings defined in the HTML of each element will not change, so we would be sacrificing performance if we were grabbing these values on every scroll event. Obviously if we're adding a speed to the effect later on, whereby the element moves at say double the speed of scroll, we're going to need to update the position on every scroll event.Īnother important way of reducing the DOM interactions is to store all the static values from the parallax elements straight away when the page is loaded. Ideally we should only be interacting with the parallax elements at the breakpoints (start & stop positions), so we can try to make use of CSS fixed positioning to accomplish the desired parallax effect.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |