The effect of the slides on the site. Version two, supplemented and revised
Some time ago I published the article “The effect of slides on the site. Through a rake on your own bike. "
The article rightly gathered a lot of comments, mainly regarding the lack of a practical part and code examples.
I bring to your attention a revised article, equipped with live examples.
While working on one of the sites, we were faced with the need to realize the effect of slides.
Namely, with vertical scrolling of the page, it should not be moved as a whole, but as a stackable stack of individual sheets.
My first thought was to use the library to add a parallax effect to the page, of which quite a lot can be found on the Internet. However, we did not need a powerful universal solution, and the time spent on reviewing, selecting and configuring a third-party solution would certainly exceed the solution of the problem head on our own. Yes, and the thirst to collect their own cones and learn the basics finally outweighed the scales in favor of their own bike.
We traditionally conduct development in Firefox + firebug.
The task essentially boiled down to changing the coordinates of the site blocks when scrolling a document inside a browser window.
Using jQuery, we simply bind to the onscroll event of the document and register there a change in the position of the blocks depending on the position of the document inside the window.
Rake number 1: If during the scrolling process we manipulate the DOM that affect the height of the entire document, we will get brakes due to the restructuring and redrawing of the content, and the most unpleasant thing is jumps during scrolling due to resizing of the scroll area and reinitialization of the scrollbar.
To avoid this, we decided not to move elements located at the first level of the document hierarchy.
Each slide eventually began to represent a div (.slide_wrapper), which was unchanged in size and position on the page, inside which there was a block wrapper (.slide), which contained the content of the slide.
To implement this mechanism, we created a class (in its javascript sense) aldparallax.
When creating an object, parameters are passed to the constructor that define the set of elements involved in the movement (.slide_wrapper) and an array with links to callback functions.
When created, the aldparallax object is attached to the scroll and resize events of the window object.
When an event occurs, an array of data is prepared for each slide (coordinates of the current visible area of the document, position of the slide in the document, coordinates of the visible area of the slide) and a callback is called, in which the algorithm for moving elements in the slide is laid.
Inside the function, we shift the position of the slide inside the container towards scrolling (by changing the top property with position: relative), which gives the desired effect.
Example 1: jsfiddle.net/88WvX
In this example, the script works with any number of slides (just add them to the html), it begins to overlap only when the slide reaches the top of the window and at the same time correctly processes situations where the slide is larger than the size of the window and its “sticking” can lead to the bottom will disappear behind the next slide before it appears in the window.
It would seem that the problem has been resolved, however, Rake No. 2 - running this solution in Chrome gives an unpleasant feeling. Slides that should simply linger at the top of the window begin to twitch unpleasantly.
The fact is that, unlike Firefox, Chrome when scrolling a page first draws its new position, and then calls onScroll, where we change the coordinates of the block and the page is drawn again.
When writing an article, it turned out that the situation was fixed in the latest Chrome updates, but I’ll give a solution, since it will be useful from the point of demonstrating an approach to solving such problems and the benefits of using callback functions.
The situation was corrected by assigning the necessary .slide elements with a fixed positioning (position: fixed;). Such elements do not change their screen position when scrolling.
It remains only to calculate the .wrapper offset relative to the window, and not the parent element and the jerks disappear. Adjust our onParallaxEvent function.
Example 2. jsfiddle.net/PWm7v
Rake No. 3 : in some mobile browsers the onScroll event is not generated until the scrolling stops completely, which leads to monstrous delays in the “animation”.
The solution may be to call the coordinate recalculation by timer, or even better through requestAnimationFrame. I leave this correction to independent work for readers.
The resulting solution has several important advantages, when disabling scripts, the page looks completely correct - only the slide effect is disabled.
When using different callback functions for different slides, you can achieve different effects and well diversify even individual blocks within the site content.
The following example is a simplified example of one of our work projects.
To prevent the Habra effect, the code was a little simplified and laid out on jsfiddle:
Example 3: jsfiddle.net/2Lhvb
The article rightly gathered a lot of comments, mainly regarding the lack of a practical part and code examples.
I bring to your attention a revised article, equipped with live examples.
While working on one of the sites, we were faced with the need to realize the effect of slides.
Namely, with vertical scrolling of the page, it should not be moved as a whole, but as a stackable stack of individual sheets.
My first thought was to use the library to add a parallax effect to the page, of which quite a lot can be found on the Internet. However, we did not need a powerful universal solution, and the time spent on reviewing, selecting and configuring a third-party solution would certainly exceed the solution of the problem head on our own. Yes, and the thirst to collect their own cones and learn the basics finally outweighed the scales in favor of their own bike.
We traditionally conduct development in Firefox + firebug.
The task essentially boiled down to changing the coordinates of the site blocks when scrolling a document inside a browser window.
Using jQuery, we simply bind to the onscroll event of the document and register there a change in the position of the blocks depending on the position of the document inside the window.
Rake number 1: If during the scrolling process we manipulate the DOM that affect the height of the entire document, we will get brakes due to the restructuring and redrawing of the content, and the most unpleasant thing is jumps during scrolling due to resizing of the scroll area and reinitialization of the scrollbar.
To avoid this, we decided not to move elements located at the first level of the document hierarchy.
Each slide eventually began to represent a div (.slide_wrapper), which was unchanged in size and position on the page, inside which there was a block wrapper (.slide), which contained the content of the slide.
To implement this mechanism, we created a class (in its javascript sense) aldparallax.
When creating an object, parameters are passed to the constructor that define the set of elements involved in the movement (.slide_wrapper) and an array with links to callback functions.
When created, the aldparallax object is attached to the scroll and resize events of the window object.
When an event occurs, an array of data is prepared for each slide (coordinates of the current visible area of the document, position of the slide in the document, coordinates of the visible area of the slide) and a callback is called, in which the algorithm for moving elements in the slide is laid.
Inside the function, we shift the position of the slide inside the container towards scrolling (by changing the top property with position: relative), which gives the desired effect.
Example 1: jsfiddle.net/88WvX
In this example, the script works with any number of slides (just add them to the html), it begins to overlap only when the slide reaches the top of the window and at the same time correctly processes situations where the slide is larger than the size of the window and its “sticking” can lead to the bottom will disappear behind the next slide before it appears in the window.
It would seem that the problem has been resolved, however, Rake No. 2 - running this solution in Chrome gives an unpleasant feeling. Slides that should simply linger at the top of the window begin to twitch unpleasantly.
The fact is that, unlike Firefox, Chrome when scrolling a page first draws its new position, and then calls onScroll, where we change the coordinates of the block and the page is drawn again.
When writing an article, it turned out that the situation was fixed in the latest Chrome updates, but I’ll give a solution, since it will be useful from the point of demonstrating an approach to solving such problems and the benefits of using callback functions.
The situation was corrected by assigning the necessary .slide elements with a fixed positioning (position: fixed;). Such elements do not change their screen position when scrolling.
It remains only to calculate the .wrapper offset relative to the window, and not the parent element and the jerks disappear. Adjust our onParallaxEvent function.
Example 2. jsfiddle.net/PWm7v
Rake No. 3 : in some mobile browsers the onScroll event is not generated until the scrolling stops completely, which leads to monstrous delays in the “animation”.
The solution may be to call the coordinate recalculation by timer, or even better through requestAnimationFrame. I leave this correction to independent work for readers.
The resulting solution has several important advantages, when disabling scripts, the page looks completely correct - only the slide effect is disabled.
When using different callback functions for different slides, you can achieve different effects and well diversify even individual blocks within the site content.
The following example is a simplified example of one of our work projects.
To prevent the Habra effect, the code was a little simplified and laid out on jsfiddle:
Example 3: jsfiddle.net/2Lhvb