{"id":3917,"date":"2014-08-14T19:59:08","date_gmt":"2014-08-15T03:59:08","guid":{"rendered":"http:\/\/blog.mozilla.org\/webdev\/?p=3917"},"modified":"2016-01-05T13:58:19","modified_gmt":"2016-01-05T21:58:19","slug":"animating-firefox-desktop","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/webdev\/2014\/08\/14\/animating-firefox-desktop\/","title":{"rendered":"Animating the Firefox Desktop Pages"},"content":{"rendered":"

As you may have noticed, Firefox for desktop computers (Windows, Mac, and Linux) got a redesigned interface with the release of Firefox 29.0<\/a>. This redesigned browser called for redesigned web pages to showcase the new interface (the tabs, icons, menus, etc., collectively called “browser chrome”) and new features (especially the new customization menu)<\/p>\n

Naturally, the main audience for these pages are people using browsers that aren’t Firefox, so we wanted to illustrate the new Firefox design in a fun and compelling way that gives them a real sense of what it looks like, hopefully encouraging folks to download it and see it first hand. Another big target audience are Firefox users who haven’t yet updated, so we needed to give them an overview of what’s new.<\/p>\n

This also gave us a chance to create some snazzy animations to show off some of the advances in CSS and SVG supported by the current generation of browsers, both on desktop computers and mobile devices. Here’s how we made it.<\/p>\n

\"\"<\/a><\/p>\n

Browser Chrome Animations<\/h2>\n

In order to demonstrate features of Firefox, we needed to simulate the way interface elements respond to user actions; opening and closing tabs, rearranging icons, adding a bookmark, and so on. This called for fairly complicated animation sequences that had to be quick and buttery smooth. The complex interplay of multiple elements moving both sequentially and in tandem really drove home the need for a CSS animation editor<\/a> (vote it up!).<\/p>\n

Approach & structure<\/h3>\n

Each animation illustrating the browser chrome (One<\/a>, Two<\/a>, Three<\/a>) is wrapped in a div<\/code> element with a common class applied (animation-wrapper<\/code>), along with an id<\/code> we can use to target the specific element with JavaScript.<\/p>\n

The first element inside the animation wrapper is a composite fallback image for browsers that don’t support CSS animations. This image has a common classname (fallback<\/code>) for easy CSS targeting. We can conditionally hide this image by leveraging the cssanimations<\/code> class Modernizr<\/a> applies to the body<\/code>. By first assuming that animation is not<\/em> supported, we ensure a functional degradation for even the oldest and least capable browsers, and we can progressively enhance the page for more advanced browsers that support the more advanced features.<\/p>\n

The next element inside the wrapper div<\/code> is the stage for the entire animation \u2013 <div class=\"stage\"><\/code>, really just an invisible box in which other elements can move around. Using the same cssanimations<\/code> class from Modernizr, we’ll display the stage for browsers that can handle the animation.<\/p>\n

\/* for legacy browsers *\/\r\n.fallback {\r\n    display: block;\r\n}\r\n\r\n.stage {\r\n    display: none;\r\n}\r\n\r\n\/* for modern browsers *\/\r\n.cssanimations {\r\n    .fallback {\r\n        display: none;\r\n    }\r\n\r\n    .stage {\r\n        display: block;\r\n    }\r\n}\r\n<\/pre>\n
(We use Less<\/a> to preprocess our CSS, so those nested rules are converted into separate rules with descendant selectors.)<\/p>\n
The final task is to trigger the animations only when they come into view, as there’s no sense running an animation while it’s off screen. We used jQuery Waypoints<\/a> to monitor the page’s scroll position, adding an animate<\/code> class to each wrapper div<\/code> when it comes into view. The addition of that class sets off the CSS animation sequence.<\/p>\n
.animating-element {\r\n    position: absolute;\r\n    top: 10px;\r\n    right: 40px;\r\n}\r\n\r\n\/* animate class added via JavaScript\/Waypoints based on scroll position *\/\r\n.animate {\r\n    .animating-element {\r\n        animation: moveAround 0.7s ease 0s 1 normal forwards;\r\n    }\r\n}\r\n<\/pre>\n
This approach worked well and helped us keep each animation block self-contained and modular. It provided a common and easily customizable HTML & CSS structure for each animation, and less capable browsers still have access to all the content in a well styled page. Within that stage box we can add any other content or elements we need.<\/p>\n
Timing is everything<\/h2>\n
The browser chrome animations have multiple elements with multiple animations applied, so getting the timing just right became rather tedious. Because separate animations are completely independent in CSS, there’s no simple way to tell a browser to “start animationY 2.1 seconds after animationX completes.” Instead, you need to do the calculations yourself and hard code them into each animation declared in the CSS, liberally using animation-duration<\/code> and animation-delay<\/code> to fire off each step of the scene in sequence. The mental gymnastics go something like this:<\/p>\n
Step 1 has a 0.7 second delay and runs for 1.5 seconds. Then Step 2 should start 1.4 seconds after Step 1 completes, so it should have a delay of\u2026 3.6 seconds. Step 2 runs for 2 seconds, and Step 3 needs to begin a quarter of a second before Step 2 completes, so Step 3 needs a delay of 5.35 seconds\u2026<\/p><\/blockquote>\n
As you can imagine, the more elements you animate and the more steps you have in the sequence, the harder the math becomes. Adjusting the timing of one step in the chain can mean adjusting all the subsequent steps to compensate.<\/p>\n
Designer Ty Flanagan created video mockups in Adobe After Effects<\/a> to serve as a guide for the CSS animation, which was an enormous help. There was still a fair amount of fine tuning to be done by hand, constantly refreshing the page and tweaking a few milliseconds until it just “felt right,” but that process could have taken much longer without the videos for reference.<\/p>\n
Another way to do all of this would have been controlling the chained animations in JavaScript, relying on the animationend<\/code> event to fire off the next step in the sequence. However, a bunch of event listeners and setTimeout<\/code> calls in a script probably wouldn’t have been a faster or better approach.<\/p>\n
Animations in a Circle<\/h2>\n
Some of our favorite animations are the customize icons<\/a>, mostly because the circular mask effect is so neat in its simplicity.<\/p>\n
\"\"<\/a><\/p>\n
The key to achieving the circular mask is a bit of absolute positioning and the incredibly versatile border-radius<\/code>. The markup isn’t too complex \u2013 a stage to contain everything, a div<\/code> for the circular mask, and whatever elements need to be animated.<\/p>\n
<\/pre>\n
\n
<\/div>\n
 <\/p>\n
<\/div>\n
 <\/p>\n
<\/div>\n<\/div>\n
If you’d like to see an example and play around with the code before reading about the methodology, here’s a little demo on CodePen<\/a>.<\/p>\n
The stage<\/h3>\n
The stage has a set height and width with a hidden overflow and relative positioning. The background color of the stage fills the circular mask.<\/p>\n
.stage {\r\n    position: relative;\r\n    width: 300px;\r\n    height: 180px;\r\n    overflow: hidden;\r\n    background: #fff;\r\n}\r\n<\/pre>\n
The circular mask<\/h3>\n
The circular mask is absolutely positioned at the center of the stage, calculated by (stage width - (mask width + mask border width))\/2<\/code> (this equation could be simpler with box-sizing: border-box<\/code>). The mask has a wide enough border to reach just past the furthest boundary of the stage. The border bumping up against the page background is what completes the illusion of the mask, so the mask’s border color matches that of the section’s background color (sadly, this means the technique only works with a solid colored background).<\/p>\n
To make sure the mask covers the animated elements, it has a z-index<\/code> at least one higher than the front-most animated element.<\/p>\n
.circular-mask {\r\n    position: absolute;\r\n    width: 164px;\r\n    height: 164px;\r\n    border: 100px solid #ccc;\r\n    border-radius: 50%;\r\n    top: -100px;\r\n    left: -32px;\r\n    z-index: 2;\r\n}\r\n\r\n\/* animated elements share absolute positioning and \r\n   a z-index lower than .circular-mask *\/\r\n.animated {\r\n    position: absolute;\r\n    z-index: 1;\r\n}\r\n<\/pre>\n
The animated elements<\/h3>\n
The only requirement for the animated elements is that they reside inside the stage and have a z-index<\/code> lower than the mask. Otherwise, anything goes.<\/p>\n
Though purely flair (as opposed to the feature demonstrations provided by the browser chrome animations), these circular animations were fun to build and we’re very pleased with the result.<\/p>\n
Drawing Firefox in the browser<\/h2>\n
When we first watched a video mockup of the proposed intro animation for the new Firefox for Desktop<\/a> landing page, we wondered if this was actually possible to pull off in a web browser. The animation involves a series of moving lines which fill in as the outlines fade onto the web page, creating an illustrated image of the Firefox browser. Definitely not a typical animation you see on the web every day!<\/p>\n
\"\"<\/a><\/p>\n
The first step on the path of discovery was to choose an appropriate image format. SVG seemed like the most obvious choice, given that the images needed to scale. Nobody on the team had any prior experience with SVG animation but it seemed like a fun challenge! Ty came up with a rough demo showing how we might use SVG path strokes for the moving lines, which seemed like a perfect starting point. We could have chosen to use an SVG animation library such Raphael<\/a> or SnapSVG<\/a>, but we wanted to try to keep our dependencies as light as possible (we had plenty already; no reason to add any more if we can avoid it). The timing and intricacies of the animation made a strong case for trying to use CSS keyframe animations, and this would also be a good opportunity to show off their potential. It was then we recalled this really clever technique<\/a> that could pull off the same line-drawn effect using CSS.<\/p>\n
Animating SVG line paths using CSS<\/h3>\n
The trick to the line drawing effect is to animate the stroke-dashoffset<\/code> of an SVG image path. The stroke-dasharray<\/code> property allows you to apply a dashed border effect to the outline of an SVG image. The clever part is that if you set the length of the dash equal to the total length of the image path, you can then animate stroke-dashoffset<\/code> to make it appear as if the line is being drawn one segment at a time. Magic!<\/p>\n
Here’s an example of an SVG path:<\/p>\n
\r\n\r\n<\/pre>\n
And some CSS to animate it:<\/p>\n
.circle {\r\n    stroke-dasharray: 117;\r\n    stroke-dashoffset: 117;\r\n    animation: draw-circle 5s linear forwards;\r\n}\r\n\r\n@keyframes draw-circle {\r\n    100% {\r\n        stroke-dashoffset: 0;\r\n    }\r\n}\r\n<\/pre>\n
You can find the required length of a path pretty easily using a bit of JavaScript:<\/p>\n
var circle = document.querySelector('.circle');\r\nvar length = circle.getTotalLength();\r\n<\/pre>\n
The animation on the finished page is quite a bit more complicated than this example, but hopefully you can get the idea. We also animated fill-opacity<\/code> and stroke-opacity<\/code> to color in the browser panels and fade out the lines at the end of the animation, leaving a scalable vector drawing of the new Firefox.<\/p>\n
Scaling SVG using CSS transforms<\/h2>\n
As well as animating the line drawing, we also needed to scale the image as it zooms onto the page. From there, the icons also zoom into their appropriate places. This was all done using regular CSS transforms via translate<\/code> and scale<\/code>.<\/p>\n
There are some notable cross-browser inconsistencies here when it comes to scaling SVG using this method. Both Chrome and Safari render a bitmap of an SVG prior to performing a CSS transform. This is presumably for performance reasons, but it does lead to blurry images when you blow them up. Firefox seems to weigh up performance and image quality a little differently, and renders sharper images when they scale. To get around the resizing issues, the best solution was to render icons at their largest size initially and then scale them down, as opposed to the other way around. It seems browsers still have some work to do in this area in order to improve SVG rendering under these circumstances.<\/p>\n
Putting it all together<\/h2>\n
Combining all the separate CSS keyframe animations together was probably the most time consuming task. We can also look forward to the day when we no longer need vendor prefixes for CSS keyframe animations, as the duplication of code required is still a bit undesirable. Aside from this, getting the timing right was once again the trickiest part. For a less-than-5-second animation, having to reload and run through the whole sequence over and over made the process pretty time consuming (here’s another vote for that CSS animation editor<\/a>).<\/p>\n
\"\"<\/a><\/p>\n
The final result of all this work is a set of pages that beautifully show off what the new desktop Firefox looks like while also showing off what it can do with open web technologies. If you haven’t yet, please do check it out<\/a>. It’s all responsive, mobile-friendly, progressively enhanced, retina-ready, and still pretty light weight all things considered. And without a single byte of Flash.<\/p>\n
The team<\/h3>\n