Search the Community

SplitText is an easy to use JavaScript utility that allows you to split HTML text into characters, words and lines. Its easy to use, extremely flexible and works all the way back to IE9 (IE8 for GSAP 2's version). Although SplitText is naturally a good fit for creating HTML5 text animation effects with GreenSock's animation tools, it has no dependencies on GSAP, jQuery or any other libraries. Note that the video below uses GSAP 2's format. .videoNav { color:#555; margin-top: 12px; } 0:00 Intro 0:21 SplitText solves problems 2:01 Basic Split 3:34 Configuration options 6:35 Animation View the JS panel in the CodePen demo above to see how easy it is to: Split text into words and characters. Pass the chars array into a from() tween for animation. Revert the text back to its pre-split state when you are done animating. Additional features and notes You can specify a new class to be added to each split element and also add an auto-incrementing class like .word1, .word2, .word3 etc. View demo You don't have to manually insert <br>tags, SplitText honors natural line breaks. SplitText doesn't force non-breaking spaces into the divs like many other solutions on the web do. SplitText is not designed to work with SVG <text> nodes. Learn more in our detailed SplitText API documentation. Please visit our SplitText Codepen Collection for more demos of SplitText in action. Where can I get it? SplitText is a membership benefit of Club GreenSock ("Shockingly Green" and "Business Green" levels). Joining Club GreenSock gets you a bunch of other bonus plugins and tools like InertiaPlugin as well, so check out greensock.com/club/ to get details and sign up today. The support of club members has been critical to the success of GreenSock - it's what makes building these tools possible. To learn how to include SplitText into your project, see the GSAP install docs. Demos SplitText Demos

https://css-tricks.com/tips-for-writing-animation-code-efficiently/

Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. Chrome 53 debuted a new "feature" to improve animation performance and graphics fidelity, but it had some nasty side effects that caused quite a few animators to get unpleasant phone calls from angry clients whose ads and web sites suddenly looked blurry and/or stuttery. Every other browser (including previous versions of Chrome) render the same animation beautifully. Chrome's new behavior may also result in WORSE animation performance. A lengthy discussion with the Chrome team revealed some disturbing tradeoffs that animators need to know about, and that could spell trouble with other browsers too unless we band together as a community and make our voices heard. At the heart of the controversy is the will-change CSS property. What is "will-change"? It gives developers a way to say "hey, browser, I'm gonna animate this property, so please do whatever you can to prepare and make it happen smoothly" which often means creating a compositor layer to get GPU-acceleration of transforms and opacity. Think of a compositor layer like a screen-shot of the element that the browser can store on the GPU to move/scale/rotate cheaply instead of re-computing all the pixels on each screen refresh. Read Sara Soueidan's excellent in-depth article here for details. Problem: blurry, stuttering animations What is Chrome 53 doing differently? Chrome is basically saying "In the past, I intelligently managed when and how to rasterize elements, but now that will-change property exists, I'll just make that serve as a blind toggle switch for rasterization instead. If things look blurry, it's not my problem - the developer will need to jump through some hoops (described below) to make things look sharp again." It all boils down to how and when "rasterization" of an element occurs (changing it into pixels stored on the GPU). If rasterization happens when the element is very small, it will be lower resolution. When scaled up, it'll look blurry/pixelated. On the other hand, if you rasterize while it's at its native scale (1) or above, you'll get a much higher-quality image with more pixels. Another key factor is how it is rasterized. Apparently Chrome uses a completely different algorithm for rasterizing an <img> than a <div> with a background-image even though both use identical source files and are sized the same! Here's an example of how they look in Chrome 53: Update: The Chrome team says they've fixed the bug that caused background-image to render differently than <img> (issue 649046) and it should be in the 9/29 release of Chrome Canary. Both factors (the when and the how) are at play in Chrome 53's new behavior (which apparently was a purposeful engineering choice based on will-change). According to this document, all content now gets re-rasterized when its scale changes (which happens up to 60 times per second during animation of scale/scaleX/scaleY properties). That's supposed to keep things sharp, but in this case Chrome's background-image algorithm applies some sort of pixel-snapping which causes that odd vibration during animation. (Update: should be fixed soon). This re-rasterization comes at a cost performance-wise too. Previously, Chrome applied some heuristics to sense when it was appropriate to re-rasterize to avoid blurriness, thus it only kicked in when necessary. But now, you must opt-in to get the layerizing benefits by setting will-change: transform. The Chrome team says this is an "improvement" because it puts the control into the hands of developers, but clearly this shift in behavior comes at quite a price. Overnight, the rug got pulled out from under many animations around the web, hurting performance (due to the constant re-rasterizing by default) and also introducing those visual vibrations when scaling background-image graphics (quite common for sprite sheets). To be clear, this primarily affected scaling animations, not ALL animations on the web. And of course anything where a background-image was used and the element was layerized (making it blurry in Chrome 53). Partial solution: set will-change: transform Complaints rolled in quickly, and the Chrome team suggested that developers go back and edit all their affected animations by adding will-change: transform which would layerize/rasterize those elements (skipping re-rasterizing on every refresh). It's a bit of a nightmare to go back and find all the affected animations and make the necessary edits, but hey, it's just adding one property to the CSS so it shouldn't be too bad, right? Oops, that breaks it in other ways Chrome chose to implement will-change such that it will trigger rasterization at whatever the current scale happens to be, so if you've got an element that starts at scale(0.1) and animates up to scale(1), rasterization happens at scale(0.1), thus it will look terrible (blurry/pixelated) at the end of the animation. Here's an example showing the SAME image animating to identical scales, but flip-flopped starting/ending values: (View the codepen here) Partial solution: toggle will-change back and forth Hold your nose...here comes the hack. In order to trigger re-rasterization of the element to keep it clear, the Chrome team suggested toggling will-change back to auto during the animation, then waiting until a requestAnimationFrame elapses before setting it back to transform...and then doing it again, and again, at whatever frequency the developer wants in order to keep things acceptably sharp. So will-change: auto is being pressed into service to explicitly tell the browser "rasterize me on the next requestAnimationFrame." Yes, you read that correctly: animators must turn **off** the very property whose entire purpose is to be **on** for animation, signaling change. Then toggle it back-and-forth many times during the animation. So we're essentially telling the browser "I'm gonna change this...no I'm not...yes I am...nope..." all while in the process of animating. This doesn't exactly sound consistent with the intent of will-change, nor does it seem performant (Google's document says "Be aware, however, that there is often a large one-time performance cost to adding or removing will-change: transform.") Gotcha: never de-layerize Even if you're willing to follow the advice to set will-change: transform and toggle back-and-forth during the animation to maintain a reasonable level of clarity, there's one last gotcha - if you set it back to will-change: auto at the end of the animation and give it a non-3d transform (to de-layerize it), you'll see a jarring shift in pixels and clarity for anything with a background-image! The Chrome team advises in that case that you make sure it always has a 3d transform thereafter to prevent it from de-layerizing. Following that advice puts you at risk of running out of memory (or hitting performance problems), plus the background-image will always be slightly blurry. Here's what it looks like to toggle between the two modes at the end of the animation: Update: The Chrome team clarified that this was a temporary fix, not a long-term solution. The background-image rendering bug should be resolved soon, and this "never de-layerize" suggestion will no longer apply at that point. The bigger issue, beyond Chrome... The will-change spec doesn't really specify implementation details which means that Chrome's new behavior may be completely unique; Firefox might do something different, and then there's Edge, Safari, Opera, Android, etc. Perhaps Chrome requires that developers toggle back-and-forth to maintain clarity, but what if Firefox interprets that differently, or imposes a big performance penalty when doing the same thing? What if developers must resort to various [potentially conflicting] hacks for each browser, bloating their code and causing all sorts of headaches. We may have to resort to user agent sniffing again (did you just throw up a little in your mouth?). This will-change property that was intended to SOLVE problems for animators may end up doing the opposite. It seems wise for the browsers to step back and let the spec authors fill in the implementation details and gain consensus before moving forward. Another problem: stacking contexts As mentioned in this article, will-change can also affect the stacking context of elements, leading to unintended changes in how things render/stack on your page. So your content may stack differently in browsers that do support will-change than those that don't. More sniffing, yay! To summarize: Before Chrome 53 Just animate stuff. No need to jump through any hoops as a developer to get decent clarity (though the Chrome team points out that there was still some blurriness in certain edge cases that they've heard complaints about). After Chrome 53 Make sure to set will-change: transform if you're animating transforms and want to opt-in to performance optimizations and avoid jittery background-image scaling. But be careful about how it might affect stacking contexts, and keep checking when other browsers decide to implement will-change, as it could change how your content looks. If you're scaling up, make sure you toggle will-change back-and-forth to/from auto during the animation to maintain clarity (but sacrifice performance). Make sure there's a 3D transform applied throughout to prevent de-layerization (which would cause a big performance hit). Don't switch back to a 2D transform at the end (at least for elements with a background-image), or you'll see a jarring pixel shift. (Update: should be fixed soon in Chrome, so this step won't be necessary at some point.) Don't forget to go back and find/fix existing animations that are affected by the new Chrome behavior. Is Chrome going to fix this? As of today, the Chrome team says they've thought a lot about this and feel pretty strongly that the new behavior is an improvement, so there's no plan to change it (that we know of at least). Here are the solutions we proposed (with the answers we got): Instead of putting the burden on developers to manually toggle will-change back-and-forth between transform and auto during the animation, just have the browser natively sense when re-rasterization is prudent and do that automatically which would be much faster than JS anyway. It seems rather trivial for the browser to sense when an element has been scaled greater than a certain delta (like 0.2) and trigger a rasterization. Chrome team's answer (summary): "that's too hard (complex). The browser might get it wrong sometimes, so it's better to have developers do it at the JS level. And JS isn't that much slower than native. It's just a small amount of extra work for animators (or library developers)." The browser could always perform rasterization at native size (scale of 1) or the current scale, whichever is bigger. That way, nobody would run into those nasty blurred images when scaling up from a small value to 1 (pretty common) and there's no need to keep re-rasterizing. Chrome team's answer: "rastering at native size and then scaling that down with bilinear filters in the compositor to something less than 0.5 or so will start to loop noticeably bad." If the goal is to put control into developers' hands, why not expose an API for defining what scale rasterization should occur at, like element.cacheTransform = "scale(1)"? Chrome team's answer: "it may not be so easy to get it right in terms of expressiveness, and requires new APIs...and also to define what raster scale means, which seems quite tricky in general, especially while not over-fitting to current implementation strategies. That might happen later on." The browser should use the same algorithm to rasterize (and scale) anything. The one being used by Chrome for <img> looks great so please use that for background-image too Chrome team's answer (summary): "Acknowledged. We're working on a fix." Instead of turning will-change into a convoluted way to control rasterization in the browser and risk opening a can of worms with other browsers doing things completely differently due to vague specs, roll back the behavior and work with the spec authors to define implementation details and re-approach later when consensus is reached. Chrome team's answer: "the intention of will-change is to give a hint to the browser that the referenced property is going to be animated, and for the browser to take steps to optimize performance for that use case. This is why will-change: transform creates a composited layer: because animating transform afterward will therefore not later have the startup cost and per-frame of creating the composited layer and rasterizing it. Following this logic, further extending the meaning of will-change: transform to not re-raster on scale change is similar, because it will make it faster." Can GSAP fix it for me? Yes and no. We've already experimented with the suggestions that the Chrome team made, but there are a few tricky challenges. First, we're hyper-focused on performance so it's quite painful to have this new Chrome behavior force us to add extra logic that must run on every tick of every tween of any transform-related animation. It probably wouldn't be noticeable unless you're animating hundreds or thousands of elements simultaneously, but we built GSAP to handle crazy amounts of stress because sometimes that's what a project requires, so we're pretty frustrated by Chrome's decision to impose this burden on animators and libraries like GSAP. But yes, we could do the toggling under the hood automatically and accept the performance tradeoff. But another major problem that's totally in the hands of browsers is rendering - we can't fix that jarring pixel shift at the end of the animations of background-image. We can force the 3D transform to remain, but as described above, that leaves things blurry and unnecessarily eats up memory. We work very hard to implement workarounds for browser inconsistencies and bugs like this, but we can't work miracles. We really need Chrome to step up and provide some better solutions. Conclusion There's no doubt that the Chrome team is working hard to move the web forward and deliver the best experience for their users. At GreenSock, Chrome is our primary browser that we use every day, so we're big fans. This article isn't intended to criticize anyone, but rather to bring attention to something that could spell big trouble for animators in the days ahead, beyond the headaches Chrome 53 caused with its new behavior. Hopefully Chrome will roll back the changes and/or implement some of the suggestions above. We'd encourage folks to make their voices heard (on the Chrome thread, below in the comments, with the spec authors, etc.). Perhaps we got something wrong - feel free to correct us or make other suggestions. Ultimately we want to help move animation forward on the web, so please join us.

#container { margin:0; padding:0; font-family: Signika Negative, Asap, sans-serif; font-weight: 300; font-size: 17px; line-height: 150%; } #container h1 { font-family: Signika Negative, Asap, sans-serif; font-weight: 300; font-size: 48px; margin: 10px 0 0 0; padding: 0; line-height: 115%; text-shadow: 1px 1px 0 white; } #container h2 { font-family: Signika Negative, Asap, sans-serif; font-weight: normal; font-size:30px; color: #111; margin: 18px 0 0 0; padding: 0; line-height:115%; } #container p { line-height: 150%; color:#555; margin: 0 0 10px 0; } #container a { color:#71b200; } #container .normalBullets code { font-size: inherit; color: inherit; font-weight: normal; line-height: inherit; font-family: inherit; } #container .normalBullets li strong { font-size: 110%; } #container .normalBullets li { margin-bottom:8px; } #container .blackBG h1, #container .darkBG h1 { color: #ddd; text-shadow: none; } #container .blackBG p { color: #999; } #container .section { width: 100%; text-align: center; position: relative; padding: 20px; } /* .block was causing conflict with wp theme --- renamed below */ #container .customblock { padding: 10px; text-align: left; position: relative; } #container .blackBG { background-color: black; } #container .lightBG { background-color: #e4e4e4; } #container .subtleDark { color: #999; text-shadow: none; } #container .blackBG p strong { color:#ddd; font-weight: normal; } #container .controls { background-color: #222; border: 1px solid #555; color: #bbb; font-size: 18px; } #container .controls ul { list-style: none; padding: 0; margin: 0; } #container .controls li { display: inline-block; padding: 8px 0 8px 10px; margin:0; } /** CODE **/ #container .code { width: 100%; border: 1px solid #555; padding: 0; margin: 20px 0; } #container .code pre.prettyprint { margin:0; overflow: auto; } #container .codeTitle { color: #aaa; background-color: #111; padding: 8px; font-size:18px; border-bottom: 1px solid #555; } #container code, #scroller code { color: black; font-size: 16px; } #container .blackBG code, #container .darkBG code { /* carl removed color: #ccc; */ } #container pre { font-size: 1.1em; padding:8px; background-color:#333; color:white; border: 1px solid #777; } /** TOSS **/ #container .box { background-color: #91e600; text-align: center; font-family: Asap, Avenir, Arial, sans-serif; width: 196px; height: 100px; line-height: 100px; overflow: hidden; color: black; position: absolute; top:0; -webkit-border-radius: 10px; -moz-border-radius: 10px; border-radius: 10px; } /** BUTTONS **/ #container .button { display:inline-block; border-radius:8px; border-bottom-width: 2px; box-shadow: inset 0px 1px 0px rgba(255,255,255,0.6), 0px 3px 6px 0px rgba(0, 0, 0, 0.6); cursor:pointer; text-align: center; font-family: Signika Negative, Asap, Avenir, Arial, sans-serif; position:relative; margin: 4px; color:black; } #container .largeButton { padding: 12px 24px; font-size: 20px; margin: 12px 8px; min-width:110px; } .greenGradient { border: 1px solid #6d9a22; background-color: #699a18; background: linear-gradient(to bottom, #8cce1e 0%,#699a18 52%,#639314 53%,#76b016 100%); /* W3C */ text-shadow: 1px 1px 2px #384d16; color:#fff; text-decoration: none; } /** EXPANDABLE POINTS (FAQ) **/ .expPoint, .expList li { list-style: none; line-height: normal; margin: 0 0 0 8px; padding: 6px 4px 4px 24px; position:relative; border: 1px solid rgba(204,204,204,0); font-size: 110%; color: #111; font-weight: normal; } .expPoint, .expContent { font-family: Signika Negative, Asap, sans-serif; font-weight: 300; line-height: 140%; } .expPoint:hover, .expList li:hover { background-color:white; border: 1px solid rgb(216,216,216); } .expContent { height: 0; overflow: hidden; color: #444; margin: 2px 0 0 0; padding-top: 0; font-size:16px; } .expMore { color: #71b200; text-decoration: underline; font-size:0.8em; } .arrow-right { width: 0; height: 0; border-top: 5px solid transparent; border-bottom: 5px solid transparent; border-left: 6px solid #999; display:inline-block; margin: -4px 8px 0 -14px; vertical-align: middle; opacity:0.8; } .tableCellDesktop { display: table-cell; } .tableCellDesktop img { left: 120px; } @media screen and (max-width: 860px) { .tableCellDesktop { display: block; } .tableCellDesktop img { left: 0px; } } Features Touch enabled - works great on tablets, phones, and desktop browsers. Incredibly smooth - GPU-accelerated and requestAnimationFrame-driven for ultimate performance. Compared to other options out there, Draggable just feels far more natural and fluid, particularly when imposing bounds and momentum. Momentum-based animation - if you have InertiaPlugin loaded, you can simply set inertia: true in the config object and it'll automatically apply natural, momentum-based movement after the mouse/touch is released, causing the object to glide gracefully to a stop. You can even control the amount of resistance, maximum or minimum duration, etc. Complex snapping made easy - snap to points within a certain radius (see example), or feed in an array of values and it'll select the closest one, or implement your own custom logic in a function. Ultimate flexibility. You can have things live-snap (while dragging) or only on release (even with momentum applied, thanks to InertiaPlugin)! Impose bounds - tell a draggable element to stay within the bounds of another DOM element (a container) as in bounds:"#container" or define bounds as coordinates like bounds:{top:100, left:0, width:1000, height:800} or specific maximum/minimum values like bounds:{minRotation:0, maxRotation:270}. Sense overlaps with hitTest() - see if one element is overlapping another and even set a tolerance threshold (like at least 20 pixels or 25% of either element's total surface area) using the super-flexible Draggable.hitTest() method. Feed it a mouse event and it'll tell you if the mouse is over the element. See http://codepen.io/GreenSock/pen/GFBvn for a simple example. Define a trigger element - maybe you want only a certain area to trigger the dragging (like the top bar of a window) - it's as simple as trigger:"#topBar", for example. Drag position, rotation, or scroll - lots of drag types to choose from: "x,y" | "top,left" | "rotation" | "scroll" | "x" | "y" | "top" | "left" | "scrollTop" | "scrollLeft" Lock movement along a certain axis - set lockAxis:true and Draggable will watch the direction the user starts to drag and then restrict it to that axis. Or if you only want to allow vertical or horizontal movement, that's easy too using the type ("top", "y" or "scrollTop" only allow vertical movement; "x", "left", or "scrollLeft" only allow horizontal movement). Rotation honors transform origin - by default, spinnable elements will rotate around their center, but you can set transformOrigin to something else to make the pivot point be elsewhere. For example, if you call gsap.set(yourElement, {transformOrigin:"top left"}) before dragging, it will rotate around its top left corner. Or use % or px. Whatever is set in the element's css will be honored. Rich callback system and event dispatching - you can use any of the following callbacks: onPress, onDragStart, onDrag, onDragEnd, onRelease,, onLockAxis, and onClick. Inside the callbacks, "this" refers to the Draggable instance itself, so you can easily access its "target" or bounds, etc. If you prefer event listeners instead, Draggable dispatches events too so you can do things likeyourDraggable.addEventListener("dragend", yourFunc); Works great with SVG Even works in transformed containers! Got a Draggable inside a rotated/scaled container? No problem. No other tool handles this properly that we've seen. Auto-scrolling, even in multiple containers - set autoScroll:1 for normal-speed auto scrolling, or autoScroll:2 would scroll twice as fast, etc. The closer you move toward the edge, the faster scrolling gets. See a demo here (added in version 0.12.0) Sense clicks when the element moves less than 3 pixels - a common challenge is figuring out when a user is trying to click/tap an object rather than drag it, so if the mouse/touch moves less than 3 pixels from its starting position, it will be interpreted as a "click" and the onClick callback will be called (and a "click" event dispatched) without actually moving the element. You can define a different threshold using minimumMovement config property, like minimumMovement:6 for 6 pixels. All major browsers are supported including IE9+. IE8 lacks hitTest() support. Demos Draggable Showcase Draggable How-To Demos See full documentation here. To get InertiaPlugin (for the momentum-based features), join Club GreenSock today. You'll be glad you did. If not, we'll gladly issue a full refund. To learn how to include Draggable and InertiaPlugin into your project, see the GSAP install docs.

CSS animations and WAAPI offer cubic-bezier() which is great but with only two control points it's impossible to create more complex effects like bouncing, elastic, wiggles, rough/jerky eases, etc. Plus you can't make an ease return to its starting values (like a ball jumping into the air and falling back to the ground with a bounce). Features Unlimited anchors and control points. Copy/Paste any SVG <path> (including directly from Adobe Illustrator). Use CSS cubic-bezier() values (For example, from cubic-bezier.com). Editor has snapping, undo, sample code and other conveniences. Start with any standard ease and customize it. getSVGData() method turns any ease into SVG <path> data for display at the size you define. Extremely optimized for runtime performance. Free for anyone with a GreenSock account. Reading Ease Curves, Editing, and Using CustomEase Here's an in-depth video tour that'll get you up to speed with exactly how to use CustomEase (note that the video is using GSAP 2 format): Ready to play? Check out the new Ease Visualizer with CustomEase support. Edit the curve as much as you want: Download CustomEase Get CustomEase by creating a FREE GreenSock account which gets you access to our community forums plus you’ll receive our exclusive “GreenSock Insider” email series (you can unsubscribe anytime). Make sure you're logged in, then you’ll get immediately gain access to the download zip containing CustomEase. Note: CustomEase is not in the GitHub repository or CDN; it's only available for download at GreenSock.com. Download GSAP (ZIP) Demos CustomEase Demos