Chrome DevTools can now tell you exactly what typeface is being used to render text.
Font stacks are a funny thing, more of a suggestion than a demand. Because the family you suggest may not be present, you're letting each user's browser handle the fall-through case, pulling something that will work and using that.
font-family: Baskerville, "Baskerville Old Face", "Hoefler Text", Garamond, "Times New Roman", serif;
As a developer, you want to know what font is actually being used. Here's how it works:
Under Computed Styles, you'll now see a summary of the typeface(s) used for that element. There's a few things to note here:
sans-serifis actually resolving to.
Enjoy and please leave a comment if you have any feedback.
If you use either sourcemaps or sourceURL (both covered in the HTML5 Rocks Primer on Sourcemaps), then you may see a warning in Chrome console like
"/*@ sourceMappingURL=" source mapping URL declaration is deprecated, "/*# sourceMappingURL=" declaration should be used instead.
Here's what that's about:
//@ sourceMappingURL was found to have a conflict with IE whenever it was
found in the page after
//@cc_on was interpreted to turn on conditional
compilation in the IE JScript engine. A legacy version of the HTML5 Shiv is one
particular offender here.
//@ sourceMappingURL syntax is defined in the Sourcemap V3 spec
It was changed there to use
//# syntax instead.
//@ sourceURL is also defined in the spec and was made to match the
for consistency. Follow through, for details on
what sourceURL does. It's used by Ember's minispade, Google's concatenate.js, and others. In Chrome,
sourceURL is supported for inline scripts and inline styles, in addition to evaluated JS.
//#for sourceMappingURL and sourceURL
While these changes make their way to stable release, you can use both syntaxes simultaneously for full tool support or migrate immediately to the
# syntax, depending on your needs.
Continuous painting mode for paint profiling is now available in Chrome Canary. This article explains how you identify a problem in page painting time and how you can use this new tool to detect bottlenecks in painting performance.
So you noticed that your page doesn't scroll smoothly. This is how you would start tackling the problem. For our example, we'll use the demo page Things We Left On The Moon by Dan Cederholm as our example.
You open the Web Inspector, start a Timeline recording and scroll your page up
and down. Then you look at the vertical timelines, that show you what happened
in each frame.
If you see that most time is spent painting (big green bars above 60fps), you need to take a closer look at why this is happening. To investigate your paints, use the Show paint rectangles setting of the Web Inspector (cog icon in the bottom right corner of the Web Inspector). This will show you the regions where Chrome paints.
There are different reasons for Chrome to repaint areas of the page:
As a developer you need to be aware of the repaints happening on your page.
Looking at the paint rectangles is a great way of doing that. In the example
screenshot above you can see that the whole screen is covered in a big paint
rectangle. This means the whole screen is repainted as you scroll, which is not
good. In this specific case this is caused by the CSS style
background-attachment:fixed which causes the background image of the page to
stay at the same position while the content of the page moves on top of it as
If you identify that the repaints cover a big area and/or take a long time, you have two options:
You can try to change the page layout to reduce the amount of painting. If
possible Chrome paints the visible page only once and adds parts that have
not been visible as you scroll down. However, there are cases when Chrome
needs to repaint certain areas. For example the CSS rule
which is often used for navigation elements that stay in the same position,
can cause these repaints.
If you want to keep your page layout, you can try to reduce the painting cost of the areas that get repainted. Not every CSS style has the same painting cost, some have little impact, others a lot. Figuring out the painting costs of certain styles can be a lot of work. You can do this by toggling styles in the Elements panel and looking at the difference in the Timeline recording, which means switching between panels and doing lots of recordings. This is where continuous painting mode comes into play.
Continuous painting mode is a tool that helps you identify which elements are costly on the page. It puts the page into an always repainting state, showing a counter of how much painting work is happening. Then, you can hide elements and mutate styles, watching the counter, in order to figure out what is slow.
In order to use continuous painting mode you need to use Chrome Canary.
On Linux systems (and some Macs) you need to make sure that Chrome runs in
compositing mode. This can be permanently enabled using the GPU compositing on
all pages setting in
Continuous painting mode can be enabled via the checkbox Enable continuous page repainting in the Web Inspector's settings (cog icon in the bottom right corner of the Web Inspector).
The small display in the top right corner shows you the measured paint times in milliseconds. More specifically it shows:
The paint time measurements are dependent on screen resolution, window size and the hardware Chrome is running on. Be aware that these things are likely to be different for your users.
This is how you can use continuous painting mode to track down elements and styles that add a lot of painting cost:
The animation below shows toggling styles and its affect on paint time:
This example demonstrates how turning either one of the CSS styles
border-radius off, reduces the painting time by a big amount. Using both
border-radius on an element leads to very expensive painting
operations, because Chrome can't optimize for this. So if you have an element
that gets a lot of repaints, like in the example, you should avoid this
Continuous painting mode repaints the whole visible page. This is usually not the case when browsing a web page. Scrolling usually only paints the parts that haven't been visible before. And for other changes on the page, only the smallest possible area is repainted. So check with another Timeline recording if your style improvements actually had an impact on the paint times of your page.
When using continuous painting mode you might discover that e.g. the CSS
box-shadow add a lot of painting time. It is not
discouraged to use those features in general, they are awesome and we are happy
they are finally here. But it's important to know when and where to use them.
Avoid using them in areas with lots of repaints and avoid overusing them in
Learn more about painting and related topics on jankfree.com
Click below for a demo where Paul Irish uses continuous painting to identify a uniquely expensive paint operation.
While before we could see sockets being established, we haven't had inspection ability into the data going over the wire in websockets. Thanks to a WebKit patch from RIM, we can now see the frame data, along with small unicode arrows indicating which direction the data is going.
window.performance, onerror event,
console.timeStamp()), Timeline view, Chrome's Heap Profiler, and remote debugging. 9 minutes.
I recently recorded some videos from the comfy red chair in our office. Probably some useful things here to learn.
In this one, I give you a heads up on recent DOM APIs with good browser support that were designed to make things easier for you. HTML5
matchesSelector() are explained and demonstrated.