HTML5 Rocks

HTML5 Rocks

DevTools Digest December 2013

By Umar Hansa at

A number of updated features have made it into the Chrome DevTools recently, some small, some big. We'll start out with the Element panel's updates and move on to talk about Console, Timeline, and more.

Disabled style rules copy as commented out

Copying entire CSS rules in the Styles pane will now include styles you toggled off, they will exist in your clipboard as commented out. []

Copy as CSS path

‘Copy as CSS path’ is now available as a menu item for DOM nodes in the Elements panel (similar to the Copy XPath menu item).

image alt text

Generation of CSS selectors do not have to be limited to your stylesheets/JavaScript, they can also be alternatives for locator strategies in WebDriver tests. []

View Shadow DOM element styles

Child elements of a shadow root can now have their styles inspected. []

Console's copy() works for objects

The copy() method from the Command Line API now works for objects. Go ahead and try copy({foo:'bar'}) into the Console panel and notice how a stringified & formatted version of the object is now in your clipboard. []

Regex filter for console

Filter console messages using regular expressions in the Console panel. []

Easily remove event listeners

Try getEventListeners(document).mousewheel[0]; in the Console panel to retrieve the first mousewheel event listener on the document. Carrying on from this, try $_.remove(); to remove that event listener ($_ = value of the most recently evaluated expression). []

Removal of CSS warnings

Those "Invalid CSS property value"-style warnings you might have seen are now removed. There are ongoing efforts into making the implementation more robust against real world CSS including browser hacks. []

Timeline operations summarized in pie chart

The Timeline panel now contains a pie chart in the Details pane which visually shows the source of your rendering costs - this helps you identify your bottlenecks at a glance.

You’ll find that much of the information which used to be displayed in popovers has now been promoted to its own pane. To view, start a Timeline recording and select a frame, take note of the new Details pane which contains a pie chart. When in Frames view, you’ll get interesting stats like average FPS (1000ms/frame duration) for the selected frame(s). []

Image resize event details

Image resize and decode events in the Timeline panel now contain a link to the DOM node in the Elements panel.

image alt text

The Image URL link takes you to the corresponding resource in the Resources Panel. []

GPU Frames

Frames occurring on the GPU are now shown at the top, above frames on the main thread. []

Break on popstate listeners

'popstate' is now available as an event listener breakpoint in the Sources panel sidebar. []

Rendering settings available in the drawer

Opening the drawer now presents a number of panes, one of which is the Rendering panel, use it to show paint rectangles, FPS meter etc. This is enabled by default at Settings > "Show 'Rendering' view in console drawer"

Copy image as data URL

Image assets in the Resources panel can now have their contents copied as a data URI (data:image/png;base64,iVBO...).

To try this out, find the image resource within Frames > [Resource] > Images and right click on the image preview to access the context menu, then select ‘Copy Image as Data URL’. []

Data URI filtering

If you've never thought they belong, Data URIs can now be filtered out of the Network tab. Select the Filter icon image alt text to view other resource filter types. []

image alt text

Network Timing bugs fixed

If you saw your image apparently taking 300,000 years to download, our apologies. ;) These incorrect timings for network resources have now been fixed. []

Network recording behavior has more control

The behavior of recording network is a little different. First, the record button acts just like you would expect from Timeline or a CPU profile. And because you'd expect it, if you reload the page while DevTools is open, network recording will automatically start. It'll then turn off, so if you want to capture network activity after page load, turn it on. This makes it easier to visualize your waterfall without late-breaking network requests skew the results. []

DevTools themes now available through extensions

User stylesheets are now available through DevTools Experiments (checkbox: "Allow custom UI themes") which allows a Chrome extension to apply custom styling to DevTools. See Sample DevTools Theme Extension for an example. []

That’s it for this edition of the DevTools digest, if you haven’t already, check out the November edition.

DevTools answers: What font is that?

By Paul Irish at

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:

  • DevTools is reporting the actual typeface used by Chrome's text rendering layer. No more guessing which font serif or sans-serif is actually resolving to.
  • Is my webfont working? Sometimes it's hard to tell if you're seeing the webfont or the fallback system font. Now you can verify that the webfont is being applied. In the above example, we're pulling down Lobster as a webfont for the ::first-line style.
  • Fall-through fonts in your stack are easy to spot. Above, we had a typo spelling Merriweather and so it wasn't used, falling through to Lobster.
  • Is that Arial or Helvetica? Ask a designer or… ask DevTools. ;)
  • Works great with Google Webfonts, Typekit, local fonts, @font-face typefaces, unicode glyphs, and all other interesting font sources.

Enjoy and please leave a comment if you have any feedback.

sourceMappingURL and sourceURL syntax changed

By Paul Irish at

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.

Spec Change

The //@ 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 //# syntax 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.

Implementation in Browser DevTools = done!

  • Safari Inspector now supports //# for sourceMappingURL and sourceURL
  • Firebug's change has landed for sourceURL.
  • Firefox landed the change for sourceMappingURL. The sourceURL ticket is here.
  • Chrome DevTools landed the change for sourceMappingURL and sourceURL. It will also warn about use of the deprecated //@ syntax.

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.

Profiling Long Paint Times with DevTools' Continuous Painting Mode

By Paul Irish at

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.

Investigating painting time on your page

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:

  • DOM nodes get changed in JavaScript, which causes Chrome to recalculate the layout of the page.
  • Animations are playing that get updated in a frame-based cycle.
  • User interaction, like hovering, causes style changes on certain elements.
  • Any other operation that causes the page layout to change.

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 you scroll.

If you identify that the repaints cover a big area and/or take a long time, you have two options:

  1. 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 position:fixed, which is often used for navigation elements that stay in the same position, can cause these repaints.

  2. 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

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 about:flags.

How To Begin

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 last measured paint time on the left.
  • The minimum and maximum of the current graph on the right.
  • A bar chart displaying the history of the last 80 frames on the bottom (the line in the chart indicates 16ms as a reference point).

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:

  1. Open the Web Inspector's settings and check Enable continuous page repainting.
  2. Go to the Elements panel and traverse the DOM tree with the arrow keys or by picking elements on the page.
  3. Use the H keyboard shortcut, a newly introduced helper, to toggle visibility on an element.
  4. Look at the paint time graph and try to spot an element that adds a lot of painting time.
  5. Go through the CSS styles of that element, toggling them on and off while looking at the graph, to find the style that causes the slow down.
  6. Change this style and do another Timeline recording to check if this made your page perform better.

The animation below shows toggling styles and its affect on paint time:

continuouspaint screencast

This example demonstrates how turning either one of the CSS styles box-shadow or border-radius off, reduces the painting time by a big amount. Using both box-shadow andborder-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 combination.


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 styles border-radius and 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 general.

Learn more about painting and related topics on

Live Demo

Click below for a demo where Paul Irish uses continuous painting to identify a uniquely expensive paint operation.

Websocket Frame Inspection now in Chrome DevTools

By Paul Irish at

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.

Open up your Chrome Canary or a fresh Chromium build for the latest changes here.

Chrome Developer Tools for Speed

By Paul Irish at
I spoke at Velocity a little bit ago and talked about the Developer Tools in Chrome to improve the speed of your apps. I covered the Task Manager, window.performance, onerror event, console.profile(), console.markTimeline() (now called console.timeStamp()), Timeline view, Chrome's Heap Profiler, and remote debugging. 9 minutes.

ps. chrome teleports goats. that's what i heard.

7 minute videos: Javascript Console Protips & newish DOM APIs

By Paul Irish at

I recently recorded some videos from the comfy red chair in our office. Probably some useful things here to learn.

Level up on the Javascript console in the Chrome DevTools. Look at XHR requests, learn console helper functions to monitor events or explore objects better. We dive into all sorts of goodies in the command lines API: console.time, $0, inspect(), $$, monitorEvents(), keys(), values(), and copy().

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 classList, dataset, matchMedia(), textContent, and matchesSelector() are explained and demonstrated.