This seems like a good time to plug our very own little :nth Tester tool. It definitely helps me understand what something like (2n+1) means in English. You can type in any string you like and see what effect that has on your site:
Anyway, back to Eric’s post. As he mentions, his technique is pseudo-random in that it looks like a random image on the page but it technically isn’t. Either way, I think it’s a really lovely technique! And it certainly breaks up the visual monotony that happens when you’re looking at a website for too long.
Here’s what it looks like in practice:
Lovely stuff!
Another way to do this is to use random numbers in CSS. For example, we could set a variable in JavaScript and then apply it with CSS custom properties. Or we could put all the images in a single sprite file and change the background-position based on a random number.
This is definitely one of those things in CSS where there are no wrong answers; just different ways to do the same awesome thing!
Here’s one simple, practical way to make apps perform better on mobile devices: always configure HTML input fields with the correct type, inputmode, and autocomplete attributes. While these three attributes are often discussed in isolation, they make the most sense in the context of mobile user experience when you think of them as a team.
There’s no question that forms on mobile devices can be time-consuming and tedious to fill in, but by properly configuring inputs, we can ensure that the data entry process is as seamless as possible for our users. Let’s take a look at some examples and best practices we can use to create better user experiences on mobile devices.
Use this demo to experiment on your own, if you’d like.
Using the correct input type
This is the easiest thing to get right. Input types, like email, tel, and url, are well-supported across browsers. While the benefit of using a type, like tel over the more generic text, might be hard to see on desktop browsers, it’s immediately apparent on mobile.
Choosing the appropriate type changes the keyboard that pops up on Android and iOS devices when a user focuses the field. For very little effort, just by using the right type, we will show custom keyboards for email, telephone numbers, URLs, and even search inputs.
Text input type on iOS (left) and Android (right)Email input type on iOS (left) and Android (right)URL input type on iOS (left) and Android (right)Search input type on iOS (left) and Android (right)
One thing to note is that both input type="email" and input type="url" come with validation functionality, and modern browsers will show an error tooltip if their values do not match the expected formats when the user submits the form. If you’d rather turn this functionality off, you can simply add the novalidate attribute to the containing form.
A quick detour into date types
HTML inputs comprise far more than specialized text inputs — you also have radio buttons, checkboxes, and so on. For the purposes of this discussion, though, I’m mostly talking about the more text-based inputs.
There is a type of input that sits in the liminal space between the more free-form text inputs and input widgets like radio buttons: date. The date input type comes in a variety of flavors that are well-supported on mobile, including date, time, datetime-local, and month. These pop up custom widgets in iOS and Android when they are focused. Instead of triggering a specialized keyboard, they show a select-like interface in iOS, and various different types of widgets on Android (where the date and time selectors are particularly slick).
I was excited to start using native defaults on mobile, until I looked around and realized that most major apps and mobile websites use custom date pickers rather than native date input types. There could be a couple reasons for this. First, I find the native iOS date selector to be less intuitive than a calendar-type widget. Second, even the beautifully-designed Android implementation is fairly limited compared to custom components — there’s no easy way to input a date range rather than a single date, for instance.
Still, the date input types are worth checking out if the custom datepicker you’re using doesn’t perform well on mobile. If you’d like to try out the native input widgets on iOS and Android while making sure that desktop users see a custom widget instead of the default dropdown, this snippet of CSS will hide the calendar dropdown for desktop browsers that implement it:
Date input type on iOS (left) and Android (right)Time input type on iOS (left) and Android (right)
One final thing to note is that date types cannot be overridden by the inputmode attribute, which we’ll discuss next.
Why should I care about inputmode?
The inputmode attribute allows you to override the mobile keyboard specified by the input’s type and directly declare the type of keyboard shown to the user. When I first learned about this attribute, I wasn’t impressed — why not just use the correct type in the first place? But while inputmode is often unnecessary, there are a few places where the attribute can be extremely helpful. The most notable use case that I’ve found for inputmode is building a better number input.
While some HTML5 input types, like url and email, are straightforward, input type="number" is a different matter. It has some accessibility concerns as well as a somewhat awkward UI. For example, desktop browsers, like Chrome, show tiny increment arrows that are easy to trigger accidentally by scrolling.
So here’s a pattern to memorize and use going forwards. For most numeric inputs, instead of using this:
<input type="number" />
…you actually want to use this:
<input type="text" inputmode="decimal" />
Why not inputmode="numeric" instead of inputmode="decimal" ?
The numeric and decimal attribute values produce identical keyboards on Android. On iOS, however, numeric displays a keyboard that shows both numbers and punctuation, while decimal shows a focused grid of numbers that almost looks exactly like the tel input type, only without extraneous telephone-number focused options. That’s why it’s my preference for most types of number inputs.
iOS numeric input (left) and decimal input (right)Android numeric input (left) and decimal input (right)
Christian Oliff has written an excellent article dedicated solely to the inputmode attribute.
Don’t forget autocomplete
Even more important than showing the correct mobile keyboard is showing helpful autocomplete suggestions. That can go a long way towards creating a faster and less frustrating user experience on mobile.
While browsers have heuristics for showing autocomplete fields, you cannot rely on them, and should still be sure to add the correct autocomplete attribute. For instance, in iOS Safari, I found that an input type="tel" would only show autocomplete options if I explicitly added a autocomplete="tel" attribute.
You may think that you are familiar with the basic autocomplete options, such as those that help the user fill in credit card numbers or address form fields, but I’d urge you to review them to make sure that you are aware of all of the options. The spec lists over 50 values! Did you know that autocomplete="one-time-code" can make a phone verification user flow super smooth?
Speaking of autocomplete…
I’d like to mention one final element that allows you to create your own custom autocomplete functionality: datalist. While it creates a serviceable — if somewhat basic — autocomplete experience on desktop Chrome and Safari, it shines on iOS by surfacing suggestions in a convenient row right above the keyboard, where the system autocomplete functionality usually lives. Further, it allows the user to toggle between text and select-style inputs.
On Android, on the other hand, datalist creates a more typical autocomplete dropdown, with the area above the keyboard reserved for the system’s own typeahead functionality. One possible advantage to this style is that the dropdown list is easily scrollable, creating immediate access to all possible options as soon as the field is focused. (In iOS, in order to view more than the top three matches, the user would have to trigger the select picker by pressing the down arrow icon.)
You can use this demo to play around with datalist:
CodePen Embed Fallback
And you can explore all the autocomplete options, as well as input type and inputmode values, using this tool I made to help you quickly preview various input configurations on mobile.
In summary
When I’m building a form, I’m often tempted to focus on perfecting the desktop experience while treating the mobile web as an afterthought. But while it does take a little extra work to ensure forms work well on mobile, it doesn’t have to be too difficult. Hopefully, this article has shown that with a few easy steps, you can make forms much more convenient for your users on mobile devices.
It’s incredibly sad that Christopher Schmitt passed away last week¹. I keep thinking about how Christopher was one of the best dudes I knew. Just incredibly kind and thoughtful all the way through. I know everyone says that about people after they pass, but I really mean it here. I’m sure we all know people that we like quite a bit, but hey, we know they can be an asshole sometimes too. Not Christopher, at least not to me. He was always good to me in ways I’ll never be able to reciprocate.
Here’s the most important thing:
We (a group of developer friends) would like to build a site of memories that people have of Christopher. We have our own, but we’d like to collect as many memories from as many people as possible to make this a true memorial to him. If you have one you would like to share publicly, please submit it to this little site just for that.
I hardly know where to start reminiscing about Christopher. Broadly: I spoke at more conferences thrown by Christopher (and Ari) than anyone else. At least a dozen. He used to throw one called In Control in Orlando that I spoke at a number of times and met some early web friends that I’m still close with today! Stephanie Rewis mentioned to me that’s where we met the first time and she remembers me coding away on a yet-to-be released CodePen while there. In Control went to Hawaii one year, along with the first-ever CSS Dev Conf, bringing me to Hawaii for the first time in my life, where I remember driving around the island with Daniel Burka. CSS Dev Conf went all sorts of amazing places, and I went to all of them! Estes Park, New Orleans, The Queen Mary… all these incredible locations that were all incredible memories for me.
And all I have are blurry, distant photos of him like this:
Christopher and Ari also ran an absolute ton of online conferences. CSS Summit, RWD Summit, SVG Summit… they ran a ton of them and they were really ahead of their time. I remember a funny moment where I had just moved to a new city and my internet wasn’t installed yet, but I still had to present online at one of these, so I did it out of my neighbors garage (as their kids slept), and the light in the garage kept going out because it didn’t detect movement. 😬
The people I met through Christopher are too many to count. He was a great connector in that way. His influence on the web was tremendous through his direct work, like writing (what, a dozen books?), blogging (even here!), speaking, and podcasting (e.g. The Non Breaking Space Show) but when you consider the people he brought together, his influence is immeasurable.
I literally made money off the guy. In the early years of ShopTalk, when it was tough to sell podcast spots at all, Christopher would sponsor every episode of ShopTalk, which probably gave us the boost that ensured it’s still happening today. Who knows what would have happened without that.
One of the things I liked best about Christopher is that he was a damn nerd. Through and through. In a way that made you envious that you could one day hope to up your nerd level that high. Guy had a Chewbacca costume that he wore regularly. His Instagram is full of snaps of him meeting other famous nerds.
I hope you still got those black Converses on wherever you are, buddy.
(And remember, if you have a memory with Christopher, please share it.)
It wasn’t COVID-19. Poor guy was dealt bad cards from day one for his health and he fought it the the best he could.
Foldable phones are starting to be a thing. Early days, for sure, but some are already shipping, and they definitely have web browsers on them. Stands to reason that, as web designers, we are going to want to know where that fold is so we can design screens that fit onto the top half and bottom half… or left half and right half¹.
Looks like that’s going to make its way to us in the form of env() constants, just like all that notch stuff.
Interesting how there is no fold-right, isn’t it? And aren’t we trying to stay away from directional terms like that and use logical properties? Why not fold-inline-start?
It’ll be interesting to see how that sentence ages. Just watch the first really popular foldable phone will have three segments.
I would normally be a #2 kinda guy — slice off the top and bottom a bit, make sure there is ample padding, and call it a day. But Nils almost has me convinced this fancy math is better.
Chase McCoy wrote a nifty post about the “gap problem” when making a grid of items. His argument might be summarized like this: how should we space elements with margins in CSS? He notes that the gap property isn’t quite ready for prime time when it comes to using it with flexbox, like this:
.grid {
display: flex;
gap: 10px;
}
Right now, using gap with flexbox is only supported in Firefox and I’ve already caught myself forgetting about that in a few projects. So watch out for that.
Make a grid with a 10px gap between each column and row.
Each column should have a minimum width (150px).
Each column should also be equal width (1fr).
The grid should auto-fill as many columns that can fit.
The nifty thing about all this is that our grid is now effectively responsive because of minmax — if you resize the browser, then the grid will snap down into fewer columns, just like this:
No media queries at all! Although sure, there’s a few other ways that you could get this to work but I think this is neat not just because we’re avoiding media queries — instead, it’s because it teaches us to think in a new way when designing and building components.
Chase continues:
With this technique, instead of using breakpoints to specify the screen size where your items should stack, you specify the minimum size an element should be before it stacks. I like this because it encourages developers to think about responsive design in terms of behaviors instead of screen sizes.
“Behaviors instead of screen sizes” is such a great way to think about component design! A lot of the problems I’ve encountered when making components for a design system is when I’ve been thinking about screen sizes — mobile, tablet, desktop, etc. — and trying to make those components fit within those constraints.
Thinking in behaviors is always more effective because there are so many things that can impact a component beyond what screen or device width we’re working with. Perhaps we want that component to fit inside another component. Or we want to align some helper text to the side of it for comparison.
Either way, thinking about behaviors instead of screen sizes isn’t really going to be fully impossible until we have container queries, as Chris writes:
Container queries are always on the top of the list of requested improvements to CSS. The general sentiment is that if we had container queries, we wouldn’t write as many global media queries based on page size. That’s because we’re actually trying to control a more scoped container, and the only reason we use media queries for that now is because it’s the best tool we have in CSS. I absolutely believe that.
Chase McCoy wrote a nifty post about the “gap problem” when making a grid of items. His argument might be summarized like this: how should we space elements with margins in CSS? He notes that the gap property isn’t quite ready for prime time when it comes to using it with flexbox, like this:
.grid {
display: flex;
gap: 10px;
}
Right now, using gap with flexbox is only supported in Firefox and I’ve already caught myself forgetting about that in a few projects. So watch out for that.
Make a grid with a 10px gap between each column and row.
Each column should have a minimum width (150px).
Each column should also be equal width (1fr).
The grid should auto-fill as many columns that can fit.
The nifty thing about all this is that our grid is now effectively responsive because of minmax — if you resize the browser, then the grid will snap down into fewer columns, just like this:
No media queries at all! Although sure, there’s a few other ways that you could get this to work but I think this is neat not just because we’re avoiding media queries — instead, it’s because it teaches us to think in a new way when designing and building components.
Chase continues:
With this technique, instead of using breakpoints to specify the screen size where your items should stack, you specify the minimum size an element should be before it stacks. I like this because it encourages developers to think about responsive design in terms of behaviors instead of screen sizes.
“Behaviors instead of screen sizes” is such a great way to think about component design! A lot of the problems I’ve encountered when making components for a design system is when I’ve been thinking about screen sizes — mobile, tablet, desktop, etc. — and trying to make those components fit within those constraints.
Thinking in behaviors is always more effective because there are so many things that can impact a component beyond what screen or device width we’re working with. Perhaps we want that component to fit inside another component. Or we want to align some helper text to the side of it for comparison.
Either way, thinking about behaviors instead of screen sizes isn’t really going to be fully impossible until we have container queries, as Chris writes:
Container queries are always on the top of the list of requested improvements to CSS. The general sentiment is that if we had container queries, we wouldn’t write as many global media queries based on page size. That’s because we’re actually trying to control a more scoped container, and the only reason we use media queries for that now is because it’s the best tool we have in CSS. I absolutely believe that.
I’ve been coding web animations and helping others do the same for years now. However, I have yet to see a concise list of tips focused on how to efficiently build animations, so here you go!
I will be using the GreenSock Animation Platform (GSAP). It provides a simple, readable API and solves cross-browser inconsistencies so that you can focus on animating. The code and concepts should be understandable even if you’ve never used GSAP. If you’d like to familiarize yourself with the basics of GSAP first so that you can get the most out of this article, the best place to begin is GSAP’s getting started page (includes a video).
Tip #1: Use an animation library
Some developers think that using an animation library is wasteful because they can just use native browser technologies like CSS transitions, CSS animations or the Web Animations API (WAAPI) to accomplish the same thing without loading a library. In some cases, that’s true. However, here are a few other factors to consider:
Browser bugs, inconsistencies, and compatibility: An animation library, like GSAP, solves these for you and is universally compatible. You can even use motion paths in IE9! There are many problematic areas when it comes to cross-browser issues, including handling transform-origin on SVG elements, path stroke measurements, 3D origins in Safari, and many more that we don’t have the space to list.
Animation workflow: Building even moderately complex animations is much faster and more fun with a tool like GSAP. You can modularize animations, nest them as deeply as you want, and have their timing adjusted automatically. This makes it so much easier to experiment. Trust me: once you try building an animation sequence in CSS and then in GSAP, you’ll see what I mean. Night and day! Future edits are faster too.
Animate beyond the DOM: Canvas, WebGL, generic objects, and complex strings can’t be animated with native technologies. Using one consistent tool for all your animations is much cleaner.
Runtime control: Using a good animation library can enable you to pause, resume, reverse, seek through, or even gradually change the speed of an entire animation sequence. You can control each transform component independently (rotation, scale, x, y, skew, etc.). You can also retrieve those values at any time as well. JavaScript animations give you ultimate flexibility.
Easing options (bounce, elastic, etc.): CSS only gives you two control points for eases. GSAP’s CustomEase lets you literally create any ease you can imagine.
Lag smoothing: GSAP can prioritize absolute timing or adjust things on the fly to avoid jumps if the CPU gets bogged down.
Advanced capabilities: Using GSAP, it’s easy to morph SVGs, add physics/inertia, edit motion paths directly in the browser, use position-aware staggers, and more.
Most of the top animators in the industry use a tool like GSAP because they’ve learned these same things over the years. Once you get beyond very basic animations, a JavaScript library will make your life much, much easier and open up entirely new possibilities.
Tip #2: Use timelines
A good animation library will provide some way of creating individual animations (called tweens) and a way to sequence animations in a timeline. Think of a timeline like a container for your tweens where you position them in relation to one another.
By default in GSAP, tweens added to a timeline will wait for the previous tweens to complete before running. The +=0.5 adds an additional offset or delay of a half-second as well, so the second tween will start 0.5 seconds after the first tween finishes no matter how long the first tween’s duration is.
To increase the amount of time between the tween to 1 second, all you need to do is change the +=0.5 to +=1! Super easy. With this approach, you can iterate on your animations quickly without worrying about doing the math to combine previous durations.
Tip #3: Use relative values
By “relative values” I mean three things:
Animate values relative to their current value. GSAP recognizes += and -= prefixes for this. So x: "+=200" will add 200 units (usually pixels) to the current x. And x: "-=200" will subtract 200 from the current value. This is also useful in GSAP’s position parameter when positioning tweens relative to one another.
Use relative units (like vw, vh and, in some cases, %) when values need to be responsive to viewport size changes.
Use methods like .to() and .from() (instead of .fromTo()) whenever possible so that the start or end values are dynamically populated from their current values. That way, you don’t need to declare start and end values in every tween. Yay, less typing! For example, if you had a bunch of differently-colored elements, you could animate them all to black like gsap.to(".class", {backgroundColor: "black" }).
Tip #4: Use keyframes
If you find yourself animating the same target over and over in a row, that’s a perfect time to use keyframes! You do so like this:
No timeline necessary! To space out the tweens we just use the delay property in each keyframe. (It can be negative to create overlaps.)
Tip #5: Use smart defaults
GSAP has default values for properties like ease ("power1.out") and duration (0.5 seconds). So, the following is a valid tween that will animate for half a second.
gsap.to(".box", { color: "black" })
To change GSAP’s global defaults, use gsap.defaults():
// Use a linear ease and a duration of 1 instead
gsap.defaults({ ease: "none", duration: 1 });
This can be handy, but it’s more common to set defaults for a particular timeline so that it affects only its children. For example, we can avoid typing duration: 1 for each of the sub-tweens by setting a default on the parent timeline:
We mentioned this briefly in the third tip, but it deserves its own tip.
If you have multiple elements that share the same class of .box, the code above will animate all of the elements at the same time!
You can also select multiple elements with different selectors by using a more complex selector string:
gsap.to(".box, .circle", { ... });
Or you can pass an array of variable references as long as the elements are of the same type (selector string, variable reference, generic object, etc.):
var box = document.querySelector(".box");
var circle = document.querySelector(".circle");
// some time later…
gsap.to([box, circle], { ... });
Tip #7: Use function-based values, staggers, and/or loops
Function-based values
Use a function instead of a number/string for almost any property, and GSAP will call that function once for each target when it first renders the tween. Plus, it’ll use whatever gets returned by the function as the property value! This can be really handy for creating a bunch of different animations using a single tween and for adding variance.
GSAP will pass the following parameters into the function:
The index
The specific element being affected
An array of all of the elements affected by the tween
For example, you could set the movement direction based on the index:
Or you could choose items from an array:
Staggers
Make your animations look more dynamic and interesting by offsetting the start times with a stagger. For simple staggered offsets in a single tween, just use stagger: 0.2 to add 0.2 seconds between the start time of each animation.
You can also pass in an object to get more complex stagger effects, including ones that emanate outward from the center of a grid or randomize the timings:
It can be helpful to loop through a list of elements to create or apply animations, particularly when they are based on some event, like a user’s interaction (which I’ll discuss later on).
To loop through a list of items, it’s easiest to use .forEach(). But since this isn’t supported on elements selected with .querySelectorAll() in IE, you can use GSAP’s utils.toArray() function instead.
In the example below, we are looping through each container to add animations to its children that are scoped to that container.
Tip #8: Modularize your animations
Modularization is one of the key principles of programming. It allows you to build small, easy-to-understand chunks that you can combine into larger creations while still keeping things clean, reusable, and easy to modify. It also lets you to use parameters and function scope, increasing the re-usability of your code.
Functions
Use functions to return tweens or timelines and then insert those into a master timeline:
function doAnimation() {
// do something, like calculations, maybe using arguments passed into the function
// return a tween, maybe using the calculations above
return gsap.to(".myElem", { duration: 1, color: "red"});
}
tl.add( doAnimation() );
Nesting timelines can truly revolutionize the way you animate. It lets you sequence really complex animations with ease while keeping your code modular and readable.
function doAnimation() {
const tl = gsap.timeline();
tl.to(...);
tl.to(...);
// ...as many animations as you’d like!
// When you’re all done, return the timeline
return tl;
}
const master = gsap.timeline();
master.add( doAnimation() );
master.add( doAnotherAnimation() );
// Add even more timelines!
Here’s a more complex demo showing the same technique using a Star Wars theme by Craig Roblewsky:
CodePen Embed Fallback
Wrapping your animation-building routines inside functions also makes recreating animations (say, on resize) a breeze!
var tl; // keep an accessible reference to our timeline
function buildAnimation() {
var time = tl ? tl.time() : 0; // save the old time if it exists
// kill off the old timeline if it exists
if (tl) {
tl.kill();
}
// create a new timeline
tl = gsap.timeline();
tl.to(...)
.to(...); // do your animation
tl.time(time); // set the playhead to match where it was
}
buildAnimation(); //kick things off
window.addEventListener("resize", buildAnimation); // handle resize
Effects
With effects, you can turn a custom animation into a named effect that can be called anytime with new targets and configurations. This is especially helpful when you have standards for your animations or if you are going to be calling the same animation from different contexts.
Here’s a super-simple “fade” effect to show the concept:
// register the effect with GSAP:
gsap.registerEffect({
name: "fade",
defaults: {duration: 2}, //defaults get applied to the "config" object passed to the effect below
effect: (targets, config) => {
return gsap.to(targets, {duration: config.duration, opacity:0});
}
});
// now we can use it like this:
gsap.effects.fade(".box");
// Or override the defaults:
gsap.effects.fade(".box", {duration: 1});
Tip #9: Use control methods
GSAP provides many methods to control the state of a tween or timeline. They include .play(), .pause(), .reverse(), .progress(), .seek(), .restart(), .timeScale(), and several others.
Using control methods can make transitions between animations more fluid (such as being able to reverse part way through) and more performant (by reusing the same tween/timeline instead of creating new instances each time). And by giving you finer control over the state of the animation, it can help with debugging as well.
Here’s a simple example:
One amazing use case is tweening the timeScale of a timeline!
CodePen Embed Fallback
Use case: interaction events that trigger animations
Inside of event listeners for user interaction events, we can use control methods to have fine control over our animation’s play state.
In the example below, we are creating a timeline for each element (so that it doesn’t fire the same animation on all instances), attaching a reference for that timeline to the element itself, and then playing the relevant timeline when the element is hovered, reversing it when the mouse leaves.
CodePen Embed Fallback
Use case: Animating between multiple states of a timeline
You may want a set of animations to affect the same properties of the same elements, but only in certain sequences (e.g. active/inactive states, each with mouseover/mouseout states). It may get tricky to manage. We can simplify it by using states of a timeline and control events.
Use case: Animating based on the scroll position
We can easily fire animations based on the scroll position by using control methods. For example, this demo plays a full animation once a scroll position has been reached:
You can also attach the progress of an animation to the scroll position for more fancy scroll effects!
But if you’re going to do this, it’s best to throttle the scroll listener for performance reasons:
Hot tip: GreenSock is working on a plugin to make scroll-based animations even easier! You’re in for quite a treat. Keep your eyes peeled for news.
Bonus tip: Use GSAP’s plugins, utility methods, and helper functions
GSAP plugins add extra capabilities to GSAP’s core. Some plugins make it easier to work with rendering libraries, like PixiJS or EaselJS, while other plugins add superpowers like morphing SVG, drag and drop functionality, etc. This keeps the GSAP core relatively small and lets you add features when you need them.
Plugins
MorphSVG morphs between any two SVG shapes, no matter the number of points, and gives you fine control over how the shapes are morphed.
CodePen Embed Fallback
DrawSVG progressively reveals (or hides) the stroke of an SVG element, making it look like it’s being drawn. It works around various browser bugs that affect typical stroke-dashoffset animations.
MotionPath animates anything (SVG, DOM, canvas, generic objects, whatever) along a motion path in any browser. You can even edit the path in-browser using MotionPathHelper!
CodePen Embed Fallback
GSDevTools gives you a visual UI for interacting with and debugging GSAP animations, complete with advanced playback controls, keyboard shortcuts, global synchronization and more.
CodePen Embed Fallback
Draggable provides a surprisingly simple way to make virtually any DOM element draggable, spinnable, tossable, or even flick-scrollable using mouse or touch events. Draggable integrates beautifully (and optionally) with InertiaPlugin so the user can flick and have the motion decelerate smoothly based on momentum.
CodePen Embed Fallback
CustomEase (along with CustomBounce and CustomWiggle) add to GSAP’s already extensive easing capabilities by enabling you to register any ease that you’d like.
SplitText is an easy to use JavaScript utility that allows you to split HTML text into characters, words and lines. It’s easy to use, extremely flexible, works all the way back to IE9, and handles special characters for you.
CodePen Embed Fallback
ScrambleText scrambles the text in a DOM element with randomized characters, refreshing new randomized characters at regular intervals, while gradually revealing your new text (or the original) over the course of the tween. Visually, it looks like a computer decoding a string of text.
CodePen Embed Fallback
Physics2D lets you tween the position of elements based on velocity and acceleration as opposed to going to specific values. PhysicsProps is similar but works with any property, not just 2D coordinates.
CodePen Embed Fallback
Utility methods
GSAP has built-in utility methods that can make some common tasks easier. Most are focused on manipulating values in a particular way, which can be especially helpful when generating or modifying animation values. The ones that I use most often are .wrap(), .random, .interpolate(), .distribute(), .pipe(), and .unitize(), but there are many others you might find helpful.
Helper functions
In a similar light, but not built into GSAP’s core, are some helper functions GreenSock has created over the years to deal with specific use cases. These functions make it easy to FLIP your animations, return a random number based on an ease curve, blend two ease curves, and much more. I highly recommend checking them out!
Conclusion
You’ve made it to the end! Hopefully, you’ve learned a thing or two along the way and this article will continue to be a resource for you in the years to come.
As always, if you have any questions about GSAP, feel free to drop by the GreenSock forums. They’re incredibly helpful and welcoming! As an employee of GreenSock, that’s where I hang out often; I love helping people with animation-related challenges!
I’ve been coding web animations and helping others do the same for years now. However, I have yet to see a concise list of tips focused on how to efficiently build animations, so here you go!
I will be using the GreenSock Animation Platform (GSAP). It provides a simple, readable API and solves cross-browser inconsistencies so that you can focus on animating. The code and concepts should be understandable even if you’ve never used GSAP. If you’d like to familiarize yourself with the basics of GSAP first so that you can get the most out of this article, the best place to begin is GSAP’s getting started page (includes a video).
Tip #1: Use an animation library
Some developers think that using an animation library is wasteful because they can just use native browser technologies like CSS transitions, CSS animations or the Web Animations API (WAAPI) to accomplish the same thing without loading a library. In some cases, that’s true. However, here are a few other factors to consider:
Browser bugs, inconsistencies, and compatibility: An animation library, like GSAP, solves these for you and is universally compatible. You can even use motion paths in IE9! There are many problematic areas when it comes to cross-browser issues, including handling transform-origin on SVG elements, path stroke measurements, 3D origins in Safari, and many more that we don’t have the space to list.
Animation workflow: Building even moderately complex animations is much faster and more fun with a tool like GSAP. You can modularize animations, nest them as deeply as you want, and have their timing adjusted automatically. This makes it so much easier to experiment. Trust me: once you try building an animation sequence in CSS and then in GSAP, you’ll see what I mean. Night and day! Future edits are faster too.
Animate beyond the DOM: Canvas, WebGL, generic objects, and complex strings can’t be animated with native technologies. Using one consistent tool for all your animations is much cleaner.
Runtime control: Using a good animation library can enable you to pause, resume, reverse, seek through, or even gradually change the speed of an entire animation sequence. You can control each transform component independently (rotation, scale, x, y, skew, etc.). You can also retrieve those values at any time as well. JavaScript animations give you ultimate flexibility.
Easing options (bounce, elastic, etc.): CSS only gives you two control points for eases. GSAP’s CustomEase lets you literally create any ease you can imagine.
Lag smoothing: GSAP can prioritize absolute timing or adjust things on the fly to avoid jumps if the CPU gets bogged down.
Advanced capabilities: Using GSAP, it’s easy to morph SVGs, add physics/inertia, edit motion paths directly in the browser, use position-aware staggers, and more.
Most of the top animators in the industry use a tool like GSAP because they’ve learned these same things over the years. Once you get beyond very basic animations, a JavaScript library will make your life much, much easier and open up entirely new possibilities.
Tip #2: Use timelines
A good animation library will provide some way of creating individual animations (called tweens) and a way to sequence animations in a timeline. Think of a timeline like a container for your tweens where you position them in relation to one another.
By default in GSAP, tweens added to a timeline will wait for the previous tweens to complete before running. The +=0.5 adds an additional offset or delay of a half-second as well, so the second tween will start 0.5 seconds after the first tween finishes no matter how long the first tween’s duration is.
To increase the amount of time between the tween to 1 second, all you need to do is change the +=0.5 to +=1! Super easy. With this approach, you can iterate on your animations quickly without worrying about doing the math to combine previous durations.
Tip #3: Use relative values
By “relative values” I mean three things:
Animate values relative to their current value. GSAP recognizes += and -= prefixes for this. So x: "+=200" will add 200 units (usually pixels) to the current x. And x: "-=200" will subtract 200 from the current value. This is also useful in GSAP’s position parameter when positioning tweens relative to one another.
Use relative units (like vw, vh and, in some cases, %) when values need to be responsive to viewport size changes.
Use methods like .to() and .from() (instead of .fromTo()) whenever possible so that the start or end values are dynamically populated from their current values. That way, you don’t need to declare start and end values in every tween. Yay, less typing! For example, if you had a bunch of differently-colored elements, you could animate them all to black like gsap.to(".class", {backgroundColor: "black" }).
Tip #4: Use keyframes
If you find yourself animating the same target over and over in a row, that’s a perfect time to use keyframes! You do so like this:
No timeline necessary! To space out the tweens we just use the delay property in each keyframe. (It can be negative to create overlaps.)
Tip #5: Use smart defaults
GSAP has default values for properties like ease ("power1.out") and duration (0.5 seconds). So, the following is a valid tween that will animate for half a second.
gsap.to(".box", { color: "black" })
To change GSAP’s global defaults, use gsap.defaults():
// Use a linear ease and a duration of 1 instead
gsap.defaults({ ease: "none", duration: 1 });
This can be handy, but it’s more common to set defaults for a particular timeline so that it affects only its children. For example, we can avoid typing duration: 1 for each of the sub-tweens by setting a default on the parent timeline:
We mentioned this briefly in the third tip, but it deserves its own tip.
If you have multiple elements that share the same class of .box, the code above will animate all of the elements at the same time!
You can also select multiple elements with different selectors by using a more complex selector string:
gsap.to(".box, .circle", { ... });
Or you can pass an array of variable references as long as the elements are of the same type (selector string, variable reference, generic object, etc.):
var box = document.querySelector(".box");
var circle = document.querySelector(".circle");
// some time later…
gsap.to([box, circle], { ... });
Tip #7: Use function-based values, staggers, and/or loops
Function-based values
Use a function instead of a number/string for almost any property, and GSAP will call that function once for each target when it first renders the tween. Plus, it’ll use whatever gets returned by the function as the property value! This can be really handy for creating a bunch of different animations using a single tween and for adding variance.
GSAP will pass the following parameters into the function:
The index
The specific element being affected
An array of all of the elements affected by the tween
For example, you could set the movement direction based on the index:
Or you could choose items from an array:
Staggers
Make your animations look more dynamic and interesting by offsetting the start times with a stagger. For simple staggered offsets in a single tween, just use stagger: 0.2 to add 0.2 seconds between the start time of each animation.
You can also pass in an object to get more complex stagger effects, including ones that emanate outward from the center of a grid or randomize the timings:
It can be helpful to loop through a list of elements to create or apply animations, particularly when they are based on some event, like a user’s interaction (which I’ll discuss later on).
To loop through a list of items, it’s easiest to use .forEach(). But since this isn’t supported on elements selected with .querySelectorAll() in IE, you can use GSAP’s utils.toArray() function instead.
In the example below, we are looping through each container to add animations to its children that are scoped to that container.
Tip #8: Modularize your animations
Modularization is one of the key principles of programming. It allows you to build small, easy-to-understand chunks that you can combine into larger creations while still keeping things clean, reusable, and easy to modify. It also lets you to use parameters and function scope, increasing the re-usability of your code.
Functions
Use functions to return tweens or timelines and then insert those into a master timeline:
function doAnimation() {
// do something, like calculations, maybe using arguments passed into the function
// return a tween, maybe using the calculations above
return gsap.to(".myElem", { duration: 1, color: "red"});
}
tl.add( doAnimation() );
Nesting timelines can truly revolutionize the way you animate. It lets you sequence really complex animations with ease while keeping your code modular and readable.
function doAnimation() {
const tl = gsap.timeline();
tl.to(...);
tl.to(...);
// ...as many animations as you’d like!
// When you’re all done, return the timeline
return tl;
}
const master = gsap.timeline();
master.add( doAnimation() );
master.add( doAnotherAnimation() );
// Add even more timelines!
Here’s a more complex demo showing the same technique using a Star Wars theme by Craig Roblewsky:
CodePen Embed Fallback
Wrapping your animation-building routines inside functions also makes recreating animations (say, on resize) a breeze!
var tl; // keep an accessible reference to our timeline
function buildAnimation() {
var time = tl ? tl.time() : 0; // save the old time if it exists
// kill off the old timeline if it exists
if (tl) {
tl.kill();
}
// create a new timeline
tl = gsap.timeline();
tl.to(...)
.to(...); // do your animation
tl.time(time); // set the playhead to match where it was
}
buildAnimation(); //kick things off
window.addEventListener("resize", buildAnimation); // handle resize
Effects
With effects, you can turn a custom animation into a named effect that can be called anytime with new targets and configurations. This is especially helpful when you have standards for your animations or if you are going to be calling the same animation from different contexts.
Here’s a super-simple “fade” effect to show the concept:
// register the effect with GSAP:
gsap.registerEffect({
name: "fade",
defaults: {duration: 2}, //defaults get applied to the "config" object passed to the effect below
effect: (targets, config) => {
return gsap.to(targets, {duration: config.duration, opacity:0});
}
});
// now we can use it like this:
gsap.effects.fade(".box");
// Or override the defaults:
gsap.effects.fade(".box", {duration: 1});
Tip #9: Use control methods
GSAP provides many methods to control the state of a tween or timeline. They include .play(), .pause(), .reverse(), .progress(), .seek(), .restart(), .timeScale(), and several others.
Using control methods can make transitions between animations more fluid (such as being able to reverse part way through) and more performant (by reusing the same tween/timeline instead of creating new instances each time). And by giving you finer control over the state of the animation, it can help with debugging as well.
Here’s a simple example:
One amazing use case is tweening the timeScale of a timeline!
CodePen Embed Fallback
Use case: interaction events that trigger animations
Inside of event listeners for user interaction events, we can use control methods to have fine control over our animation’s play state.
In the example below, we are creating a timeline for each element (so that it doesn’t fire the same animation on all instances), attaching a reference for that timeline to the element itself, and then playing the relevant timeline when the element is hovered, reversing it when the mouse leaves.
CodePen Embed Fallback
Use case: Animating between multiple states of a timeline
You may want a set of animations to affect the same properties of the same elements, but only in certain sequences (e.g. active/inactive states, each with mouseover/mouseout states). It may get tricky to manage. We can simplify it by using states of a timeline and control events.
Use case: Animating based on the scroll position
We can easily fire animations based on the scroll position by using control methods. For example, this demo plays a full animation once a scroll position has been reached:
You can also attach the progress of an animation to the scroll position for more fancy scroll effects!
But if you’re going to do this, it’s best to throttle the scroll listener for performance reasons:
Hot tip: GreenSock is working on a plugin to make scroll-based animations even easier! You’re in for quite a treat. Keep your eyes peeled for news.
Bonus tip: Use GSAP’s plugins, utility methods, and helper functions
GSAP plugins add extra capabilities to GSAP’s core. Some plugins make it easier to work with rendering libraries, like PixiJS or EaselJS, while other plugins add superpowers like morphing SVG, drag and drop functionality, etc. This keeps the GSAP core relatively small and lets you add features when you need them.
Plugins
MorphSVG morphs between any two SVG shapes, no matter the number of points, and gives you fine control over how the shapes are morphed.
CodePen Embed Fallback
DrawSVG progressively reveals (or hides) the stroke of an SVG element, making it look like it’s being drawn. It works around various browser bugs that affect typical stroke-dashoffset animations.
MotionPath animates anything (SVG, DOM, canvas, generic objects, whatever) along a motion path in any browser. You can even edit the path in-browser using MotionPathHelper!
CodePen Embed Fallback
GSDevTools gives you a visual UI for interacting with and debugging GSAP animations, complete with advanced playback controls, keyboard shortcuts, global synchronization and more.
CodePen Embed Fallback
Draggable provides a surprisingly simple way to make virtually any DOM element draggable, spinnable, tossable, or even flick-scrollable using mouse or touch events. Draggable integrates beautifully (and optionally) with InertiaPlugin so the user can flick and have the motion decelerate smoothly based on momentum.
CodePen Embed Fallback
CustomEase (along with CustomBounce and CustomWiggle) add to GSAP’s already extensive easing capabilities by enabling you to register any ease that you’d like.
SplitText is an easy to use JavaScript utility that allows you to split HTML text into characters, words and lines. It’s easy to use, extremely flexible, works all the way back to IE9, and handles special characters for you.
CodePen Embed Fallback
ScrambleText scrambles the text in a DOM element with randomized characters, refreshing new randomized characters at regular intervals, while gradually revealing your new text (or the original) over the course of the tween. Visually, it looks like a computer decoding a string of text.
CodePen Embed Fallback
Physics2D lets you tween the position of elements based on velocity and acceleration as opposed to going to specific values. PhysicsProps is similar but works with any property, not just 2D coordinates.
CodePen Embed Fallback
Utility methods
GSAP has built-in utility methods that can make some common tasks easier. Most are focused on manipulating values in a particular way, which can be especially helpful when generating or modifying animation values. The ones that I use most often are .wrap(), .random, .interpolate(), .distribute(), .pipe(), and .unitize(), but there are many others you might find helpful.
Helper functions
In a similar light, but not built into GSAP’s core, are some helper functions GreenSock has created over the years to deal with specific use cases. These functions make it easy to FLIP your animations, return a random number based on an ease curve, blend two ease curves, and much more. I highly recommend checking them out!
Conclusion
You’ve made it to the end! Hopefully, you’ve learned a thing or two along the way and this article will continue to be a resource for you in the years to come.
As always, if you have any questions about GSAP, feel free to drop by the GreenSock forums. They’re incredibly helpful and welcoming! As an employee of GreenSock, that’s where I hang out often; I love helping people with animation-related challenges!
I just can’t stop bookmarking great links related to typography. I’m afraid I’m going to have to subject you, yet again, to a bunch of them all grouped up. So those of you that care about web type stuff, enjoy.
I know there are lots of good reasons to be excited about variable fonts. The design possibilities of endless variations in one file is chief among them. But I remain the most excited about the performance benefits. Having a single file that elegantly handles the thicker weights (for bolding) and italics is so cool. I can’t wait to wave my fist saying back in my day we had to load multiple files for our font variations!
Even if you consider the slightly larger file sizes, when combined with improved font compression formats like WOFF2, font subsetting and font loading techniques like font-display: swap; we end up in a situation where we can still get smaller overall font file sizes as well as a significant increase in stylistic opportunity.
Anna Monus did some variable font performance testing as well, evaluating the extreme case of loading 12 variations of a font against a variable font. Even though the copy of the variable font she had for Roboto was massive (over 1MB), there was a perf gain compared against loading 12 variations.
Roboto is on Google Fonts, of course, and it’s got the #1 position by far. But Google Fonts has Inter now, and I’d expect that leap up in the charts as it’s got a style that everyone seems to like and can work with just about anything.
Klint Finley on the proliferation of high-quality open-source fonts for WIRED. Sometimes they are backed by companies with thick wallets, which makes sense. But the motivation for doing it varies. Sometimes quality is the goal. Like open-source anything, lots of contributions, can, if handled well, lead to a better product. But open-source doesn’t always mean there isn’t a business possibility, and if not, not everyone cares about turning a profit on everything.
Speaking of open-source fonts, Collletttivo is an open-source font foundry with a good dozen typefaces, including a variable font one. It’s a super fun site to explore with the little fake windows you open up and move around.
There’s a new mac app called FontGoggles for poking into a font file and taking a look at what it offers. Seems like that would be easy but it really isn’t. I like that it supports WOFF/2 as that’s pretty much all we deal with on the web.
Also, remember there is a website that looks around in font files with the best name ever.
Font Match allows you to put fonts on top of each other for comparisons. Seems like it’s more for large type and comparing their features, while Font style matcher is more about comparing paragraph text.
In fact, using Font style matcher to make a perfect font fallback is one of my all-time favorite CSS-Tricks. Sssshh… don’t tell anybody but I’m compiling those all-time favorites into a book, like this chapter. You’d have to subscribe to read it, because that’s kind of the point: I’d like to sell the book. So if you happen to subscribe now, there is stuff to read there, but you’d be a very early supporter for the rest of it.
