[Applause]

Good morning. Welcome to using Safari to deliver and debug, a responsive web design. My name is Jono Wells. I am an engineer on the Safari and WebKit team with Apple, and I'm really excited to talk to you today. I have a great privilege of being able to develop for the Development Tools that are a part of the Safari web browser. I feel I'm privileged because I love the web, as I'm sure you do. I think Safari is a great browser, a really great platform.

It deserves world-class Development Tools, wouldn't you agree? Especially because we are not just making content in the web browser, we're making content in our apps as well, using web views and so we want that content to run great and look great. So this morning, of course we're going to be talking about Web Inspector, a tool most of you have probably used before, hopefully. We're also going to be talking about a brand-new tool called Responsive Design Mode.

With these two tools together we're going to very rapidly and very smartly improve the quality of our site and get a good solid responsive design as a result. Let's begin by talking about Web Inspector. This is Web Inspector, of course. This is the one you've been working with for the last year.

We've come up with a lot of great new features. We've also gotten some great feedback from you over the last year about the interface. We took a lot of that to heart and we changed things around a little bit so this is the Web Inspector that we're releasing with this release of Safari. Here it is. [Applause]

I suspect some of you may be applauding because there is a dedicated elements tab as you see up there. We have a tab based interface, all the tools that you would expect in Web Inspector are here; resources, timeline, the debugger, the storage tab and a console tab.

But these are tabs so of course you can get rid of ones that you want to get out of your way if there are tools you don't work with as often you can just move them out of the way, you can reorganize the ones that are already there, if you want to bring one back, you just hit the plus button on the right-hand side and open up whichever one you want to. We give you the ability to customize Web Inspector to look more like what you want, to work the way you do. We've made improvements to the interface there.

Now let's talk about what new things we can do with Web Inspector and how it can help us. The first one is, it can help us get great performance out of our content. It helps you get great performance. Now it almost dragoons you to get great performance and we'll talk about how.

What do I mean when I say great performance? The gold standard as I'm sure most of you know, is 60 frames per second, because our screens are refreshing at 60 Hertz, 60 times a second. This means that if we are trying to render a smooth animation, right, for any given rendering frame, right, in a turn of the event loop we need to make sure all of our scripts, our timers, and our layout and rendering can happen within 16.67 milliseconds. If we blow this budget, then our animation will stutter and that's not something that we want. How can we get better information to help us debug the performance of our content? We have this idea.

What if you could just look at the content and every time a paint occurs, we just flash a region of the screen? We added something called Paint Flashing. When you're in the elements tab, in the upper right-hand corner, you will see this paintbrush. Click that, turn that on.

When that is lit up blue, every single time a paint occurs on your page it will light up red with a translucent red box. You're going to want to try this on your content. It going to light up like a Christmas tree. It is amazing! It's going to look like a game of Simon if you ever played that with a kid -- as a kid.

That's going to give you a sense that perhaps you're painting too often, there's too much happening on your page. But what about what's happening behind the scenes? To help you get more information there and get you towards 60 frames per second performance, we've added a great new tool called the Rendering Frames Time Line.

If you go to the time lines tab you can get to it by clicking right here on Rendering Frames and this is the interface you will see. When -- so you can record, use your site and we will start drawing these bars. Each one of these bars represents a rendering frame. They're segmented into different colors based on what is happening in each frame. Purple for scripts, event timers and such, red for layout and rendering and gray for behind the scenes engine work that the engine is doing.

The goal is to keep each of these bars underneath the middle line right here, the 60 frames per second line. If your bars tend to go above that, it means you're possibly not going to be getting 60 frames per second performance and we want to work on that.

You can select a region of the bars just like you can on the other timeline, and we're going to show you a lot of good information about that. First of all, we're going to show you this graph right here, this is an aggregate of the different activity that is happening in that particular region. We're going to give you a breakdown of each frame. You can open up every single rendering frame and see exactly what's happening.

For things like event timers and rendering, style and validation inside of your code we have the ability, of course, to click to the relevant line of source codes so you can see what's going on. We also show you this table of timing information. One of my favorite things to do, I have been using this for a bit, what's been really helpful for me is to sort by total time for reach Rendering Frame and then I open up the one on the top because it is most likely that the most offensive frames are at the top and then I can see what is holding back my performance.

This tool is going to tell you a great story about your content. Even if you think you're performing well, you're going to want to hookup to this and see if you can get additional performance out of your site. It tells you a great story, it allows you to do without thinking, that's really what we want our development tools to do. Just to put the information out in front of you and say here, here it is, you don't have to work too hard to get it.

One of the things that we've been noticing is that you have to jump around between different tools within Web Inspector a lot. We thought it'd be great if you could focus on a particular one. More often if you can just stay in one tool that might save you time.

We've done this in a few ways. One of the ways is for errors and warnings we don't just show those in the console now, we show them in a few other places so that you can spot them more quickly. In the debugger side-bar for instance on the left, any resource that has an error warning we'll just show them underneath, they'll appear so you can just jump right to them.

In all of the JavaScript code in your site, we'll show the errors and warnings in line so you'll see those messages. So if you're just browsing, everything will just show up. It's a lot nicer. We have also improved the way they look in the console so errors and warnings, they're highlighted, the colors are easily distinguishable. They just look better too, we've made the fonts better, it's great.

We have this other idea, and again we want to Do Without Thinking, we want to put important information in front of you. JavaScript of course, is a dynamically typed language. That means that the engine itself assigns the types for you, you don't have to. This is what's happening behind the scenes in this case. Right. We have a string, we have an integer, we have an object.

If you're working with some code, here's a function that's designed to add two numbers together, and this is a mistake that might happen. We're accidentally passing in a string, and so that is going to lead to some unexpected results we're going to call a dysfunction. This is something that you can discover by trying to debug, and play around with your code, might be a, in a more complicated case, might be hard to find this error. But, what if you could see something like this where we just show you as your code is running, we show you the types that have been assigned to all the different variables, passed in as parameters, or return from functions.

We created just such a thing. We call this the Type Profiling Tool. If you look in the upper right-hand corner when you're looking at any JavaScript source you'll see this T button right here. If you click that, from that point forward, when your code runs, your code is going to go from looking like this to looking like this. [Applause]

I love this tool! It's so cool! I've been using it a lot working on Web Inspector. We're going to show you as best as we can type information as your variables are assigned values. You'll also notice that some of the code is grayed out. Since we're tracking what code has been covered, any code that hasn't been reached yet will be grayed out for you. So this also serves as a great code coverage tool.

Right. It going to allow you to see if a function isn't being run or if an else condition isn't being reached, things like that. You'll also notice that we show you the return value from a function. In this case I have a function that's returning something called a DeveloperPerson, it's a class I wrote. You'll also notice that we're showing you the name of that object.

If you have constructer functions, right, like this one, if you're using this classical model using prototypes and you construct an object that way, we will show you the name of the constructer function. We'll do the same thing of course, if you're using ES6 classes which just landed in this release, we'll show you the name of the class. Obviously parameters can get past multiple values over the lifetime of your application. What happens if you have multiple types? For objects here is how we handle it.

Let's say I have a function called register. Right. So we're going to register somebody for a conference or something like that. Say I call it once, and I pass in a new DeveloperPerson. Well, we're just going to show you that it's a DeveloperPerson. If we pass in another object, say a ManagerPerson, we'll show you that.

Let's say we pass in both a DeveloperPerson and a ManagerPerson, then since they both have a common ancestor, person, that's what we're going to show you. If we pass in something else that isn't in this inheritance chain at all like an extraterrestrial for instance, we'll just show you object, because of course everything derives from object, right? Now here are all the different types that we might show you.

If there are multiple types, a string, and a number that get assigned to a value, this is what you're going to see in your code, it's just going to show you many. There is an exception to this, say you have a simple type like a double and it's a double sometimes and it's null or undefined sometimes, we'll just add a question mark to the top, that means it's double sometimes or sometimes it's a null value.

This is such a nice feature, I just want to show you a few more shots. This is code from the Web Inspector. It's just really nice. It gives you a bird's eye view of what's happening with your application. You can quickly spot behavior that isn't interesting to you. Right. Here is an object assignment. Again, you can see the coverage, you can see areas that are grayed out. This has been incredibly useful in my development with Web Inspector, I think you're going to find it just as useful as well. This is the type profiling tool. [Applause]

All right. We have also made improvements to the console. In a similar way we want to be able to put really useful information in front of you without you having to work too hard. Here are some objects that we have launched in the console. And you're going to notice a few things.

The first one is that we're creating -- we give you object preview, so you have really good looking object previews so you might spot information inside your object much more quickly. You're also going to notice something else, every time something is output to the console, we're going to store it in a variable for you. This starts at dollar sign 1 and then dollar sign 2, then dollar sign 3, on and on and on.

You can reference them again just by putting them in the console. This is great. The feedback that we got from you, because these used to represent recently selected elements in the elements panel and the feedback was that really everyone was only using one of those, which is dollar sign 0, so don't worry, that's still the currently selected element, still there, it'll still work as you expect it to, but starting with dollar sign one, those'll be recently logged variables.

That can be really useful, right, if you're paused in the debugger and there's a value in the scope that you want to remember, you no longer have to go into your source code and create a variable just for debugging purposes and then save it, and then run the app, then delete it later, or forget. You don't have to do any of that anymore, we'll take care of that for you. What about when you open up one of the objects.

You're going to see this. It's a lot nicer. First of all, we've just improved the look and used colors to distinguish the different types of information that can be inside of an object. Everyone of the objects inside has its own preview. You'll notice that this is an array, siblings, this one has a special type of preview, we've created special previews for certain things, Maps, sets, weak sets, weak maps, promises.

Right. We show you the types of the objects inside the array and the size of the array on the right. When you open it, we show you the index of each object inside. Of course, each of those have a preview. I want you to notice here that we also have made it a lot easier to inspect the prototype chain so I can then open up the prototype for developer person and for person, and I might see something like this. I love this very much. This gives me the ability to essentially get an API view of my object in the classes that constructed this object. Look at this.

I can quickly spot and see okay, I have a function called change name that takes in a first name and last name. I have a custom setter called firstName. I have a custom getter called fullName. I can tell that because there's an eyeball next to it. I can click on that eyeball and it'll actually run the custom getter.

This is almost better than the documentation in some cases. It is even great for native API exploration, and some of you are probably thinking, I can't remember how local storage works, no problem, just put it in the console. I can see all of the functions, it looks a lot better, it's really nice.

Really great for object exploration, if you're exploring third-party APIs, it's great. It's not just in the console, either. Anywhere we show object views, for instance, if you're paused in the debugger and you have the view of the variables in scope on the right, or when you're mousing over, a variable in the source view, let me show you that - same beautiful object views in all of those places.

Nicely organized for the type of information that is in there, you're going to spot information more quickly and that is really the goal of all of this. I now would like to invite my friend and colleague Andy Estes to come up to the stage and he's been working on a site that he's excited to show you and maybe some of these tools will help him out. Andy. [Applause]

ANDY ESTES: Thank you, Jono and thank you to all of you for being here this morning. I'm really excited to be here and show you these new tools in Web Inspector. First, a bit of a confession, I was up late last night working on this site, I wanted it to look good.

It's supposed to display a bunch of photography I've taken and I think I've introduced a bug and if you don't mind, I just want to see if I can figure out this bug I introduced and fix it real quick so I'm just going to go into Web Inspector.

By the way, if you never opened the inspector before, you do it from the develop menu and you don't have a develop menu in your Safari, it's really easy to enable, you simply go to Safari's preferences, and in the advanced tab you'll see the option, show development menu in mini bar, I already have that checked so I'll just go right in there. I'm going to say Develop, show Web Inspector.

It will open this up along the bottom and right away I see that I have an error here in the console. I can click it, it looks like undefined is not an object, I can jump to the debugger, I even have the error here in the side-bar, I can click it, it'll take me right to the line of code. Let's take a look at this. Somewhere in this line of code I'm seeing an undefined value where I don't expect it.

Now typically what I would do is I would set a break point and maybe spend some time debugging but I don't have time for that, instead I think I'm just going to enable the type profiling to see if maybe that can tell me where my error is. I'm going to click this T to enable type profiling and I'm going to reload the site.

Great, so there's my error. And now my source code is annotated with these helpful pills that tell me the types of all my variables. Let's just see if we can quickly work this out. I have galleries, which is an array. I have current gallery which is an imager.

The result of that shouldn't be undefined but I initialized galleries up here, and one of the things I'm noticing is that the body of my four loop is grayed out, that means that code hasn't been covered, and it looks like that's because gallery data itself is undefined. That's somewhat unexpected, I should be passing a valid gallery data in here. Gallery data itself comes from this variable, this.options, let's take a look at where I set that. I do that up in my constructer for navigation galleries controller.

And it does look like I'm passing a valid object to the constructer, I see the object pill right there. I'm not passing a null or some other kind of type. Let's find where I construct navigation galleries controller and see if that tells me what my mistake is. I'm going to just copy this. I'm going to use Web Inspectors' global search and I can get to that by command-shift-F and it will search all of the resources in the site.

And I have exactly one place where I have a navigation gallery controller, it's right here and I immediately spot my mistake. I was expecting to pass an object that had gallery data as a property, instead I'm just passing gallery data directly. Let's fix that real quick. I can use the convenient ES6 shorthand syntax for declaring a new object that's going to have both the property name as gallery data and also the value as gallery data's value. I made that change.

When I'm editing local files in Web Inspector I can save those changes directly and Web Inspector will prompt me just to make sure I really want to over ride a local file and of course, I do in this case. Once you do that once for a file, it'll never ask you again, it'll just save directly. Let me reload, and see if that worked. There we go, so now I have my beautiful photography that I totally took myself. This is looking really great.

You can see that I have these galleries, I've laid them out so they take up the full width of the display, I can hover over them to see the name of the galleries and I also have this logo in the middle I can hover over that to see a menu that comes out to the side and you'll notice that occasionally these galleries rotate between photos and I have a nice dissolve effect to go from one to the other.

I want to make sure that this transition is as smooth and as efficient as possible so hopefully some of these tools that Jono told us about will help me do that. The first thing I want to do is I want to turn on paint flashing. I'm going to go to the elements tab and the paintbrush tab is here, I'll select that.

Now you can see the red rectangles as the images transition from one image to the next. The first thing I'm noticing is that for the duration of that transition, I see a solid red rectangle, that indicates to me that I'm probably painting every single frame of the transition. Now, I wonder if that's too expensive? What I'd like to use is use the I want to use the frames timeline to tell me whether I'm doing too much work and maybe blowing my budget for a 60 frames per second animation. I can switch to the timelines tab.

And I can see that when I reloaded it automatically recorded a timeline for me so I don't need to do that again. For the most part, you know, this is looking really good. It's looking like I'm staying within 60 frames per second. But there were some frames here that exceeded my budget like this one right here. I can click and drag to select a subset of this and then you can see that it filters the records tab to just include that subset. I can expand some of these and see the work that was done, style and validation, recalculation, time refiring, things like that.

Here's one that's interesting. It's telling me that an animation frame is fired based on request animation frame, it's even telling me that I've invalidated a style and it's going to let me jump right to that line that did that style invalidation. That's right here. In fact, the way this animation is working is I'm using request animation frame and each frame I'm running with a duration of one second, I can even pause here and inspect these values.

Running for a duration of one second and I'm just animating the opacity value from zero to one over that duration of one second. It looks like, at least in some cases, this animation is too expensive to stay within my 60 frames per second budget. I've actually been planning to transition this to a CSS transition instead which I think might be more efficient. Let's do that and see if things get a little better. I'll select this. I still want to set this current class on the image and I'll talk about that later. I want to comment out the rest of this. I can save that local resource. I'll confirm that.

Let's go to the elements tab and I can use the picker to select one of these galleries. I'll choose this one. Down here we can see that there are three images that are stacked on top of each other. The one with the current class right here, is the one that's currently being displayed.

In the side-bar I can actually see what style properties that current class has. Right now it is Z index 3. Let's add some more properties here. For one I want to animate its opacity -- or I want to set its opacity to one then I want to use a transition to animate opacity over one second using a linear animation curve. I'm going to make those changes. I'm going to save again and I'm going to reload the page.

Great. Right away you can see that there is almost no flashing going on here. There is an occasional flash in the beginning and the end, but for the rest of the time there is no flashing whatsoever. That indicates I've gone from doing software compositing in my request animation frame code to letting the engine do -- to composite the opacity and hardware which is going to be a much faster, smoother experience.

This is looking pretty good but I'm actually seeing a problem. I did see one frame animate but then none of the others did. It looks like I might have introduced some sort of bug. Let's see if we can figure out what that is. I happen to know that in my code I am -- that there's show next image right here. Show next image returns a promise -- let me reload so we can actually hit my break point.

Show next image is going to return a promise, when the promise is resolved I'm start a timeout for the next animation. We can even log the promise here, show next image and it is going to tell me that the state is pending. This may not be surprising that it is pending because I'm pausing the debugger, I might not have let the code that will eventually resolve that promise run, so let me resume here.

These start animating every 2 seconds, and so by now this promise should be resolved if everything is working correctly. Even though I'm no longer pausing that function, I still have that promise bound to dollar sign 1 so I can just inspect it again. I can see that it's still pending. I actually think I know the mistake I made.

I'm going to go back to my animation frame and I can see here that I was resolving the promise at the end of the request animation frame. The last animation frame but I'm not doing that with the CSS transition. Let me just fix that real quick. I'll use an on transition end listener and resolve that. Let me save that change and reload.

And of course I hit my brake point again. So let me reload again. Great. Now we see these smooth hardware accelerated transitions, everything seems to be looking great. We can see how we can use these powerful features like type profiling, paint flashing, Rendering Frames timeline, improved console, improved debugging to quickly identify our issues and fix them. Thank you, and back to Jono. [Applause]

Thank you, Andy. So I think you're going to find really great use out of this tool. You're going to want to take the new features in Web Inspector, make your site faster, use the paint flashing tool, use the rendering frames timeline and try this in iOS, this works of course, if you're connected to a web view, or Safari on iOS, you should really try this out. Performance is particularly critical on those devices. Make your code better. Use the type profiler to get a lot of great information, play with the console, play around with native APIs. Right. Use these to work smarter and to work faster.

That's what we have introduced with Web Inspector. Now let's go ahead and talk about a new tool. It is called Responsive Design Mode. It is new in this release of Safari 9 and we'll show you what it is in just a moment. First I want to talk about responsive design for a moment and why it is particularly important now. I'm sure most of you know what responsive design is, it is making sure that your content will automatically fit and give a great experience for any screen size. It is particularly important that you do this correctly.

Now, up until this point some of you may have said, well, I can just, you know, sniff the user agent string, I can figure out what kind of device I'm on. I know that I'm running a web view inside of an app, I know exactly what devices I'm targeting.

So I don't really need to do responsive design the way it was meant to be. We've made that a bit trickier for you now because of multitasking. Now web views might be resizing, you don't exactly know how wide they're going to be and they're going to be resizing without reloading your content.

Right. We want to instead of targeting a device, we want to make sure we're using features like @supports, media queries, source set, serving different pixel resolution images to your users, we want to make sure that our content will stretch to any screen. To help you do that without having to go, and open up the iOS simulator and play around, we have brought to you a new tool that going to help you test your layouts and just make sure that they're properly responsive and give you some ways to test them in the sizes for our devices as well. That's Responsive Design Mode. You can find it in the develop menu and when you turn it on, your content will shrink to this view.

This is Responsive Design Mode. It has a few interesting features and the first one, we have handles on the side so you can stretch your content as small or as big as you want to. It will actually automatically scale so if you want to simulate your content on a giant 70-inch display let's say, you can do that.

We also built in navigation with presets for all of our devices so that you can automatically set it to different screens. We actually have built in all the multitasking configurations in here as well, as you will see in a moment. For the iPads that are up there, you can click, it will show you, it'll automatically resize your content to those configurations We also allow you to test to make sure you're covering 1X, 2X, and 3X images.

Additionally, we do give you a tool to set the user agent string because you might need to support a very old browser, legacy browser and make sure you get away from using user agent strings to target the different screens that your concept will run on. Right. To be forward thinking.

This tool will help you make sure that you don't break anything when the user agent string changes and make sure that you have properly gotten away from that as well. Now to show you this tool in action and how it can be useful, I would like to bring Andy back up to the stage to take his site a little bit further. Andy. [Applause]

ANDY ESTES: Thank you, again, Jono. Let's just jump right in to Responsive Design Mode. Here we are. I currently have a preset set for the iPad mini 3. Let's also explore some of these desktop sizes. One of the great things about this is I can actually size it to a resolution larger than my monitor. Right now you can see that I have a width of 2536 pixels which is definitely larger than this monitor. So that's useful, but I already knew that my site looked good on desktop Viewport sizes.

I want to make sure that everything works well on iOS devices as well, iPhones and iPads, I can click these and quickly cycle through, here is an iPad error in landscape mode. Here are some of the multitasking modes. If I keep going it'll rotate to portrait and I can also look at the multitasking modes there. I'm starting to notice that in some of these configurations my site -- the Viewport is really too narrow to be useful.

For example, I really can't see much of these photos if I rollover this menu, the text is clipped. This isn't a really good experience. Let's see if I can make some changes to make this -- make my site more responsive at these types of Viewports. I'm going to bring the Web Inspector back up again. One of the great things about this tool is that you can use the Inspector in conjunction with Responsive Design Mode. Let's dock it on the side so that I have more screen real estate here.

Let's turn off the paint flashing which is annoying at this point. Let's do a few quick changes. First off, let's get rid of this logo in the middle since the menu doesn't have room to fit, I don't think it's worth displaying and I also show the names of the galleries on hover so let's set that to display non-grade. In terms of these images, I have so little screen real estate I'd really like them to take up the entire Viewport. Right now I'm specifying that they are using 50% of the Viewport width and height, let's make that 100.

Great. So now I have just one gallery per screen which is really nice. Now you'll notice I have these hover effects which works great on a desktop but on iOS devices you won't have hover and I also don't have my menu it would be great if this text is just always there. Let's explore doing that. I'm going to enable the hover pseudo class here. You see that it displayed. There are a few things that happen on hover. The first is that the UI is capacity one, but let's just make that always happen.

Second, you will notice there is an overlay that goes to opacity 0. Let's just make it always opacity 0. I have my labels all the time which is what I want. One more change I want to make, I went to the What's New in WebKit session yesterday and I learned about this new feature called Scroll Snap Points, and I would love it if as I scroll through the galleries if it snapped exactly to each gallery. I'll try to add that real quick, I'm going to the body tag and I'll do a WebKit scroll snap type, make it mandatory and then I'll do WebKit scroll snap points and in the wide direction I'll repeat every Viewport.

Let's look at that. Perfect. Beautiful, it just snaps right into place as I scroll. I really like that. There is a number of other changes that I have decided to make, and I have actually baked these into a media query that I've added right here. I'll just uncomment that and save it then reload my site.

You can see I added a little text scroll to see more at the bottom, which is nice. I moved my icon to the upper right, it doesn't bring up a menu. And now with these settings -- this is looking good at this Viewport, let's make sure things work well at other Viewports.

If I go to the wider size, I still get my original design, and then as I go down to smaller sizes, I see the narrow Viewport responsive design. This is great. It is really easy to use this tool in conjunction with the Web Inspector to see how your contents look at different Viewport sizes and make quick changes to effect the design. Thank you, and back to Jono. [Applause]

All right. Andy, thank you for showing us that. That's Responsive Design Mode. If you're not doing responsive design for the content of your applications or for your web content, now is the time to start. It is a good idea because, again, something like multitasking just come out of nowhere just like that and mess your content up. You don't want that to happen.

We have added Responsive Design Mode. The focus is on layout, image resolution and being able to stay focused in Safari in the Development Tools so you don't have to leave and go off to simulator or a plug-in of an actual device to test your layouts. We have all the presets for the devices we make, you can set your own presets as you saw, it works right alongside Web Inspector so you can debug as you normally would. This is new in Safari 9. It is a really cool tool. Try it out.

Along with Web Inspector you now have a very powerful set of tools to take your designs, make them smooth, feel great, make sure that they're error free and make sure that they work across different screen sizes. When you leave here please -- first of all, get OS X, El Capitan, get the developer release, if you don't have it already, turn on the develop menu in Safari.

Customize Web Inspector to your liking, play with the interface, because I think you're really going to like it. It is a lot cleaner, everything is a lot easier to find. Play around with paint flashing and the rendering frames timeline. Even if you think that you have the best performance that web content has ever had in the history of all web content, this will tell you something about your site and how it is working on WebKit, how it's working in Safari, right, and you might discover something you didn't know.

Right. The second I use paint flashing for the first time for instance I had a site, I discovered I had some painting happening in the background I didn't want that was stuttering the animation for everything else, I was able to eliminate it. It just happened immediately. It was great. Use the type information profiler.

Right. Take -- we're going to -- this tool, it takes all of the code, makes it look like a light bright board if you ever played with one of those. It's amazing, it's going to give you great information. Play with that. Play in the console with the object views, try Responsive Design Mode. With all of these tools, use them to make your content shine.

Now, it is really important that we get feedback from you. We very much want your feedback on these new tools and so for that, you should send questions or ideas to Jon Davis, he's our web evangelist and you can reach him at [email protected]. We also have these resources here for information on developing with Safari, resources for Safari developers and the Safari developer library.

In the second link right now there is a document called What's New in Safari 9. To learn more about these features, plus all of the new features on the platform itself you'll definitely want to check out that document. Also, we have two labs coming up for Safari and WebKit, we have win right after this session and Andy and I will be there along with many developers and engineers on the Safari and WebKit team to answer your questions. There is another one on Friday at noon. Please come, check it out. We'll answer questions, get help for the content. I hope you enjoy the rest of your conference. Thank you very much for being with us this morning. [Applause]