Dan Wilson

Individualizing CSS Properties with CSS Variables

Fri, 07 Apr 2017 00:00:00 -0500

In “A Trick: Individual CSS Transform Functions”, I discussed how we could use CSS Variables (Custom Properties) to bring us close to independent transform properties. Each day I explore CSS Variables, however, I’m finding they can help us with any property that accepts multiple values at the same time.

See the Pen Pause Independent Animations with CSS Variables by Dan Wilson (@danwilson) on CodePen.

This example shows a block of text that animates via clip-path to reveal itself over another block of text. I’ve added a second keyframe animation to do a hue-rotate filter to effectively cycle through colors for the background. The animation property therefore has two values: one for each animation. If I want to change anything later for only one animation - such as a duration or play-state, I would likely take one of two approaches (Let’s talk about toggling the animation-play-state from paused to running):

Set up multiple classes to represent all the different combinations of play state we can have (in our case four: running,running; running,paused; paused,running; paused,paused;), and use JavaScript to determine the correct one and toggle the class.
Or: use JavaScript to getComputedStyle on our animating element, tokenize the value based on the comma, set the desired value on the one we want to update, and then join back together for a final result string to be set on the element’s style.animationPlayState.

These approaches have drawbacks, since they both grow more complex as we add more animations. We need nine classes if we have three animations and more complicated JS to get the right class applied. For the second option, we need to add additional logic to our JS any time a new animation is added, and we need to be careful to not change order in our CSS.

Instead, our example shows how we can use CSS Variables to break them apart and think of them more individually. We set up our animation as we normally would but we also set a separate animation-play-state property value, with the default values of running:

main {
  --shape-play-state: running;
  --hue-play-state: running;

  animation: 
    reveal-shape 3000ms 1000ms infinite alternate ease-in-out both,
    hue-adjust 6000ms 0ms infinite alternate ease-in-out;
  animation-play-state: 
    var(--shape-play-state),
    var(--hue-play-state);
}

Now we can add some form controls that allow us to pause an individual animation via a small amount of JS:

var main = document.querySelector('main');
//Get Form controls with an id that syncs with the CSS Variable names
document.getElementById('shape').addEventListener('click', updatePlayState);
document.getElementById('hue').addEventListener('click', updatePlayState);

function updatePlayState(e) {
  var variable = '--' + e.currentTarget.id + '-play-state';
  main.style.setProperty(variable, e.currentTarget.checked ? 'paused' : 'running')
}

This allows us to break out of manipulating full property values when we only need to update a small segment. We could take this further and add controls to everything… for each animation’s durations, direction, iteration count, etc. It’s not just CSS Animations and Transforms that take multiple values/functions in their properties and benefit from this approach.

We can use CSS Variables to switch Hue, Saturation, and Lightness for color: hsl():

See the Pen HSL by Dan Wilson (@danwilson) on CodePen.

We can combine it with “The Original CSS Variable” currentColor and theme a site:

See the Pen Site Theming with input[type=range] by Dan Wilson (@danwilson) on CodePen.

We can even update the individual parts of a cubic-bezier() easing function on the fly:

See the Pen Jump to Where You Press by Dan Wilson (@danwilson) on CodePen.

Multiple backgrounds, box shadows, and more are open to this simplification. Latest Chrome, Firefox, and Safari do well with these examples. Edge 15 (just released) is the first version to have CSS Variables, so I’m just starting to play with this there and… they sometimes work. Impressive for an initial release in my book, and the more common use cases for Variables seem to be working very well. Hopefully we will see improvements in all the browsers as we continue to explore what CSS Variables can do.

A Trick: Individual CSS Transform Functions

Tue, 21 Feb 2017 00:00:00 -0600

We get a lot of power through the single transform property in CSS - allowing us to rotate, translate, scale, and more all at once. But allowing all of those different transform functions into one property can trip us up.

It’s common to want to apply different transforms to different states of our elements. Say we have a button that we always want to be translated -150% vertically. When a user hovers over the button we scale the button down a bit, and on press (the active state) we rotate it 180 degrees. This example shows how one might first think to write the CSS for “My Button” as just described, and then the “Expected” button shows a way to get it as intended.

See the Pen Basics with Transform Functions by Dan Wilson (@danwilson) on CodePen.

With the initial styles on the button we are not just adding the scale on hover… we are overriding the original translate as well, so it scales and transitions back to translateY(0).

Why is this? Linear Algebra. The way these transformations happen depend on each other and their order (such that translate(-50%, -50%) scale(.4) rotate(50deg) is different than rotate(50deg) translate(-50%, -50%) scale(.4)), and they boil down to matrix multiplication. But we usually don’t need to know transforms at that level. Web developers just want to know how they can maintain these transform functions at an individual level.

See the Pen Order of Transform Functions by Dan Wilson (@danwilson) on CodePen.

Chrome has begun implementing individual properties, such that translate, rotate, and scale become first class properties as seen in this previous example (as of this writing requires Chrome Canary). But this has limitations of its own:

The x, y, and z pieces of each are still tied to a single property currently.
The order will always be translate scale rotate when it is converted to matrices.
Early days - just in Chrome Canary.

So what can we do?

Use CSS Variables.

Listening to David Khourshid talk about CSS Variables quickly opened my eyes to a lot of opportunities for animating with them. It wasn’t until I started putting variables everywhere that their power became even clearer. Without further ado… here is the trick to give us more flexibility (with the how/what/why after the example).

See the Pen CSS Variables + Transform = Individual Properties by Dan Wilson (@danwilson) on CodePen.

We set up a key initial transform for our element with all the variables we intend to change. By modifying the variable value on the different states we can get a CSS rule that looks closer to our original code but with much more flexibility as the complexity grows. In this example we are dealing with many more states than the original example’s three by introducing JavaScript (but this is not required: Here is a CSS only version of our original button example). Still, it effectively is one CSS property defined, and we change only one transform function at a time (whether that be in JS or CSS).

Without the CSS variables we would have to do some calculations on the current transition when changing one of the transform functions (which may not be trivial). Then we could know where the other two functions are currently to make sure the transition remained smooth. Every time a variable is changed, a new transition occurs in the same way as if you had rewritten the transform property from scratch, so you still can’t have different transitions for each transform function.

How does this compare to the upcoming individual properties in Chrome Canary?

We can do any combination of x, y, and z since we choose how to set up our initial transform.
Similarly, we can even do whatever order of the transform functions we want (though we lose the (likely) less common use case of changing the order around between states).
I’ve seen this work well in latest Chrome (56), Firefox (50), and Safari (10.1 on Mac, iOS 10.3) (version 10 supported variables but did not do a smooth transition). Additionally, the latest Windows 10 (Creators Update) releases April 11, 2017, and its new version of Edge supports CSS Variables, so we will soon see how this works there.

Please reach out if you have some creative uses for this technique.

A Different CSS Motion Path

Mon, 02 Jan 2017 00:00:00 -0600

When I first heard about the Web Animations API a few years ago, the most exciting piece was the promise of support for motion path animations - so that we could move/translate elements along a defined path instead of the linear default.

SVG has had this for years in most browsers, but the ability to use this with any DOM element brought new possibilities. A lot changed after the initial announcement, and a lot more has changed again, and there are a lot of exciting things to come from this spec. To see some examples of the current spec, see my demos and others’ demos in Chrome 55+ or Opera 42+.

For now, I want to discuss what I had originally hoped the CSS Motion Path module would be (using CSS + SVG animations to illustrate, since this doesn’t really exist).

How I Imagined CSS Motion Path

Instead of defining a path for an element and then animating its offset value to create motion along the path, I feel my ideal CSS Motion Path would tie more into existing transitions/animations.

Take a normal translate

For example, take a basic translation animation with a 2000ms duration with linear easing and an infinite iteration count via transform: translate(25rem, 7.5rem):

… and a path from SVG

Path defined by the points "M0,100 C200,0 200,200 300,0" from a viewBox "0 0 300 100"

Add a property to specify the path

For example:

translate-path: path("M0,100 C200,0 200,200 300,0")

Let the browser map the points

This is where I would pass the hard stuff to the browser (and why I understand this is a complicated issue). Assuming this could be achieved well, I’d expect the path to be rotated and scaled such that its start and end points match the start and end points of the translation.

So with the following CSS:

.circle {
  animation: go-forth 2000ms 0ms infinite linear;
  translate-path: path("M0,100 C200,0 200,200 300,0");
}
@keyframes go-forth {
  100% { transform: translate(25rem, 7.5rem); }
}

We could have the following animation (second dot is the reference of the default translation):

Then if we only change the start and end points of our translation to be further apart and from the top/right to the bottom/left (with no change to anything related to the path) such as by changing our keyframes to:

@keyframes go-forth {
  100% { transform: translate(-26rem, 52rem); }
}

We’d have:

There are several use cases for the current spec, and in many ways I'm glad it is how it is. There's still a part of me, though, that finds more value in what I've just described. I will certainly admit that might just be due to habit - being used to animating transforms for the last several years.

When to Use the Web Animations API

Thu, 04 Aug 2016 00:00:00 -0500

Firefox 48 is now available, and with it comes the third browser (after Chrome and Opera) to support an initial feature set of the Web Animations API. With it, Brian Birtles goes into detail why this API is a big deal. A few people have recently asked me why I talk so much about the API but still use CSS animations a lot of the time… so with Firefox’s official release, here are some thoughts on when using JS might make more sense than CSS.

But first, a spoiler… I still typically prefer CSS for animating. You state an animation once, and all matching selectors will pick up on it without you having to iterate through them all. There’s a reason over time we’ve seen things move from JS to CSS, and for me it’s hard to beat declaring some rules in CSS and calling it a day.

So Why Go with the API?

Dynamic/Random/New Values

One of the main reasons to reach for JavaScript is when values are not static. For a basic Transition, you can use JS to modify a value to a transition property dynamically in one line such as element.style.transitionDelay = '123ms' and that’s fine enough. However, modifying keyframe values on the fly is much more involved, such as adding a new stylesheet to the document with your new keyframes fully defined.

var frames = getFramesArray(); //get your new frames, e.g. [{offset: .5, transform: 'scale(1)'}]
animation = '@keyframes updatedAnimation {';
frames.forEach(function(frame) {
  animation += (frame.offset * 100) + '% {transform:' + frame.transform + '}';
});
animation += '}';

var style = document.createElement("style");
style.appendChild(document.createTextNode(animation));
document.head.appendChild(style);
var ele = document.getElementById('toAnimate');
ele.style.animationName = 'updatedAnimation';

Instead the API can handle this directly, and in one spot.

var frames = getFramesArray(); //get your new frames, e.g. [{offset: .5, transform: ''}];
var ele = document.getElementById('toAnimate');
ele.animate(frames, 1000);

Making randomized confetti, snow, and springy objects often requires less tinkering when using the API.

See the Pen Confetti by Dan Wilson (@danwilson) on CodePen.

For the confetti demo I actually combined both WAAPI and CSS. I used the WAAPI to generate random scale and horizontal placement values (also duration and negative delays), while animating inner divs with a 3D rotation and a wavering back and forth via CSS. I could have taken it further and animated everything with random values, but having only the container based on random values (for the primary confetti action of falling to the ground) was enough for it to feel spontaneous.

And yes, I agree - the phrase “primary confetti action” is one of the least confetti-related phrases a person can say.

A Plethora of Class Toggles

If you’re already doing a lot of logic to add and remove classes to trigger your CSS transitions or animations, the API might be a good way to go as well. That way all of your logic is in one place instead of two. Especially, if you are also needing to listen to animation events like animationend or transitionend. That is usually a sign to me that the only reason I’m using CSS is to take advantage of hardware acceleration (which you will get from browsers that support the WAAPI already).

See the Pen 755de1ba31b1629e4f662db0818185ac by Dan Wilson (@danwilson) on CodePen.

Playback Control

When you want to change the rate or be able to jump to different frames, the API will be the easiest way to do that now. It’s all technically achievable with CSS now, but you have to take a fair amount of extra care to get timings right.

Chaining Multiple Animations

Another reason is if you have complex animations that depend on other animations for when to start. The next level of the spec is introducing formal grouping and sequencing for multiple animations, but even now using the callbacks, delay, and endDelays in the WAAPI can be a lot easier than managing your sequence of animations via delays alone in CSS.

An excellent CSS-Tricks article comparing various animation methods (by Sarah Drasner) covers the cons for CSS in detail.

What about Some Specifics

See the Pen Falling Letters by Dan Wilson (@danwilson) on CodePen.

I’ve used the Web Animations in a couple client projects because they were basic enough, but still benefited from the playback rate and timeline control.

You can also use features like canceling, playbackRate variance, dynamic elements/values, onfinish handlers, and more to create a game. The CodePen version of a game I recently created is shown here, with the full version now at Letters and Such. Effectively, letters (or other characters) fall, and you have to type the appropraite key before they reach the ground. Playback Rate is increased over time, letters and locations are randomized, and if the correct key is typed the animation is canceled (and you get a point, to boot). If the key is not pressed in time, however, the onfinish handler will be called and a “miss” is counted. The code in the CodePen is commented as far as the logic is concerned, so take a look for more detail.

There is nothing that would prevent you from making this with CSS animations. It made sense for me to keep the animations primarily in JS, especially since the animations drive a lot of the actual game logic.

But What about the Future?

The Web Animations spec that underlies the Web Animations API is all about uniting JS and CSS methods. Firefox Nightly builds actually allow you to get all Animations on the document via JS, whether generated with the WAAPI, CSS Animations, or CSS Transitions. Right now some of the properties on CSS ones are read only (no changing of duration, for example), but already you can read/write the currentTime, pause these animations, or change playbackRate. There will be even less to differentiate the methods beyond personal preference as the spec matures.

A Mouse, Some Touches, and All Sorts of Pointers

Tue, 14 Jun 2016 00:00:00 -0500

If you’ve ever tried to support both touch and mouse events on the web you know there is a lot to consider, and you can get tripped up - especially when you accept that it is not an either/or situation. Pointer Events try to unify different input pointing devices so you don’t have to think as differently for touch and mouse (or a stylus… or anything new that comes like an airtap), while also giving you access to the details that might be unique to each type.

Pointer Events have been around since 2012 and the introduction of Windows 8 with IE 10. Having used them when I made Windows apps for the launch of the Windows Store, I’ve been excited about their potential. They abstract enough of the similarities between different pointer types while still providing pressure on a device that allows it.

With their introduction recently in Chrome 52 behind a flag, they now are on track to be in three stable evergreen browsers (with support already in Edge and Firefox (behind a flag since last August)). We’ll take a look at how to use them, how to enable the flags, and how to provide a fallback to mouse + touch in other browsers.

Give Me the Basics, Please

Pointer Events provide a single event for mouse + touch + stylus + other future pointing devices. They have common mappings to Mouse Events, such as if you currently listen to mousedown you would instead listen to pointerdown.

See the Pen Pointer Event Logging by Dan Wilson (@danwilson) on CodePen.

These events can be triggered: pointerdown, pointermove, pointerup, pointerenter, pointerleave, pointerout, pointerover, pointercancel

In addition to the normal event properties (such as pageX) when an event fires you also are given the following:

pointerId: a unique identifier (Integer) so that you can keep track of the touch with which you are dealing
pointerType: a string such as “mouse” or “touch”
pressure: a number between 0 and 1 for the pressure if the input and device support it (0 represents a hover, and 0.5 will be the default for an input + device that does not support pressure but is pressing)
tiltX: number in degress (from -90 to 90), visually described in the spec
tiltY: similar to tiltX, also visually described in the spec
width and height: dimensions (in CSS pixels) of the pointer. This will likely 1x1 for a mouse and something bigger for a touch, but is left to the browser to determine how to report it
button and buttons: shows which button is changed and all buttons pressed, respectively.

pointerId and pointerType are the two properties that will appear regardless of the capabilities of the pointer.

How Do I Use This Today?

There are three pieces you will want to remember when using Pointer Events:

To check support, see if window.PointerEvent is present.
Listen to events as you would with other devices/input, such as Element.addEventListener('pointerdown', function(e) {})
Set the touch-action CSS property to none (or other value than auto) on the element(s) that you want to receive Pointer Events.

It’s the third point that needs the most explanation. If you do not set this in CSS, your pointer events will fire fine for mouse, but might do nothing on touch (as determined by each browser). This is because the browser likely already has a lot of touch gestures that perform actions at the browser level, such as scrolling and zooming the viewport. By setting touch-action: none you are telling the browser to not perform those browser-level actions on the element and instead trigger Pointer Events. There are other values that will allow you to continue some browser behaviors and then fire a subset of events.

See the Pen CSS Touch Action by Dan Wilson (@danwilson) on CodePen.

For example, you could still want normal scrolling/panning on a given element, but still want to know when a pointerdown occurs via a JS event. In that case you could set touch-action: pan. You will no longer receive pointermove events for every finger movement. You could even limit this to a direction such as touch-action: pan-y, which will fire pointermove events for horizontal moves, but perform the default browser behavior for vertical movements (with no JS events sent).

Edge will not fire any Pointer Events if touch-action is auto, while Chrome and Firefox both currently treat auto similar to pan. So it is best to know and specify what you want for consistency between browsers.

As of today, you can explore their uses in the following browsers

Edge (and IE 11 (and IE10 with a prefix)): Supported
Firefox (41+): Enable the dom.w3c_pointer_events.enabled and layout.css.touch_action.enabled flags in about:config
Chrome (52+): Enable the Pointer Events flag at chrome://flags/#enable-pointer-events

The fullest representation is Edge. In my testing Chrome and Firefox work well with a mouse or single touch point already, but have issues to resolve with multitouch.

What about Fallbacks?

Almost everything in Pointer Events has a fallback either through Mouse Events or Touch Events. For example, Touch Events have an identifier that acts like pointerId and force which is similar to pressure.

I’ve not seen an equivalent for tilt*, so pen support will lack angles without Pointer Events. Though, it’s important to note tilt is only reported on a subset of pens (even the Surface Pro 4 pen does not support it in Edge).

We can use our support check to provide fallbacks

if (window.PointerEvent) {
//register event listeners for Pointer Events
} else {
//register for mouse and touch
}

Here is a full demo with multitouch and fallbacks. Press and the circles will surround your pointer. Release and they will fade away. If your pointer and device support it, more pressure/force will make the circles grow larger. 3D transforms occur when tilt values are detected.

See the Pen Press & Hold by Dan Wilson (@danwilson) on CodePen.

The caveats for this demo are the flagged releases of Chrome and Firefox. The Pointer events work well for mouse, pen, and a single touch point. When multiple touch points occur in Chrome and Firefox currently (flagged versions 52 and 48, respectively), it cannot keep up. Both browsers have work left before they become unflagged, and you can follow the status/bugs for both Chrome and Firefox for updates.

Promises in Web Animations

Fri, 18 Mar 2016 00:00:00 -0500

When I first started learning about the Web Animations API there was one way to handle a “finish” event - the onfinish callback. It lets you assign it a function and that function is called when the animation is finished.

There is a newer way to handle this scenario, though… via the finished Promise. This either excites you (if you know what a Promise is), confuses you (if you know what a Promise is), or makes you ask what a Promise is. So…

What is a Promise?

Promises have gone through several specs and implementations. A standardized version has found its way into most browsers with Edge, Firefox, Safari, Chrome, and Opera’s latest all supporting Promises. They are a feature in JavaScript similar to a callback in that they look for some code to finish running and then run some other code. With callbacks we often think of success and error handlers… with Promises we think of resolving and rejecting, such as:

//set up 1 second animation to fade box out
var box = document.getElementById('box');
var animation = box.animate([{ opacity: 1 }, { opacity: 0 }], 1000);

function finishedHandler() { 
  console.log('animation finished: ' + Date.now());
}
function canceledHandler() { 
  console.log('animation canceled: ' + Date.now());
}

//the Promise version, log the timestamp when the Animation finishes
animation.finished.then(finishedHandler, canceledHandler);

//the effective successful equivalent with the onfinish callback
animation.onfinish = finishedHandler;

This code starts an animation (by calling animate() on an element), and any other code will continue to execute while we wait for the animation to enter the “finished” state. Animations will expose a finished Promise that will “resolve” when the animation finishes. You can think of the Promise as a future object. When it resolves (in this case, a successful finish of the animation), the first function passed into the then will run. If the animation is rejected (the animation is canceled), it will run the second function passed to then, if specified.

For rejection, the current spec defines it this way, but there are discussions to change away from this. We will focus on how to work with an animation that resolves for now…

One time fits all

Promises by definition will either resolve or be rejected, and this resolution will only happen once. As soon as a Promise is resolved or rejected, it will not resolve nor reject again. Since animations can be played multiple times, this seems to be at odds with the Web animations API as subsequent finishes would not resolve again.

To solve this, the spec dictates a new Promise will replace the existing finished Promise when the play state changes to “running”. This allows you to latch on to the Promise resolution state again, but you will have to add your handlers via then again.

//extending the previous example, play the animation second time
animation.play();

//set 'then' to what spec states will be a newly created Promise
animation.finished.then(finishedHandler);

//the onfinish from before remains

Note: As of March 18, 2016 the polyfill has an issue with resolving subsequent finished Promises at the correct time.

Then Why Bother?

Imagine a case where you want to trigger new animations when a given animation finishes. The following example shows two boxes, one using onfinish to start new animations and the second using the finished Promise.

See the Pen Callbacks vs. Promises with Web Animations API by Dan Wilson (@danwilson) on CodePen.

Callbacks will nest, and Promises can chain by returning a Promise. For this example it reads differently, and one might be more readable than the other to you. In fuller development the chaining can provide more power with how you manage your animation states and values. We will look into that in a future post.

There is a lot more to talk about with Promises… for much fuller discussions on Promises check out the Ponyfoo article on the topic and the MDN article, especially their suggested reading.

Thanks to Rachel for triggering this discussion and Šime for pointing me to when an animation is rejected in the spec (and Jake for mentioning the discussion about changing that). Thanks also to Martin for recommending additional Promise articles.

Of Layouts with Columns

Fri, 04 Dec 2015 00:00:00 -0600

I've been wanting to try this alternate large-screen layout out for a while, but there were quirks (more on those later) I hadn't resolved so I waited. Now that I (potentially) have resolved the issues I'm just going to flip the switch and see how these columns work out!

Mobile is always where I first read something, but I know that especially in the tech industry we still read on large monitors while working. It’s weird that we have these large monitors but we still set max-widths on our content and force the user down a page. So… I’m trying out columns on my articles when you have a large and wide screen. Full width and horizontal scrolling - why not?

Columns, grid layouts, and other new methods for laying out pages have been emerging the last few years. I’ll quickly admit I have not done user research or anything to validate what I’m trying here… it’s simply my current exploration as to what we can try. Hopefully it works well for you, and if it doesn’t I’d love to hear thoughts on why.

So How Does it Work?

Initially I’m rolling this out to what I (somewhat arbitrarily) deem a large enough viewport (1600x900), via the following media query:

@media screen and (min-width: 100em) and (min-height: 56.25em) {
/* ... */
}

I also look to see support in browsers. The following should support all browsers that support CSS.supports and column (as well as IE 10 and 11 that have unprefixed column support but lack CSS.supports):

if ((window.CSS && window.CSS.supports && (CSS.supports('column-width', '1px') || CSS.supports('-webkit-column-width', '1px') || CSS.supports('-moz-column-width', '1px')))
    || (document.body.style.columnWidth === '')) {
    document.documentElement.classList.add('columns');
  }

Then I do some width/padding/position updates to the body and containers to prepare them for being a page with height 100vh and scrolling horizontally, as well as adding the column properties to my article. There are also rules set up to try to prevent breaking before a paragraph that follows a heading:

.columns article {
  /* also include -moz and -webkit */
  column-width: 58rem;
  column-gap: 5rem;
  height: calc(100vh - 24.5rem); /* take full height less the header and footer */
}

.columns p + h3 {
  break-after: avoid; /* not well supported outside IE/Edge */
}

What Were the Quirks?

I had planned to roll this out when I reworked my site a half year ago, but that was when I started using a lot of CodePens in my articles. Columns do not respond well to changes to content once they have rendered (in the case of CodePen a link changes to a module with a different height and different break rules). If the length of your content changes after the column is painted the browsers are not responding to that change, and you will potentially have your last column(s) chopped.

I’d known about this issue since I first tried columns a few years ago… but I still forget about it. I have now learned that both browser resizes and changes to the column properties will cause the browser to repaint, so my current solution is to load the CodePen script and attach an onload event listener. That is still to soon to act, so for now I am resorting to a setTimeout to make it work (in my case a change to the column-gap by .1rem does the trick).

(function() {
  function onCodePenLoad() {
    setTimeout(function() {
      var article = document.querySelector('.post-content');
      article.classList.add('external-loaded'); //this class just changes the column-gap values by .1rem
    }, 1000);
  }
  var cp = document.createElement('script'); cp.type = 'text/javascript'; cp.async = true;
  cp.src = '//assets.codepen.io/assets/embed/ei.js';
  cp.onload = onCodePenLoad;
  var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(cp, s);
})();

Other Layouts

There are many people talking about alternative screen layouts and the new CSS that is here and coming to help us. I highly recommend CSS Layout Weekly from Rachel Andrew and catching up on podcasts and talks from Jen Simmons of The Web Ahead.

Should be a fun time ahead on the web.

Web Animations API Tutorial Conclusion

Mon, 14 Sep 2015 00:00:00 -0500

This is the conclusion to an introductory/tutorial series on the Web Animations API coming to browsers. I've updated the series content in June 2016, as Chrome and Firefox have both rolled out major updates (and some small spec changes). If you have thoughts/questions or see that I’ve misinterpreted the spec, please reach out to me on Twitter, @dancwilson.

We’ve covered a fair amount of ground and hopefully cleared up questions about what the Web Animations API is (and is not). To conclude this series, we’ll recap what we’ve discussed and take a look at what has yet to be implemented.

Why Bother with the API?

In the introduction we discussed how the API came into being as a way to unite the various methods to animate in CSS, JS, and SVG… with the intent to take the best of them all. This means, for example, JavaScript can latch on to the hardware acceleration that CSS has had for years, and you are not limited to the declarative nature of CSS. The API is not meant to replace libraries like GSAP, but simply to provide more options at the browser level.

Firefox and Chrome have both started implementations, and Edge has it on its backlog. The polyfill allows us to start playing with it today as the team finalizes the specification.

Animation Basics

To create a basic animation, we follow a structure similar to CSS by providing keyframes and timing properties.

var player = document.getElementById('toAnimate').animate([
    { transform: 'scale(1)', opacity: 1, offset: 0 },
    { transform: 'scale(.6)', opacity: .6, offset: 1 }
  ], {
    duration: 700,
  });

Timeline controls are the obvious pieces not currently present in CSS. Reading the state of an animation happens via the playState property, and changing the state is via methods such as play(), pause(), and finish(). We can also change the playback rate to be slower or faster with the read/write playbackRate property. The currentTime can be checked (or changed), and we can set a callback for when the animation finishes with onfinish.

Multiple Animations and Grouping

The Web Animations API allows for multiple animations on an element, creating separate animation objects. The default timeline on the document gives us access to all animations created with the getAnimations() method. Animations can be grouped to play together or one after the other by using GroupEffects and SequenceEffects (available in the polyfill but not in the first spec).

Motion Path and the Future

Animating along a path sneakily saw its first implementation in CSS during this series, but there are many other pieces yet to come.

Spacing

The current implementations use a default spacing if no offsets are set in the keyframes, meaning they are evenly distributed (e.g. three frames will have offsets of 0, .5, and 1). The specification also defines a way to pace the animation based on a property, so that it has a constant rate of change. The spec describes this well when discussing Spacing Keyframes.

Promises

The spec has evolved to include a ready Promise that will be replaced with a new Promise every time the animation is cancelled or enters a pending state (which will typically happen before changing to “running” or “paused”). In addition to using the onfinish callback as we have discussed in this series, we will be able to use the finished Promise to run a function after an animation finishes.

Let’s Keep Talking about the Web Animations API

People are starting to talk more about this API, and I hope this conversation continues. The spec, browser implementations, and polyfill have been going on for a while, and they are ready to examine closely.

Sometimes CSS will make the most sense, sometimes requestAnimationFrame will, and sometimes using a library will be the best solution. It’s good to know when to use what, and this API provides quite a few things that were not previously available to us by default… so have fun.

Check out the rest of this series:

Web Animations API Tutorial Part 5: The Loveable Motion Path

Tue, 08 Sep 2015 00:00:00 -0500

This is Part 5 of an introductory/tutorial series on the Web Animations API coming to browsers. I've updated the series content in June 2016, as Chrome and Firefox have both rolled out major updates (and some small spec changes). If you have thoughts/questions or see that I’ve misinterpreted the spec, please reach out to me on Twitter, @dancwilson. An earlier (and slimmer) version of this one article appeared on my CodePen Blog shortly after Chrome announced its flagged Motion Path support.

Finally. Animating along a path… no longer just the domain of SVG.

Motion Path: Current Direction (of the Spec)

See the Pen Motion Path Infinity by Dan Wilson (@danwilson) on CodePen.

As the API specification has been worked through, motion path has appeared in different forms. One direction that initially seemed likely was the form of an Effect (like the previously discussed GroupEffect), but then a little bit of steam picked up with Motion Path as a CSS Module (with its own spec).

Therefore animating along a path will simply be another set of CSS properties that can be animated, just as opacity and tranform can. This way CSS Transitions and Keyframes can use it as well as the Web Animations API… which is great since we want as much as we can shared between these methods to give us more flexibility. Chrome and Opera have released an initial implementation, so we can actually start playing with it today even though it has not found its way to any polyfill.

Let’s break down what these properties are, how we can use them, and what things might still trip us up for now.

Motion Path Properties

There are three motion properties we will discuss. For now, to see the examples you will need to be running Chrome 46 or Opera 33.

`motion-path`

The starting point is motion-path which defines a path along which the element can move, following how paths work in SVG 1.1:

#motioner {
  motion-path: path("M200 200 S 200.5 200.1 348.7 184.4z");
}

This can also take a fill-rule as an optional first parameter in the path call. I recommend reading Joni Trythall’s excellent Pocket Guide to Writing SVG for a discussion on what this entails.

According to the spec, you can also use a basic shape such as circle, polygon, ellipse, and inset. These should look familiar to you if you have tried using CSS Shapes.

With Blink’s initial implementation, I’ve only seen the path() method work, so either I’ve been using shapes incorrectly or that is yet to come.

`motion-offset`

To drive the motion and actually place the element somewhere on the path we use motion-offset. This can either be a double length value or a percentage. So to animate from the starting point of the path to the end we set up an animation that goes from 0 to 100%. With the Web Animations API we have

var m = document.getElementById('motioner');
m.animate([
  { motionOffset: 0 },
  { motionOffset: '100%' }
], 1000);

And with CSS

#motioner {
  animation: path-animation 1s;
}
@keyframes path-animation {
  0% { 
    motion-offset: 0;
  }
  100% { 
    motion-offset: '100%';
  }
}

See the Pen CSS Motion Path Spiral by Dan Wilson (@danwilson) on CodePen.

This CodePen demo shows several dots moving along a spiral path from the outside to the inside. As each dot approaches the center it gets faster, smaller, and becomes transparent. .animate() is called twice on each dot with inifinite iterations and a delay, where one call focuses on the motion offset and the other focuses on the scaling and opacity. I broke them out to specify different easings, but they certainly could have been combined.

This approach also uses feature detection, which you will notice if you are viewing this in Safari, Firefox, Edge, or an older Chrome/Opera because you will see a message instead of the animation. There a few ways to do this, such as

var m = document.getElementById('motioner');
if (m.style.motionOffset !== undefined) { ... }

Of course, we wouldn’t want to block out users completely in a real web thang, so we can have an alternate animation (or no animation) that switches to the Motion Path animation if supported. Progressive Enhancement is a friend here, as usual.

`motion-rotation`

The final property is motion-rotation, and it deals with which direction the element “faces” as it moves along the path. There are four primary ways to specify this.

The value “auto” means the element will rotate with the path.
With the value “reverse” the element will also rotate with the path, but it will add 180 degress, so it will be facing backward.
“auto Xdeg” (or “reverse Xdeg”) will do the same except add X degrees
“Xdeg” will no longer rotate with the path, the element will stay fixed facing the same direction.

See the Pen CSS MotionPath by Dan Wilson (@danwilson) on CodePen.

What’s Missing?

This is a first version, of course, and the browser makers and spec writers are still discussing it all. The biggest thing I have noticed while trying this out was the lack of a way to adapt the path to different screen/container sizes.

Paths simply appear as they are defined. When working with SVG we get flexibility because we have different coordinate systems and attributes on the container like viewBox. With Motion Paths defined in CSS, the size of the path cannot be additionally modified or constrained with other properties. The width and height defined on your element apply only to the element, not its motion path. You could use media queries or JavaScript to define different paths for different criteria, but setting it up with flexibility via the motion properties is not possible yet.

Wrap Up and Next Time

We will see the direction the specification takes, but for now it’s fun to try this out and see what it might provide (and not provide). I’m gathering a collection of CSS Motion Path demos I find on CodePen, and Eric Willigers (owner of this implementation task on the Chrome development team) has a Google Doc with examples.

We will wrap up this series next time by recapping what we have discussed and taking a look at a few currently-only-in-the-spec topics.

Check out the rest of this series:

Web Animations API Tutorial Part 4: GroupEffects & SequenceEffects

Wed, 02 Sep 2015 00:00:00 -0500

This is Part 4 of an introductory/tutorial series on the Web Animations API coming to browsers. I've updated the series content in June 2016, as Chrome and Firefox have both rolled out major updates (and some small spec changes). If you have thoughts/questions or see that I’ve misinterpreted the spec, please reach out to me on Twitter, @dancwilson.

Let’s continue our discussion on multiple animations within the Web Animations API by discussing a few pieces available today in the polyfill to provide grouping and sequencing.

KeyframeEffects

A KeyframeEffect takes three parameters: the element to animate, an array of keyframes, and our timing options. These are all parameters we’ve seen before when using element.animate(). This new object essentially is a blueprint for a single animation and we will see it as we discuss ways to group and sequence animations. It does not start an animation, it just defines one.

var elem = document.getElementById('toAnimate');
var timings = {
  duration: 1000,
  fill: 'both'
}
var keyframes = [
  { opacity: 1 }.
  { opacity: 0 }
];

var effect = new KeyframeEffect(elem, keyframes, timings);

GroupEffects

Though not available in any native implementation yet, and not even found in the Level 1 spec, the polyfill provides a way to group animations and play them together. The GroupEffect (yes, it is coming in the Level 2 spec) groups one or more KeyframeEffects to play simultaneously.

See the Pen zGeVey by Dan Wilson (@danwilson) on CodePen.

A GroupEffect takes an effects parameter where we can pass in our array of KeyframeEffects representing our multiple animations. Once defined, we can play the group of animations on the default timeline when ready.

var elem = document.getElementById('toAnimate');
var elem2 = document.getElementById('toAnimate2');
var timings = {
  duration: 1000
}
var keyframes = [
  { opacity: 1 }.
  { opacity: 0 }
];

var kEffects = [
  new KeyframeEffect(elem, keyframes, timings),
  new KeyframeEffect(elem2, keyframes, timings)
];
var group = new GroupEffect(kEffects);
document.timeline.play(group);

SequenceEffects

Similar to the GroupEffect, SequenceEffects allow us to group together multiple animations (specified by KeyframeEffects)… but instead of playing them in parallel they play one after the other. You can also, as defined in the polyfill, use GroupEffect and SequenceEffect together (such as having a grouping of multiple sequences).

See the Pen vNYQLL by Dan Wilson (@danwilson) on CodePen.

Sequences give you something that we’ve had to work our way around with CSS or with what we’ve seen with the animations API so far. We would have to maintain delays based on duration of earlier animations or use finish callbacks. These methods can be hard to maintain and may not be as precise.

Using the earlier variables from the GroupEffect code segment:

var sequence = new SequenceEffect(kEffects);
document.timeline.play(sequence);

An Alternate Way to Create an Animation

We have previously looked at the element.animate() way to create animations. This is the quick way to create an animation, play it immediately, and get a reference to the Animation object. We focused on this first since it has been supported in Chrome for a while now, as well as the polyfill. Firefox is the first to support an alternate way: the Animation constructor. It shows us one more way to use the KeyframeEffect, and it is in the Level 1 spec so we should see more use of this soon.

First a reminder of how element.animate() works:

var elem = document.getElementById('toAnimate');
var timings = {
  duration: 1000,
  fill: 'both'
}
var keyframes = [
  { opacity: 1 }.
  { opacity: 0 }
];

elem.animate(keyframes, timings);

Using the same variables as above, the following is equivalent using the Animation constructor:

var kEffect = new KeyframeEffect(elem, keyframes, timings);
var player = new Animation(kEffect, elem.ownerDocument.timeline);
player.play();

The primary difference here is that the animation does not start playing immediately, so this will be useful when creating animations in advance to be played later.

Wrap Up and Next Time

As the Level 2 spec makes its way through the working drafts, we should see more definition on these different Effects. There are two more planned posts in this series. Next time we will take a look at the future again with what else we can expect to see soon.

Check out the rest of this series: