Can I invite the first two speakers up to take a seat in this awkward-looking coffee area? This is the strangest little faux chat show setup ever.

But there's no coffee.

There's no coffee.

Yeah, sorry about that.

I'm an MC that doesn't do any rap and a host that doesn't provide coffee.

I'm failing in every possible way.

Sorry about that.

So we do have some questions that have come in on Twitter-- so many, in fact, that we're actually trending in the Netherlands on Twitter, which is nice.

So go Fronteers.

Right behind 1st of April.

So thankfully, they haven't-- I was expecting a littering of April Fools.

I don't know.

Unless all of what you said was surprise, I was kidding, then that's kind of nice for that to be absent.

Bram, can I start with you, just because of what you've been saying there about choosing fallback fonts? So I think there's an art in itself in choosing the right fallback font so that you don't get such a big, disruptive flash of-- so FOFT is a new one for me, Flash Of Fallback Text.

Or I think of Flash Of Unstyled Text.

Are there good ways of choosing the right fallback font so that you don't get your layout juddering and reflowing too aggressively? Yeah.

So what you should look for is a font that has a matching x height.

So the x height is the height of the x in the font.

And if the x height of your fallback font matches or roughly matches the height of your fallback font, then the flash won't be that disruptive.

There's also a CSS property called font size adjust which you can use to scale your fallback fonts or you web fonts to some other font, but the browser support for that is really bad.

So in terms of finding font faces that have a similar x height, are there tips of ways to do that? Without wanting to turn it into a Typekit sales pitch, are there ways on Typekit to identify that? Or is that something that you do through a bit of trial and error and a bit of testing out your fonts? It's mostly trial and error.

What I usually do is I create a page where I just have a couple of characters, and overlay them, and then try to make sure that the x height matches.

And then you can pretty quickly see what is similar.

Fair enough.

And on this subject of page layouts changing as things loads, Paul, you were talking about static layouts and having a known structure on the page so that as things load and reflow, you don't get things reflowing very quickly.

Feels like that's something that's been around for a while, knowing or describing the size of the asset so that you don't forget things, like janking around as you move.

Has that got much harder now with responsive web design, and having a bit more of a squishy viewport, or an unknown state? Yeah, definitely.

So in the AMP framework and AMP library, we had to implement our own responsive image tag in order to work around the issues that we would have.

And so the entire pipeline is changed.

So I think it will be extremely difficult to do in a normal environment.

And font is actually an example where we're still not great within AMP, because that's the one exception that can still change the layout.

And I don't have a perfect solution yet.

That's really a tricky one.

I think ensuring when your assets load in that things don't move around, especially if they're loading in later-- it's kind of a tough one.

And I think a few of the talks touched on the theme of fading content, and whether or not that's hiding content, and then loading it in when your assets are there, or if it's for building anticipation, or for any other reason.

It feels like that is-- we're adding some complexity there to make that happen.

Is that a risk? Is that something that we can do as a progressive enhancement, do you think? I think so.

I think it's inherently progressive.

So the navigation transitions that I talked about-- if they're not available, then it will be like before.

So I think it's very progressive.

OK.

And progressive enhancement is a phrase that's come up quite a few times in the questions that have been coming through.

Tobias, there are some questions around providing animations as a progressive enhancement.

First of all, do you think that's practical to do, and also, do you think that's wise to do? Because I know that some animations serve a particular function, serve a particular purpose, and they're not necessarily enhancements.

Would you agree with that, or would you think that there are a class of animations which you can say, OK, this is an enhancement.

It's not core, and if it's missing, it's not a problem? Right.

There's a lot of questions in that statement.

Yes, of course you should and can detect if animations can work.

But I think if-- so let's talk about a modal, for example, if you show a modal.

So if you're doing that without animations, that's absolutely fine.

You're not really losing anything.

It's not core of the thing.

But you can add so much value with that if you show where is modal coming from.

What is triggering the modal.

Tell a story about that modal.

So in that case, it makes total sense to actually look for support and not do that, actually, because you're fine anyway.

So just then skipping to no animations is absolutely fine.

What you have to do, though, is-- like a lot of the things that I showed, relies on 3D transforms to work.

So you're drawing a border by using scale and things like this.

So if the browser doesn't support that, then you're screwed.

So then you'll have to fallback.

And do you think there are ways that you can fallback where you fall back to a simpler form of animation, or is it purely we'll either animate or not? Because you touched on-- you had quite a few tips on the kind of properties that are optimal to animate and some to be avoided.

Is it sensible to step down from one to the other, depending on support, or is it safer to say if I'm not going to get the optimum? I wouldn't do it, just because it's time consuming, but it depends on the value of your product.

If you have a small product and the animations are key, then of course, maybe you can fall back to jQuery or any regular polyfill.

But I'd rather not do that.

Yeah.

I think a theme that's come from a few of these talks is the nature of the design of these animations and the way that we design the typography on a site.

Where do you guys think the best place for that design is to happen? Because particularly, I'm thinking about animations, where the kind of animations we're looking at here, really, you understand what they can do best by experiencing them in the browser and designing them in the browser.

And often, that's not the case on a project.

You'll get a design that has animation as part of it, or that's expressed through user experience design, or through visual design.

Where do you all feel that those animations are best specified and expressed so that clients can see those ahead of time, and sign those off, and that kind of thing? In the browser.

In the browser? Yeah.

We don't really have good design tools to show all the range of possibilities that you could get on the web.

You could come across a browser with no JavaScript support.

You could come across a browser with no web font support.

You could come across a browser with no animation support.

And it's like this huge, two-dimensional matrix of possibilities.

And so the only way to do it is in the browser.

I think that's particularly true of topography, where the font rendering can be so different.

Exactly.

In general, when I meet students that are coming from a design perspective and trying to explore animations, I always advise them to try out Framer, which is basically a browser.

But it's still built for those who are trying to lean in both the development camp and the design camp.

And it's a really good tool to still get the authentic feel of browser animations, but it's a very versatile tool, and it helps you along the way to get a good end result.

OK.

And when it comes to frame rates, we're talking about pursuing that 60 frames per second.

How important is that, really? I think you had some-- you both actually had examples of different frame rates there.

And of course, that's the goal, and we're seeing that as the best possible output.

How much energy should we impart on that, and how good is good enough, I guess is the question? So I think it's super important to hit the 60 FPS, but even more important than that is having a stable frame rate and having a frame rate that syncs with the refresh rate of the display.

Because almost every consumer display out there, every cell phone, is clocked at 60 Hertz, which means that if your frame rate is 40 FPS, then it will always look like crap.

So it's either 60 or 30.

And interesting story here is that with Firefox OS, the very early builds had framerate issues.

And the one app that looked spectacular on the phone was Angry Birds, because game developers naturally know how to cap the frame rate to a certain display refresh rate.

And so Angry Birds was clocked at 30 Hertz, whereas the OS was running between 40 and 50, and that made all the difference.

So I think that's even more important.

So if you can't hit 60, try to hit 30.

And you've been-- I know you've been doing a lot of work on the dev tools in Chrome, and that's getting richer for learning about animations and supporting animations.

Are there particular things that are arriving soon, or that have just landed that are making that easier to try and help people hit those framerates? To hit the framerates, we're always doing improvements on the timeline panel.

It's actually-- it's quite of a pro tool, still, I would say.

It's still quite hard to-- A pro tool, did you say? Pro tool.

So it's still quite hard to get into it.

I hope we can make that easier in the future.

I would like to have some more high level idea of, hey, did you know that you could squeeze out 500 milliseconds by optimizing this on your load time? And with animations, same thing.

Right now, it's still quite difficult to dig in.

I don't have any announcements to make, but-- I wasn't trying to tease something out of you.

I am thinking about the tools that have landed recently, so yeah.

But I would love to have any feedback on the animation inspector.

And we just launched an extended version in Stable, in Chrome Stable, and I would love to hear more if anyone is experiencing it.

Cool.

OK, great.

So I have-- so I'm sorry to do this to you.

I was always nervous about outsourcing the hosting of my fonts.

And I know that Typekit, particularly, is a product that's really widely used now, and doesn't seem to be going away.

The first product that I used that was similar to that was Fontdeck.

I remember when it arrived, I was nervous about providing all of these assets from a third party.

Is that a realistic concern? Is that a fair concern, or is that a solved problem now, and we shouldn't really worry about using a service like this that's going to be providing the access to those resources? Yeah.

It's a really great question, and I think I'm going to answer with a very lame response.

It depends.

Fair enough.

For example, if you're a really huge company, and you have your own house style that includes your own fonts, then by all means, host them yourself.

If you're a web design agency and you develop for many clients with many different types of fonts, then like something like Typekit or Fonts.com

is a very attractive option.

As for reliability, we try to keep our service up as much as possible.

And I think if you handle your web font loading correctly, then it should also be acceptable that they do not load at some point, even though that's not what we want.

So they should be their own enhancement, like I said in my talk.

Yeah.

And I guess the kind of fallbacks that you've been describing-- although the loading state should mean that if there ever is a disruption, it's tiny, and the disruption is minimized.

Paul is not a fan of that last question.

[INAUDIBLE] Oh.

I thought that was you running out.

I saw you-- No.

I'm having a little nose bleed.

I'm going to be back in a minute.

Oh, you're OK? Yeah, I'm OK.

No worries.

OK, cool.

So all of the questions that I was lining up for Paul, that's fine.

We can grab him later on.

That's not a problem.

So one of the things that I'm curious about, as well, is optimizing in the right place.

And the-- I think it's fairly plain when it comes to the kind of things we were talking about fonts, where having a sensible fallback, and then progressively enhancing that, that makes perfect sense.

When it comes to animation, that's hard, I think, trying to understand exactly what the right things are to optimize and what the right things are to target.

Other than frame rate and refresh rate, are there particular traps that people fall into in terms of obsessing over certain kinds of animations or addressing the wrong thing? I think the most common mistake is still not keeping to the best practices.

Something that I think is intuitively also very easy, like an easy trap to fall into, is to have a progress bar and map the width and percentages to the progress.

That makes total sense.

I have 50% progress, and it's 50% width.

And I just see tons of those mistakes-- a progress bar slowly ticking forward and triggering constantly re-layouts.

And I think really what you should focus on is just keeping to the best practices.

Sort of a lame answer, but-- No, I think that's completely fair.

Actually, one of the questions that's been coming in quite a lot-- lots of people are seeing the information that's in these slides and want to know if they can get access to the slides.

Are you guys all going to be sharing slides later on? Yeah.

Yes.

Yes, possibly.

I'm probably going to share a summary, some sort of outline.

Because I used to share all my slides.

The slides are sometimes very useless without notes, so I'm trying to prepare a little bit further and add some more outline to it.

Then I'm going to release something more.

And the other thing to mention, of course, is that all of the talks are being videoed, and the videos are going to be available online later on.

So you can get access to that content there.

There's a big pool of-- a big resource that you've been working on, stateofwebtype.com.

Because one of the things that was instantly on my list is, OK, these practices are changing all the time.

It seems like as soon as I understand how to do typography on the web, the state of play changes, and it's evolving.

Is that a good resource for finding out about support for these different things that you've been talking about, or is there another canonical resource that you would recommend? Well, of course, caniuse.com,

which I guess everybody knows.

But if you want to particularly focus on typography, then the State of Web Type, which I run, is a good place to go.

Excellent.

OK.

So I think we're just about out of time.

So I'd just like to thank, again, all our speakers for our first section.

So thanks again to Tobias, to Paul, and to Bram.

Give them a big hand.

[APPLAUSE]