Things are getting better now.

No more plug-ins.

True animation is part of the web platform.

And here to tell us about it, to tell us about the now and the future, a huge post-lunch welcome-- it's Rachel Nabors.

[APPLAUSE] Oh my goodness.

I don't think I've spoken to quite so many people before.

But I'm very happy to be here.

And I'm super, super thrilled to have been invited.

Thank you guys so much for having such a wonderful shindig.

I'm totally flattered.

Now, awkwardness aside, moving along.

I am, as he says, Rachel Nabors.

And this spring-- I think it was spring-- I was approached about this conference.

And I thought, this is a great idea.

I want to go talk about web animations there.

And then the summer happened.

And I traveled, and I met people, and I talked about web animations.

And originally, I had pitched a talk called CSS animation sucked because you're doing them wrong.

But as I spoke to people, more interaction developers, people who've been working on the Web Animations API, designers who've been having problems with making animations work for them, I realize that while we love CSS animations very much, they do fall short in a number of ways and that the animation landscape is changing.

So I came back, asked if I could change the talk to be more like this.

Meantime, I also started a business.

Let's see.

Nope.

Started a business.

And I'm only putting this up here to let you know that I work for myself.

By working for myself, I am completely unbiased.

Nobody pays me to do anything for them from the major browsers.

I've only done one project for Adobe.

And thus, you can know that I'm speaking from a place of neutrality and love when I give this presentation.

But I will give you one disclaimer-- that I am a CSS nerd, and I did come into web animation CSS first.

And when I say I started this business, what I mean is that I squirreled enough money away to fool around with web animations indefinitely.

And I enjoy making the web do all kinds of fun things that it wasn't meant to do in the HTML5 specs.

But nonetheless, we are making it do it today.

I do have one very special skill.

I happen to be an award-winning cartoonist and then I got into front-end development.

And that skill really comes in handy on days like today.

Now, I interviewed a lot of people.

But while I was interviewing them, I asked them about what they're doing with animation and where it falls flat.

I also realized that the people I'm interviewing are terribly-- it's hard to find a word for it.

There's a lot of cattiness.

There's a lot of people who have strong opinions.

And I didn't want to name any names.

And some people would be like, oh, are you going to quote me, because if my employer finds out I said this, sh, sh, sh.

So I have distilled all the people I interviewed into four characters.

I've got-- I will introduce each of them to you as we go.

So these are they.

You'll meet them all.

And I realized while I was interviewing all of these people that before anyone got on stage to tell you what to do with animations, there is a human side that needs to be told to this story.

And I happen to love telling stories.

So the era of web animation has just begun.

Now since Flash-- hang on a minute.

These things keep poking at the mic.

There we go.

That's much better.

Don't let me forget that.

So since Flash, animation has been seen as mostly decorative.

There isn't a conference I've been to in the past year where someone hasn't gotten on stage and made some sort of a Flash joke.

And I always cringe when I hear them because it's kind of like hearing someone use a slur in their talk.

It gets a cheap laugh out of the audience.

[SIGH] Remember Flash? Oh.

And you know, everyone's clapping.

In the meantime, in the back over there is this person who was like a god of ActionScript who's just dying inside and hating you all.

Yeah.

I've got to say, we've got to stop doing that because we're not helping anyone for reasons you're going to see very soon.

So since Flash died, we talk about animation like it's a dirty word.

It's thrown on at the end of a lot of processes.

Or whenever we talk about it, it's like an afterthought.

But first, what is animation, really? It's just a visual representation of a rate of change over time and space.

There are audio representations of these, but we talk about them a lot less because people who come to these conferences tend to be cited.

But animation is just that.

It's just a rate of change visually represented over time and space.

It's very useful to us.

And this young lady here is a user interface designer.

She represents not all user interface designers, but like the median of user interface designers.

You have to remember, there are outliers.

But user interface designers, or interfacers, as I like to think of them, they know that anything other than copy on a web page, you're going to need animation to make that work.

They know that just as hierarchy guides users through content like copy, animation guides users through interactions using relationships, structure, and cause and effect.

And I would talk to you for another hour about all of these, but that is a different talk.

And that is not the one I was brought here to give you.

So we're going to move on.

I will say that we knew as early as the '90s that animation actually improves how users, especially old and young users, adopt interfaces.

We have this lovely paper, which is still available, which basically what it says is that when you, instead of jumping between two states in a user's task flow, if you animate between the two of them, you offload a lot of processing to that person's visual cortex, thus freeing up more of their mind for the task at hand.

And this becomes super, super, super visible when you're working with people with reduced computing power in their brains, like busy people or old people.

Then this guy, the interaction developer, he works a lot with complex animations.

He's often experienced with Flash.

And he does things from infographics to dashboards, and sometimes even to building games.

And he knows that if you want any of those things on the internet, you are going to need animation.

You are going to need all kinds of animation because this sort of thing can't be done with just some CSS and a couple of paragraph tags.

Google knows that you need animation.

If you've seen the Google material design papers, they did a really nice section in there devoted completely 100% to animations.

And it's some of the best examples I've seen of how to and how not to use animations in an interface.

And I think this is a really big statement because products that use animation are going to benefit from the increased usability.

They're going to succeed where their animation-abusing or animation-free competitors just fail.

There's no escaping this.

This is the core of it.

As long as we have GPUs, we, however, are faced with an animation problem.

Animation is a natural step in the evolution of apps and device systems that we've been building, be they on the internet or in walled gardens of apps stores.

It's not going away anytime soon.

But before we talk too much about how we're going to solve this problem, let's talk about the kinds of ways that our two wonderful designer and developer friends use different kinds of animation.

There are three kinds.

And we combine them all in many interesting ways.

There's static animations.

I tried to use my own words for these.

And I was really careful.

I didn't want to use too many programmy words because somebody in the audience would be like, I object.

Declarative versus imperative programming does not work that way.

So I'm sorry, there's probably better words for this.

You come up with them.

So, static animations-- they run from start to finish.

There's no branching logic.

And it all depends on the animator to define the beginning state and the end state.

Think of a loading spinner that has a cycle it goes through.

It's not actually changing because there's new input.

You know, not one that gives you the percentage points, just one that goes [MAKES NOISE].

That is a static animation.

You can define that in CSS.

No problem.

You can even make a video of it.

No problem.

It's not impossible to achieve it with CSS, either.

For instance, this is a music video.

There's no music right now.

I thought it might short circuit the electrical system, again, that I made using just CSS.

There's a little bit of JavaScript to hit Play on some things.

But the point was when I made this is that I wanted to do something with animation that didn't use JavaScript.

And this is when I got hooked, by the way.

It was shortly after this that I quit my job and went crazy and moved to Portland.

So, stateful animations-- In its simplest form, it's like a Boolean input.

You have your default state.

Then something happens.

A user hovers over a button or they hit Play.

And then it moves to a defined state.

And the state that, once again, has been defined by the designer, the animator.

This is a pretty simple example.

And I would like to thank the people at Codrops for this lovely drop down, which I love.

It can be as simple as a click.

CSS has lots of built-in states like hover and selected and even target that let you use these.

That's all right.

That's kind of interactive.

And states become much more pronounced in app environments.

Different states corresponding to different tasks.

For instance, here, this is Evernote, which is a native app.

But you can see that as you move through it, each one of these states is animated between one and the other.

None of them are jump cuts.

The page is never completely repainted.

New content is animated into the page.

And it's a really nice feel for users.

Then, here's where we have problems-- dynamic animations.

Dynamic animations are special because, as the designer, all you can do is give it the information it needs to respond to events and it determines what the outcome is.

Dynamic animation isn't going to give you the same animation twice in most cases.

It does its own thinking.

You give it rules and variables, and rather than at a pre-defined state, it determines its own behavior and end state.

This is the kind of thing that requires a dynamic animation.

I'd like to thank Alex Graul at CrowdStrike.

He let me borrow this.

This is an actual interface that they've built for monitoring security resources over a huge network.

And you might think, well, that's unnecessary.

But actually, this isn't unheard of.

This is a pretty decent way of managing a lot of resources and seeing what's happening.

The little orange dots are supposed to indicate security alerts.

So this is a big example of a live, updating animated interface that's not possible given the current APIs that we have as they are.

He did a lot of homebrew to make this happen.

I believe he's using a bit of juice sap in there, too.

All right.

Now, whenever I talk about this with our lovely UI designer, they always say, well, I could technically do a dynamic animation if you gave me enough states.

Well, maybe.

When you get enough states in a stateful animation, you can start having something that feels like a reactive animation.

It feels more dynamic.

This is how that would look.

But it can only go to those designated states you've given it.

It can't anticipate what a new state would look like.

You can imitate reactive animations by adding more and more of these states.

But this is how a true dynamic animation would handle that.

Truly reactive animations have more states than you can reasonably anticipate or code for.

Technically, you could do a stateful animation for every event that could ever happen in a first person shooter, but you don't have the time.

And frankly, the code would be enormous.

So here's an example of a simple loading bar.

This one does a 10%, 20%.

Lets you know when everything is uploaded.

With CSS and JavaScript, you could create 100 different scoped classes to kind of show like I could do this in CSS.

Every time we get an update on how much stuff has been loaded, we'll change the body class to loaded-002, 003.

And we'll keep doing that, and the bar will keep getting longer.

And it just keeps going on, and you have 100 lines of code.

I'm sure that you could write this in Canvas with less than 100 lines of code.

So stateful animations exist where static and dynamic animations overlap.

So declarative versus reactive-- CSS animations are declarative.

It doesn't take any context except for those rare instances where you've got a hover event or something like that.

It does what it's told.

It doesn't take, except in rare cases, a little bit of variables from its environment or its context.

So you, as a designer, as the developer, say what goes where, when, how.

It's very stupid.

It takes orders.

It doesn't think for itself.

So to make declarative CSS act more like dynamic animation, we often use states in the form of classes, like this.

Once it's loaded, the spinner turns invisible.

Opacity is zero.

And we write a little bit of JavaScript to handle that logic there.

We'd offload the logic to the JavaScript.

What this does is it listens for the page loads, then it adds a state class to the body and removes the spinner after it fades out.

And this is very useful for CSS-first UI designers, like people where I came from.

They've adopted this state-based animation very readily.

This is a little animation that my friend Madeline over at Square made.

And I believe she used AngularJS in the process.

And it looks great.

I mean, that's beautiful.

And it's totally state-based.

It degrades nicely in older browsers.

This is what this looks like when you don't have animations enabled on your browser or you're using like IE6.

It jumps from state to state, but those people still get a nicely degraded experience.

It works great.

So for interfacers, a framework that supports states like Jangular, it's heaven for them.

But for interaction developers, it's still too declarative.

So while CSS and UI people dream of a better state engine, interaction developers, they want performant manimation models.

And what do developers do when they want something that isn't available to them? They develop it themselves.

So this guy, he's an animation library developer.

He builds JavaScript libraries to animate stuff because we don't have any open source APIs or anything that would come in and fill in that void.

He is doing for himself the developer way.

This guy is often our hero.

Sometimes, he comes from Flash.

Sometimes, he didn't come from Flash.

But he saw a need, and he's like, I'm going to fill that need.

Sometimes, he's in-house.

Sometimes, he's on his own.

A brave and valiant noble figure standing in the wind.

Sometimes, he has a startup, and he wants to somehow get paid to do this.

And man, I feel for him because I want to get paid to do animation stuff, too.

But, it's important to keep in mind that animation library developers usually build for their own processes based on their own experiences.

Currently, we have GreenSock, GreenSock Animation Platform, a.k.a.

GSAP.

It's the current heavyweight for Flash-like animation.

And this used to be a Flash tweening library.

But the people who run GreenSock were clever enough that when they saw that Flash was on the way out, they rewrote it in JavaScript.

And currently, it is the darling amongst people who used to use Flash and is gaining more and more traction among people who wish that there were something like it available to them natively in the browser.

But there isn't.

There's another contender-- VelocityJS.

It replaces jQuery's laggy animate function.

And it's also quite-- there's no really cool logo for Velocity.

They gave me a very sad looking V.

So I just took a screenshot instead.

I thought it was much more cool.

But Velocity does a great job of replacing jQuery's laggy animate feature.

And the developers will tell you repeated-- sorry, developer-- will tell you that it's not JavaScript animation that's laggy, it's jQuery's animate function.

But the interesting thing is for all of-- those are just a couple.

A lot of animation libraries get abandoned.

And there's a reason for that.

It's hard to maintain animation libraries.

The people who use them often are too busy to keep maintaining them.

Or they're building them in-house and they can never show them to the outside world.

Or they don't have the resources to maintain them publicly.

Or they don't want people interfering with their processes.

Or their bosses wouldn't like it.

There's all kinds of reasons why a lot of animation libraries are never released to the public or die on the vine.

So that's why we don't have a lot of contenders right now.

Animation libraries are beasts to maintain and a beast to support for more than a couple of people.

It wasn't always like this, though.

And I realize we're reaching an era where there might be people in the audience who weren't here during the era of Flash.

So I'm using my magical cartoonist powers to take us on a history lesson.

Once upon a time Flash, the benevolent dictator, ruled over all and forced everyone to use the same workflow and the same tools.

And goddamnit, we had a visual timeline tool.

All were united, whether they liked it or not.

But then, Steve Jobs announced that Flash would never be on the iPhone.

And thus, the error of copy and content was ushered in.

And the interaction developers did leave the community and pouted in a corner for a very long time.

Developers, ridiculed at events, [INAUDIBLE], exiled into the desert.

Web design stepped back to a more stateful, copy-oriented place.

Schools stopped teaching Flash.

And a generation grew up with no concept of what could be.

With no HTML alternative, they never knew what was possible or even out there.

They only knew stateful CSS animations.

And they fell in love with them.

So with no tools, no performance, no coverage, no stability, a jaded old guard looked on as new ones struggled to find their way.

But then, everything is about to change.

Intentionally left blank.

So this is the Web Animation API.

And you may or may not have heard of it.

Can I see a show of hands of people who've heard of this? Oh uh, that's sad.

It's a W3 specification.

It is a unified language for CSS and SVG animations.

You're going to hear more about those SVG animations from this lady in the front here, Sara Soueidan-- yay-- tomorrow.

Be there.

It will open up the animation engine for tool developers and those wonderful library developers, alike.

Everybody is going to get their chance at it.

This is supposed to change the world.

This guy right here is representing a couple of people.

He is a representative of the animation spec authors and browser vendors doing implementation.

And when I say browser vendors doing implementation, right now-- we'll get there, we'll get there.

It was two and a half years in the making and features have been rolling out in Firefox and Chrome nightly for over the past six months.

So that's coming along.

Seems like it's about to happen.

But every time I would speak to the interaction developers, they said, I miss a lot of things from Flash.

I miss performant animations.

I miss motion paths, callbacks, nesting and sequencing, and just simple, pause, playback and reverse, and seeking, all these things.

He goes, you can't get that with simple declarative CSS animations.

And I don't think that the Web Animation API is offering any of those.

But actually it does.

They're buried in the spec.

You have to read a lot of it.

Most of the people I spoke with, they'd never read the spec.

And they had a lot of questions.

Some people were like, I've never heard of that.

Others were like, I think I looked at that once a year ago.

And it was huge.

And I didn't have enough time in the bathtub, so I didn't bother.

And some people were like, nah, I'm not convinced.

But they had some questions.

And I'm going to answer them.

So, support.

Right now, it's mostly Mozilla that's writing the spec.

Chrome has been doing a lot of the implementing.

As far as Internet Explorer, they have it under consideration. (WHISPERING)

"Under consideration."

Need some more air quotes.

Safari.

Safari-- the browser that railroaded in CSS animations, probably so that people who develop for iOS Safari could animate their websites the same way iOS itself animated the user interface-- the animation good user experiences.

Safari was the browser that made CSS animations and transitions happen while we were all chasing each other's tails in the circle about what kind of syntax we should use.

Well, they're waiting to see how developers use this API.

And right now, for those web app engines and devices like Kindle Fires, well, who the fuck knows.

I've sent emails to Jeff Bezos, the owner of Amazon.com.

And while he does reply to my emails asking if he could improve the search functionality for women with size 12 feet to not show them ads for shoes that only come up in size eight, he did not reply to my repeated emails about, so, is that engine going to be Evergreen.

I suppose shoes are more important than what your web app engine is running on.

There is a polyfill.

Thank goodness.

It's being rewritten as a Web Animations Next.

But if you go to the URL at the bottom of this screen, psst, you can see that and its former permutation.

Unfortunately, it has shit performance.

GSAP still outperforms it.

And interaction developers, they're not going to be using it in production in the near future.

But in the future, library developers should be keen on the API's improved performance.

That's right.

It can give you performance boosts.

It uses the same rendering engine as CSS.

So the performance is the same as what you get from using CSS animations.

This will help with ending jank.

However, Cinderella can't go to the ball until she's done all of her chores.

Web Animation API does give animations their own thread, so long as the animation doesn't tie into anything happening on the main thread, such as JavaScript and Layout.

Right now, a lot of stuff puts Layout on the main thread.

But it varies by the vendor.

So you should keep an eye on what your vendors are doing.

So getting around that layout, every time I talked with animation library developers, they always came back to the layout.

Layout is a big issue.

Reflowing layout takes a lot of energy from the browser.

And it's one of the things that perpetuates jank in animations.

They are a rendering engine problem, though.

Right now, we talk about how opacity and transform are the most performant things to animate.

The reason for that is because they don't trigger layout reflows.

But there are other things we can look forward to coming soon-- color, motion paths, absolute positioning.

They are, hopefully, I'm not telling you any names, going to come out soon, which means that they'll also be things that we can animate in see performance boosts from.

Now, taking a shortcut through the GPU.

In the meantime, it's a good idea to get good with will-change while browser vendors work on improving reducing that or triggering layouts and reflows.

Will-change is a nice new CSS property that came out.

And Sara wrote a great article about it for Dev.Opera, which

you should totally read.

It promotes things to their own layer and allows the browser to optimize them in the best possible way.

Usually, that's sending them over to the GPU.

It's kind of the end of that translateZ(0) hack.

I hope it is at least.

All right.

So where do we go from here? We've got this API that nobody has heard of.

And we've got nothing to really replace it except for a handful of animation libraries.

What do we do? Everybody I talked with wanted something different from this talk.

They wanted me to tell you something different.

They had something they wanted me to say, that I couldn't very well end this giving you all of that.

UI designers want a visual timeline tool.

They desperately need ways to manipulate and test their animations because working 100% within code is very tiresome.

The developers, they want browser support and performance.

They can't implement stuff if the browsers that their users are using doesn't support it.

It's hands down not going to happen for them.

A lot of interaction developers work for marketing agencies who are paid a lot of money to just make it work everywhere.

Goddammit, please.

And of course, the library developers, they feel isolated and alone because the standardistas, as they put it, they need to come down from their ivory towers.

There's some super big communication issues going on.

The standardistas, in the meantime, the vendors and the spec authors, they are convinced that if I could just show everyone how well it performs, that they'd all see the light and come into the fold.

I know that's not going to happen because I've spoken with the JavaScript library authors and they really do feel isolated and left out.

It's been a long cold exile in the desert for some of them.

And they don't feel like they're being heard.

They don't feel like there's transparency.

So if they were talking to each other, they'd all already know what each other want.

Instead, everyone is off in their own worlds and they're fretting over their own problems.

Or they're fighting with each other.

But whatever happens, animation is coming and we can't stop it.

Can't stop the animation train.

We're only slowing it down.

We're only getting in each other's way.

So I'm going to tell you what to do.

Even though this is not my job, I'm going to give you a freebie.

Here's how we're going to get through this.

We're going to do it as a family, a family of animation.

User interface designers-- don't be afraid of JavaScript.

Tell your boss you need a day to get up to speed.

Go check out all the polyfills.

Play around with them, play with GSAP and Velocity.

Don't listen to any article that tells you this is better than that or anything.

They're all fighting with each other, anyway, and won't talk to each other or have a civil conversation over dinner.

So just figure out what works for you.

Don't be afraid of it.

Make your own decisions.

Interaction developers-- don't be afraid of new things.

I recommend going to the polyfills page and reading the feature list because it's way shorter than the spec.

The spec is very, very long and intimidating.

It's what I call a three bathtub spec.

It takes you three bathtub refills to read it on your iPad in a plastic bag.

I don't have that much time and my hands would probably just turn into great big meaty prunes if I did that.

So yeah, I don't expect them to have that much time, either.

So, go read the polyfill page.

And then give feedback.

We'll talk about the feedback in a moment.

Because this is also, it's a two-pronged problem here.

Animation library developer-- man, I love you.

But you need to go read that spec.

There is one animation library development company that has read the spec.

And they are GSAP.

And I've got to say to all the other animation library developers, please don't let one company show you up.

It's not that hard and it's in your best interest, read the spec.

Then, go give feedback.

OK.

This is the most well-meaning meaning person of the group.

I have the most to say to them.

Animation spec authors and implementers-- find a better way to get feedback.

Get out of the ivory tower.

Meet the people you're building this thing for.

When people say, I'd like to participate, I'd like to feel some ownership, your response shouldn't be, send an email with this in the title of it to this person here at this mailing list and we will flood your inbox every morning.

Nobody has the time for that.

People who are doing client work don't have time for that.

Nobody wants to be a part of your crappy epidemic process.

It hasn't been updated since God knows when.

And also, designers aren't going to want to come play with you on IRC.

Every once in a while, I will get an email or a tweet or something from a designer friend of mine.

And she says, hey, I got an IRC account.

What do I do? And I say, fuck if I know.

I don't use IRC.

So telling somebody, join an email list and join our conversations on IRC when those people do not use IRC and they do not want your shit cluttering up their inbox is a horrible way of getting feedback.

And that system needs to change.

Or else, you're not going to build anything that this particular user group is going to want to use.

I don't care if it is the most useful thing.

You guys build websites.

You know that if you wait in a corner building something and then you release it to users, even if you've done your best, there are going to be problems.

It's the same with specs.

It may seem transparent just because you left the door open.

But if you don't put a sign out saying, welcome, please come in.

Or put someone out there with candy to sample, nobody is going to come into your house.

It is your job.

You have one job.

You're paid to do it.

I'm not.

Don't let me do your job for you.

So yes, find better ways of getting feedback.

And back in comics, I used to call this technique meeting people in the field.

When I had young ladies who were really into my comics, they would email me every once in a while and say, I love your comics, why aren't you on Facebook.

This is before social media was a word.

And I'd say, oh, Facebook, what's that.

OK.

I'd set up a profile and there I was.

I would post a link every time a new comic went up.

And this is how I was able to get enough followers to make a living to do comics for as long as I did.

It wasn't a living to keep me in comics, but it was a lot better than a lot of other people were making.

You have to go meet people halfway to make them feel invested in something, to make them feel love for you.

And then I've got something for everybody here because I didn't expect so I don't have as many representatives of those four groups here as I would like because you haven't started booing me yet.

I would like to ask you all to respect each other.

I've seen a carousel of personalities.

Some hot, some cold, some reasonable, some antagonistic.

And they've all been great people who are capable of great things.

And I talked about those jokes we like to make about Flash developers, at once, at least, at conference.

And I'd like to say that discriminating against somebody because of their tools can often be just as harmful to a community as discrimination based on race, sexuality, that sort of thing.

It's not healthy.

We shouldn't be doing it.

So this is my favorite quote.

And I wanted to leave us on a bright, bright note here.

This is John Lasseter, CCO of Pixar.

He likes to say that "the art challenges the technology, and the technology inspires the art."

What that means is that only Athena sprung perfectly formed from Zeus's head.

Tool creation is like evolution.

We create new things.

We see how they're used.

We make better things.

We challenge each other.

We do it by sharing and cooperating, not asking other people to comply with what we've given them.

Many of us invest our egos in our tools and processes.

But those things don't define us.

You should look for the common interest, the thread that connects us all.

Web animation is one of many tools we have to build the web forward.

And it is a tool we build together.

So if you want to get involved, I've put all this information at this URL right here.

It's a little complicated if you want to get involved.

I also made this hashtag, #waapi, Web Animations API.

And if you want to talk about it anywhere, just use that hashtag.

And I'll be listening.

And hopefully, the people who are invested in the API will be listening, as well.

And we can have this conversation in public together as a family.

And if you want to talk about animations, I'm always here, I'm always listening.

Thank you.

[APPLAUSE] Come along to the lounge.

We can-- The lounge.

Have some questions.

This is what it must feel like to be on "The Tonight Show."

It didn't occur to me until afterwards.

A few people tweeted it.

But it was when you started talking about Flash being history, that all of the power went out instantly.

Do you think it's their fault? Do you think they have a kind of 4chan-like mafia who are out to how to get us all? I blame poltergeists.

So when it comes to developing animation, how can a developer and a designer best work together on this? I mean, is it a matter of going straight to the browser or is it better if the designer prototypes it in another tool? Problem is right now we're kind of in a difficult place.

There's so many different prototyping tools.

A lot of people are trying to solve this problem.

But at the same time, we don't seem to be making as much headway as the people who are having to solve the problem on their own would like to see.

What I'd like to see, I mean, when people have been faced with big problems like this in the past, I feel like we've always gone ahead and pushed our own ideas out.

There's been some working group that spun off and did their own thing, presented a better idea.

And that might be what's necessary.

But I think first, we need to see what's already rolling out nightlies and make some decisions based on that.

I personally would like to work on a tool that would help people.

And I think we do need the Web Animation API to build that tool with.

There's no other way to tap into the engine to build a visual timeline tool in a browser like Chrome or Firefox without it.

So we kind of have to get over this hurdle first.

And maybe it's not the API we're going to die with, but it is the API we're going to start with.

I have seen Adobe, they've released a few tools that were kind of bridging the gap, I guess, between the Flash editing environment but for HTML.

Do you have any experience with those? Are they any good? I do.

So I've used Adobe's Edge Animate program quite a bit.

But it has some problems.

Once again, it goes back to that Flash era-- you must conform to our process, our code.

The code that it outputs isn't necessarily the code that a JavaScript developer would look at and say, oh, this is really good code.

So you've run into problems with performance in that regard.

But there's also the issue of you're building animations in something that's not a browser.

I mean, if it's destined to be in a browser, shouldn't you be building it in a browser.

My personal hope is that tools in the future will come plugged in directly to browsers so that you could be able to work on animation directly in the target that you're looking for.

So are you from a Flash development background or were you doing animation on the browser before it was cool? I was doing it before it was cool.

(jake) Yeah.

All right.

Excellent.

Yeah.

I wanted to learn Flash.

It was like when I went from comics to web development because I needed jaw surgery.

And cartoonists-- even award-winning cartoonists with hoards of fan girls-- don't make enough to be able to afford insurance in my country.

So I had to get a real job.

And I looked at my skills.

Like, what will people pay me to do.

Well, I do a lot with this web stuff to promote the comic.

I'm sure somebody will throw money at me for that.

And boom, I ended up in front-end development.

And I was just like, I'm going to learn Flash one day and then I'm going to make a cartoon of my comics.

And it'll be great.

And it'll be like "Homestar Runner."

And then two years later, it's like, no, Flash is never going to happen.

Look at that.

They just killed it.

Oh well.

It will never happen.

And then I just gave up into front-end development until I read the CSS spec and saw that there were some timing functions that I could imitate traditional animation styles with.

And now I'm off on this tangent.

That brought back just loads of memories there.

My friends at uni baked me a cake in the shape of Strong Bad.

Anyways, I laughed.

I couldn't even eat it.

It was just so beautiful.

Is it still moldering at your apartment? Oh, yeah yeah yeah.

It's grown to about four or five times the size it was originally.

And it doesn't look like Strong Bad, anymore.

And it gives you diseases if you go in the same room as it.

But it's still so very special to me.

What parts of the web animations spec do you particularly like? And are there any rough corners there that maybe need a bit more thought by the spec people? Once again, I haven't read through the whole thing because I don't have enough time to sit in a bathtub for that long.

But from what I've read of the polyfill, I like a lot of it.

And I think it actually gives the interaction developers and the library authors a lot of the things that they've been wanting.

I think that the issue now is that there is a-- nobody really knows that they're there.

It has a lot of good things in it.

I personally am not unhappy with it.

Although, I'm sure if library developers and interaction developers spend a long time scrutinizing the spec, they would give you reasons that they're unsatisfied with it.

But we need a starting point so they can get in there and start providing that feedback.

Yeah I think the spec is a really rough place to go and learn about this, right.

Because as you said, when I first visited it, like the browser scroll was like, blip, blip blip, blip blip blip, blip blip-- and oh no.

I can't be bothered with this, especially when it takes ages to get to any of the API, as well.

Yeah.

Most of it is a table of contents.

Yeah.

Yeah.

Since we stopped doing the whole vendor prefix thing and actually shipping stuff into stable before it was ready, which is a bad thing to do, but that meant people were playing with these APIs way ahead of time.

We've got a problem now that we have things like the polyfill where people maybe don't play with it for performance reasons.

So we're getting stuck on the feedback side.

What do you think the solution is there? Or is it, just as you say, making feedback super easy? You know, if I were trying to solve this for myself, I would say the easiest way to get the API into production would be to have something like a web app engine that fully supported it and have people developing apps for the web app marketplace that use it.

I know that there are-- I think there's a web app marketplace with Chrome, is it? (jake) Yup, yup.

Yeah.

I believe so.

So that would be how I'd get people using it.

And then I'd wait for the other vendors to catch up.

And then we would have people who'd already been developing skills, already been developing tools, and they would just immediately release a very well-baked product onto the market.

So that's what I personally would angle around.

I mean-- nudge wink-- if you know anybody who's in a position to execute a plan like that.

So when you're working with animation, do you consider 60 frames a second to be the end goal? Or, are there sometimes like for stylistic reasons you want to go for something else? 60 frames per second is overrated.

So when you go to see a film, it's actually running at 24 frames per second.

The reason you don't notice it is because of a thing called motion blur.

And the human eye doesn't actually perceive 60 individual frames per second.

It just mushes them all together to create a blur, like when you take a photo of your friend and they're waving at you and you just see the smear where their hand is.

That's a motion blur.

And they use it in computer animation, as well.

You don't need 60 frames per second.

That's just how many frames per second it takes for the human eye to make its own motion blur based on what's on the screen.

I remember there was this really cool Firefox OS game from Mozilla that they've been working on, and it had motion.

It was 30 to 35 frames per second.

And all the sprites had motion blurs drawn on them already.

So you got away with a much lower frames per second.

And they used requestAnimationFrame AnimationFrame to make sure that it capped.

I wish there were an easier way to cap frame rates so that people can do more with motion blurs out-of-the-box.

It's right now kind of unapproachable for designers to do any animation because you have to know so much about JavaScript to just handle its mechanics.

And it's very, very technical right now.

I suppose also things like refresh rates.

One of things that really bugs me is if I'm watching, like you say, a 24 frame per second film but on a screen, such as a laptop or a TV, that's running at 60.

And there is that sort of a slight judder as 24 frames per second is being crammed into 60, and it's not quite working.

It feels like we need some way for-- I think in video they're working on interesting technology to allow the screen to update at whatever rate it needs to just according to the animation.

There's some fascinating stuff going on there.

When you've been working with the polyfill of an animation library, how, if you're doing a dynamic animation, especially if it's relating to touch or something like that, is the API good enough for that, or do you have to find yourself falling back onto manual requestAnimationFrame style stuff and doing your own computing of numbers? Personally, I haven't gotten that far with the polyfills.

I only discovered a lot of the stuff after I started doing interviews, specifically, so I could write this talk.

And while you're interviewing, you don't necessarily have the time to develop.

So I'm sure that an interaction developer-- who's played around with the polyfill, if I knew any of them, I would totally have gotten a quote from them for this-- would be much better able to answer that question.

So someone was asking me, looking at the Google stuff, their material design, they have page transitions, which is something that Microsoft has like 100 years ago in their browser.

Do you think that's something that we need back on the platform? It's a slightly loaded question because it's something we're thinking quite strongly about.

Could you rephrase that for a moment? If you click a link on a page, what we currently do at the moment is you'd get a white screen, and then everything's loading.

Should we be looking at adding APIs that might do something like load that stuff in the background.

And then once it's in a acceptable state, whatever that might be, you can have a sliding transition or a fading transition into the next page.

I would say yes.

But don't people already build their own P-checks frameworks to do that? Are you saying, do we need to build an API to facilitate that so that it could be handled natively and thus perhaps more efficiently? I would agree with that sentiment.

Cool.

I think that's a good place to leave it.

Thank you very much.

Rachel Nabors, everyone.

(rachel nabors) Thank you.

[APPLAUSE]