I came across at a lot of this websites which have animations that get triggered throught the scroll. I actually at first thought we did it in javascript by calculating the position of the cursor relative to the website page we can through animations at each positions.
But when I did a bit of googling I found this stuff about Intersection Observer. Is there are any performance issue or something of sort to my visioned method?
NB: I am looking for a way to do it without a framework.
Before the Intersection Observer API you would listen for the scroll event and check the position of the elements with each scrolled pixel. That is performance heavy work and gets called a lot! Intersection Observers are designed to tackle this issue in a performant way. You won't get better performance from an alternative.
You don't need a framework. The API is native to your browser (considering you have support).
If you're looking for ready to use animations, then AOS library is a good example. There are lots of other libraries for animating on scroll.
Related
I'm currently maintaining an old legacy project, where I just noticed a message from my browser about how scroll-linked effects reduce rendering performance.
The application is rendering a large form, on the bottom there is a slider with lots of data, which will be loaded asynchronously (and only if the user scrolls down, so it gets into his view). Afterwards it creates a lot DOM-elements (a lot means a typical of 100-300 figures with an image, texts and some attributes each) that will be added into the slider.
So I was reading about Scroll-linked effects on MDN to take care about this performance issue, but I don't know what's the best practice is. Neither I can use the examples about "sticky positioning" nor "scroll snapping". Also I do not want to customize scrolling in any way.
The goal is of this behavior is to delay loading the big bunch of data as much as possible (since only when the user scrolls this page down, he really needs this data).
Can you please help me how to take advantage on this, to optimize the scrolling performance of the application without losing the lazy-loading feature?
You can use a combination of check element visible in the viewport + requestAnimationframe
https://stackoverflow.com/a/125106/800765
I have been using react to build out an editor. One of the configurable properties is to dynamically generate background color animation. For example, an infinite fade in and fade out with a x second period.
The problem is that the color animation needs to be same and synchronized in multiple views. CSS animations does not enable that synchronization without being hacky. I want to use 'react-motion' but it does not incorporate timing easily.
Looking for some concrete examples using react + react libraries (ideally react-motion). Thanks in advance.
Not a direct answer to your request for examples using react + react libraries, but, if you're rendering on the client/browser you can use a global var for keeping sync between views. If that is too "hacky" for you, then perhaps finding a common parent up the ladder that both views can be handed a synchronized var/value.
After doing quite a bit of research into all of this, it turns out that the answer is just working at the animation frame level.
CSS animations abstracts all of this away from devs but as a result it gives very little control between animations.
React Motion react-motion while a good library for dealing with transition animations (it's intended purpose) again does not address controls between animations.
They key though exists in the react-motion code. You just have to request animation frames one after the other using raf library and then calculate the animations per view using the common frame info. It's pretty tedious and no real generic solution here.
I'm trying to create a page similar to new google calendar landing page http://www.google.com/landing/calendar/
I'm using skrollr(https://github.com/Prinzhorn/skrollr) but I can't get the effect right, on google landing page if you do a small scroll it will send you to the next block and with skrollr I'm not able to get that navigation. Any ideas how I could reproduce that? is it possible to do with skrollr or you would recommend another js plugin?
Thanks!
In case you still haven't found a solution yourself, I've been tasked with doing a very similar thing. There are two ways of achieving this that I researched and choosing the right one mostly depends on the complexity of your design/expected result. Unfortunately I can't provide a link because the site won't be live for next couple of weeks.
This is what worked for me:
I used fullpage.js library to achieve 'full-page' scroll effect. You could also take a look at onepage-scroll.js and see which one fits you most - they don't differ that much in terms of functionality though.
Benefits of using fullpage.js (among other things):
integration is quick and simple
allows a lot of customisation through options hash
provides callbacks when scroll to another section is triggered (before or after it happens)
enables you to manually trigger a scroll via 'methods'
works surprisingly good on iPad/iPhones. Probably on other mobile devices as well, although I can't fully confirm that since that
wasn't a requirement for my project.
Now when you've got section-to-section scrolling in place, what's missing is the animations. Considering that fullpage.js provides you with callbacks, it's as easy as adding a class when a transition to another section/slide happens and then using that class to trigger an animation of your choice through CSS. This is what worked for me without facing major problems.
For more advanced things:
If you're looking to build something more complex, then I strongly recommend that you take a look at tween.js. This is what google used on the landing page that you've provided in your question.
It's a very powerful tool hence it requires quite some setup + it moves animations to javascript, which might be a hassle. I would rather keep them in CSS where they belong and dont use javascript until I really need to.
FYI I also started with skrollr but it won't really work with 'fullpage scroll' because what it really does is disabling scrolling and animating body/html through translate. Skrollr bases it's behaviour on scroll event which will not fire if you use libraries I proposed.
EDIT:
It appears that you can actually use skrollr in par with fullpage.js. You can see the answer on how in it's FAQ site. Thanks to Alvaro for claryfing that! Even then, I wouldn't use skrollr unless you really need it for some advanced parallax scrolling effect - as said before, depends on your needs though. :)
Let me know if you have any doubts or something is not clear in my answer.
Good luck!
Having discovered requestAnimationFrame just a moment ago, I have dived into all the information I could find about it. To name just a few of the resources I came across in case there are others looking for more info about it:
http://creativejs.com/resources/requestanimationframe/ - explains the basics about it.
http://www.html5rocks.com/en/tutorials/speed/animations/ - explains how to use it.
Anyway, all of these resources tell me something about how requestAnimationFrame works or how it could/should be used, but none of them tell me when it is right to use it.
Should I use it for animations (repeated changes to the style of an element, much like CSS animations)?
Should I use it when an automated event wants to change the css/classes of one or multiple elements?
Should I use it when an automated event wants to change the text value of one or multiple elements? (e.g. updating the value of a clock once every second)
Should I use it when an automated event wants to modify the DOM?
Should I use it when an automated event needs values like .offsetTop, .offsetLeft and then wants to change styles such as top and left a few lines further?
Should I use it when a user generated event causes any of the above changes?
TL;DR: When is it right to use requestAnimationFrame?
You shouldn't yet. Not really, at least. This is still experimental and may or may not reach full recommendation (it is still a working draft at this point). That said, if you don't care about older browsers, or willing to work with the polyfill available the best time to use it is when you are looking to draw things to the screen that will require the browser to repaint (most animations).
For many simple modifications of the DOM, this method is overkill. This only becomes useful when you are doing animations when you will be drawing or moving items quickly and need to make sure that the browser repainting is keeping up enough to make it smooth. It will allow you to ensure that every frame you calculate will be drawn to the screen. It also provides a utility for more accurate time measurements to your animations. The first argument is the time at which the paint will occur, so you can ensure that you are where you should be at that moment.
You should not use it when you are doing many simple modifications to the DOM, or things that don't need to be smoothly transitioned. This will be more expensive on your users' computers so you want to limit this to making things smoother in transitions, movements and animations. Forcing a frame redraw is not needed every time you make a change on the page, since the response will be fast enough most of the time you don't need to worry about that extra couple milliseconds between draws.
As the previous answer says, you should not use it in the discontinuous animation because that don't need to be smoothly transitioned. In most cases, it's used for properties which vary continuously with time.
I'm making an TV Guide. See http://i.tv/guide for an example implementation using Canvas.
I need to make lots of little boxes representing each show. I need to be able to scroll them around, both vertically (channels) and horizontally (time). To make it with Canvas, my understanding is that the only way to implement scrolling is to intercept the correct events, and redraw the canvas smoothly with new offsets many times a second.
If I were to use divs, I could slap scrollbars on it and let it scroll normally. I could position them once, and let the scrolling move them around, rather than re-calculating their new offsets.
Which should I pick for this kind of project? If I use divs will it be too slow? Some lineups have 500 channels. I want to display up to 4 hours at once.
Thanks!
I would strongly recommend using plain HTML in preference to canvas, for interactive elements. Apart from the speed issue (divs are usually going to be faster than drawing it all manually yourself), HTML is designed to offer accessibility and usability features for free, which you'd have to do a lot of work to get even partially from canvas.
The canvas-based guide as linked has the following drawbacks:
very slow to render/scroll, for me;
impervious to keyboard navigation;
no HTML link actions (like middle-click-link-to-open-in-new-tab or right-click-bookmark);
text not copy/pastable;
a dead loss for accessibility tools like screen-readers;
reduced browser compatibility;
invisible to search engines.
Use canvas for pretty graphical and interactive effects you can't achieve with plain HTML. To be honest I don't even see any of that on i.tv's site; I have no idea why they have implemented it in this seemingly-crazy way.
Doing it with DIV's wont have issues with speed. Browsers rendering engines are built to render elements. DOM rendering is faster than canvas rendering in a lot of cases, take isogenicengine they use DOM based rendering to render thousands of elements to make games You should implement it based on your technical ability. Both technologies will be able to do what you want. Personally I would choose canvas but I see no issue with DOM rendering.
Good Luck.