What do we call browser’s native development tools?

You know, that panel of tools that allows you to do stuff like inspect the DOM and see network requests. How do the companies that make them refer to them?

  • Chrome calls them DevTools.
  • Edge calls them DevTools.
  • Firefox calls them Developer Tools.
  • Safari calls it the Web Inspector.

I think it’s somewhat safe to generically refer to them as DevTools. Safari is the only browser that doesn’t use that term, but I imagine even die-hard Safari users will know what you mean.



The post What do we call browser’s native development tools? appeared first on CSS-Tricks.

Inspecting Animations in DevTools

I stumbled upon the Animation panel in Chrome’s DevTools the other day and almost jumped out of my seat with pure joy. Not only was I completely unaware that such a thing exists, but it was better than what I could’ve hoped: it lets you control and manipulate CSS animations and visualize how everything works under the hood.

To access the panel, head to More Tools → Animations in the top right-hand menu when DevTools is open:

Many of the tutorials I found about this were pretty complicated, so let’s take a step back and look at a smaller example to begin with: here’s a demo where the background-color of the html element will transition from black to orange on hover:

html { cursor: pointer; background-color: #333; transition: background-color 4s ease;
} html:hover { background-color: #e38810;
}

Let’s imagine that we want to nudge that transition time down from 4s. It can get pretty annoying just bumping that number up and down in the element inspector. I typically would’ve opened up DevTools, found the element in the DOM and then ever-so-slowly manipulate it by typing in a value or using the keyboard directional keys. Instead, we can fire up that demo, open DevTools, and switch to the Animation tab which ought to look something like this:

By default, Chrome will be “listening” for animations to take place. Once they do, they’ll be added to the list. See how those animation blocks are displayed sort of like an audio wave? That’s one frame, or act, of an animation and you can see on the timeline above it each frame that follows it. On an animation itself, the inspector will even show us which property is being changed, like background-color or transform. How neat is that?

We can then modify that animation by grabbing that bar and moving it about:

…and it updates the animation right away — no more clicking and editing an animation the old way! Also, you might’ve noticed that hovering over an animation frame will highlight the element that’s being animated in blue. This is handy if you’re editing a complex animation and forget what that crazy weird pseudo element does. If you have multiple animations on a page, then you can see them all listed in that section just like in this demo:

What we’re doing here is animating both the .square and the .circle when hovering on the html element, so there’s effectively two separate divs being animated in the same time frame — that’s why you can see them in the same section just like that.

I can see that inspecting animations in this way could be super useful for tiny icon design, too. Take this pen of Hamburger menu animations by Jesse Couch where you might want to slow everything down to get things just right. Well, with the animation inspector tool you can do exactly that:

Those buttons in the top left-hand corner will control the playback speed of the animation. So hitting 10% will slow things to a crawl — giving you enough time to really futz with things until they’re perfect.

I’ve focused on Chrome here but it’s not the only browser with an animation inspector — Firefox’s tool is in every way just as useful. The only immediate difference I found was that Chrome will listen for any animations on a page and will display them once their captured. But, with Firefox, you have to inspect the element and only then will it show you the animations attached to that element. So, if you’re doing super complex animations, then Chrome’s tool might be a smidge more helpful.

Animation Inspector Documentation

  • Walkthrough on Google Developers
  • Animation inspector in Firefox – MDN

The post Inspecting Animations in DevTools appeared first on CSS-Tricks.

Monitoring unused CSS by unleashing the raw power of the DevTools Protocol

From Johnny’s dev blog:

The challenge: Calculate the real percentage of unused CSS

Our goal is to create a script that will measure the percentage of unused CSS of this page. Notice that the user can interact with the page and navigate using the different tabs.

DevTools can be used to measure the amount of unused CSS in the page using the Coverage tab. Notice that the percentage of unused CSS after the page loads is ~55%, but after clicking on each of the tabs, more CSS rules are applied and the percentage drops down to just ~15%.

That’s why I’m so skeptical of anything that attempts to measure “unused CSS.” This is an incredibly simple demo (all it does is click some tabs) and the amount of unused CSS changes dramatically.

If you are looking for accurate data on how much unused CSS is in your codebase, in an automated fashion, you’ll need to visit every single URL on your site and trigger every possible event on every element and continue doing that until things stop changing. Then do that for every possible state a user could be in—in every possible browser.

Here’s another incredibly exotic way I’ve heard of it being done:

  1. Wait a random amount of time after the page loads
  2. Loop through all the selectors in the CSSOM
  3. Put a querySelector on them and see if it finds anything or not
  4. Report those findings back to a central database
  5. Run this for enough time on a random set of visitors (or all visitors) that you’re certain is a solid amount of data representing everywhere on your site
  6. Take your set of selectors that never matched anything and add a tiny 1px transparent GIF background image to them
  7. Run that modified CSS for an equal amount of time
  8. Check your server logs to make sure those images were never requested. If they were, you were wrong about that selector being unused, so remove it from the list
  9. And the end of all that, you have a set of selectors in your CSS that are very likely to be unused.

Clever, but highly unlikely that anyone is using either of these methods in a consistent and useful way.

I’m a little scared for tools like Lighthouse that claim to audit your unused CSS telling you to “remove unused rules from stylesheets to reduce unnecessary bytes consumed by network activity.” The chances seem dangerously high that someone runs this, finds this so-called unused CSS and deletes it only to discover it wasn’t really unused.

Direct Link to Article — Permalink


Monitoring unused CSS by unleashing the raw power of the DevTools Protocol is a post from CSS-Tricks