Using Safari to Deliver and Debug a Responsive Web Design
Safari has a powerful new interface for designing responsive web experiences. Explore this great new feature and other new capabilities and improvements to the Web Inspector—WebKit's built-in development tool. Discover how you can use Safari and Web Inspector to powerfully and efficiently design, debug, and optimize for the web.
JONO WELLS: 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.
JONO WELLS: 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
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.
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.
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
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.
JONO WELLS: 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.
JONO WELLS: 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
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 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.
JONO WELLS: 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 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.
JONO WELLS: 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
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.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.