• Tools for Auditing CSS
  • By Silvestar Bistrović
  • Translation from: The Gold Project
  • This article is permalink: github.com/xitu/gold-m…
  • Translator: Hoarfroster
  • Proofreader: Zenblo

No way, 1202 years ago, you still don’t know these tools for checking CSS??

Checking CSS is not a common task in a developer’s day to day job, but it is sometimes necessary. Maybe this is part of a performance check to check for faulty CSS or remove unused selectors. Perhaps as part of an effort to improve accessibility, all colors used in the codebase are evaluated against each other. Maybe even to enforce consistency.

Whatever the case, when it comes time to check out my CSS, I usually use the tools I’ll show you next. But before we do that, let’s take a look at checking CSS for exactly what it is.

directory

  1. Development tools in the browser
  2. Online tools
  3. CLI tool

Checking CSS is difficult

In general, code review involves analyzing code to find bugs or other irregularities, such as possible performance problems. For most programming languages, the concept of checking code is relatively simple: does it work or does it not work? But CSS is a special language, and errors are mostly ignored by browsers. And the fact that we can implement the same style in so many different ways makes CHECKING CSS a little tricky — to say the least.

Using extensions to your favorite code editor, or setting up a CSS linter or CSS code checker may help you catch these errors in time, but that’s not what I want to show you here, and we shouldn’t stop there. Because we can use too many colors, typographic definitions, or Z-index values, all of which can make a CSS code base messy, unmaintainable, and unstable.

To really examine CSS, we need to dig deep and find those areas that are not considered best practices. To find these places, we can use the following tools:

Built-in browser development tools

Let’s start with the Chrome DevTools CSS checker. I’m using the Chromium-based Brave browser here. You might also want to check out this post by Umar Hansa, who compiled a bunch of “great” DevTool features to be released in 2020.

If you prefer to check your CSS code manually, we can use the Inspect tool to find out which CSS code is applied to a particular element. Using “Inspect arrow”, we can even see those extra details about color, font, size, and accessibility.

Inspector for Grid and Flex

There are many useful utilities and details in the DevTools interface, but my favorites are the Grid and Flex checkers. To enable them, go to Settings (a pinion icon in the upper right corner of DevTools), click Experiments, and then enable CSS Grid and Flexbox debugging. While this tool is primarily used to debug layout issues, I sometimes use it to quickly determine if A CSS Grid or Flexbox is in use on a page.

CSS Overview

Checking CSS is so basic that everything needs to be done manually. Let’s take a look at some of the more advanced DevTools features.

CSS Overview is one of them. To enable the CSS Overview tool, go to Settings and click Experiments to enable the CSS Overview option.

To open the CSS Overview panel, use the ⌘ Registering P or Ctrl/P shortcut and type CSS Overview then select Show CSS Overview. This tool provides an overview of CSS properties such as colors, fonts, contrast issues, unused declarations, and media queries. I usually use this tool to judge the quality of my current CSS code. For example, having 50 grayscale colors or too many typographical definitions means that the style guide is not being applied, or may not even exist.

Note, however, that the tool makes an overview of the styles used for the page, not of individual files.

Coverage Panel

The Coverage Panel tool displays the amount and percentage of code used on the page. To view it, use the ⌘ Registering P or Ctrl/P shortcut, type Coverage, select Show Coverage, and click the Refresh icon.

You can filter specific CSS files by entering.css in the URL filter input. I usually use this tool to learn about web site delivery techniques. For example, if I see that the CSS coverage is quite high, I can manually generate the CSS file separately for each page. This may not be critical data, but it is sometimes useful to understand the caching strategy.

Rendering Panel

Rendering Panel is another useful tool. To open the rendering palette, use the Ctrl + P or Ctrl + shortcut. This time enter “Rendering” and select the “Show Rendering” option. This tool has many options, but my favorite is:

  • Paint flashing – A green rectangle is displayed when a redraw event occurs. I use it to identify areas that take too much rendering time.
  • Layout Shift Regions – Displays a blue rectangle when a Layout move occurs. To make the most of these options, I usually set the “slow 3G” preset under the” Network “TAB. I sometimes record my screen and then slow down the video to find the layout shift.
  • Frame Rendering Stats — Shows real-time usage of the GPU and frames. This tool is handy for identifying heavy animation and scrolling problems.

These tools give you something you don’t get in a regular review, but I’ve found it to be essential to knowing if your CSS code is performing and doesn’t consume your device’s energy.

Other options may be more beneficial for debugging problems, such as simulating and disabling various features, forcing the use of The Preference-color-scheme feature or print media type, and disabling native fonts.

Performance Monitor

Another tool for checking the Performance of CSS code is the Performance Monitor. To enable it, use the ⌘ Registering P or Ctrl/P shortcut, type Performance Monitor and select the Show Performance Monitor option. I usually use this tool to see how many recalculations and layouts are triggered when interacting with the page or when animations occur.

Performance Panel

On the Performance Panel, we can view all browser events during page loading in detail. To enable Performance tools, use the ⌘ Registering P or Ctrl/P shortcut, type Performance, select Show Performance, and click the “Reload” icon. I usually enable Screenshots and Web Vitals options. For me, the most interesting indicators are “first render”, “first content-rich render”, “Layout shift” and “Maximum content-rich render”. There is also a pie chart showing the draw and render times.

DevTools may not be a classic review tool, but it can help you understand which CSS features are being used, how efficient your code is, and how well your code is performing, which are all key elements of CSS code review.

Online tools

DevTools is just one of the many tools available for checking, but there are other tools available for checking CSS code:

Specificity Visualizer

A Specific Visualizer displays the Specificity of a CSS selector in a code base. Just go to the website and paste the CSS.

The Main Chart shows the relationship between a particular style and the position in the stylesheet. The other two charts show the use of specific styles. I often use this site to find “bad” selectors. For example, if I see a number of specific styles marked red, I can easily conclude that the CSS code here could be improved. It’s helpful to save screenshots for reference as you work to improve.

CSS Specificity Graph Generator

The CSS Specificity Graph Generator is a similar tool for visualizing specific styles. It shows a slightly different diagram that might help you see how your CSS selectors are organized in a particular style. As it says on the tools page, “Spikes are bad, and the general trend should be toward higher specific styles later in the style sheet.” It would be interesting to discuss this further, but it is beyond the scope of this article. However, Harry Roberts does write extensively about this in his article “The Specificity Graph” and it is worth trying.

CSS Stats

CSS Stats is another tool that provides analysis and visualization of your stylesheets. In fact, Robin wrote about it a while ago and showed how he uses it to review style sheets in his work.

All you need to do is type in the URL of the website and then hit Enter. This information is broken down into meaningful sections, including the number of declarations for styles, colors, typography, Z-index, specific styles, and so on. Also, you may want to save screenshots for future reference.

Project Wallace

Project Wallace was developed by Bart Veneman, who has already introduced the Project at CSS Tricks. The power of Project Wallace is that it can compare and visualize changes based on imports. This means that you can see the previous state of your CSS code base and see how your code changes between states. I find this feature quite useful, especially if you want to convince people that the code has been improved. The tool is free for individual projects and offers paid plans for more.

CLI tool

In addition to DevTools and online tools, there are command line interface (CLI) tools that can help us check CSS:

Wallace

One of my favorite CLI tools is Wallace. Once installed, type Wallace, then the name of the site, and it will automatically output everything you need to know about the CSS code for the site. My favorite thing to see is! The number of times important is used, and how many ids are in the code. Another neat piece of information is the number of top-level specific styles and how many selectors use them. These can be red flags of “bad” code.

What I like most about this tool is that it extracts all the CSS code from the site — not just external files, but inline code as well. This is why CSS Stats and Wallace’s report do not match.

csscss

The CSSCSS CLI tool can show which rules share the same declaration, which can be useful for identifying duplicate code and reducing the amount of code you write. I would think twice before doing this, as it might not be worth it, especially with today’s caching mechanisms. It is worth mentioning that CSSCSS requires a Ruby runtime environment.

Other useful tools

Other CSS tools may not be used for checking, but are useful. Let’s list these as well.

  • Color Sorter – Sort CSS colors first by hue, then by saturation.
  • CSS Analyzer – – Analyzes a list of CSS.
  • Constyble – This is a CSS complexity Analyzer based on CSS Analyzer.
  • Extract CSS Now — Extract all CSS from a web page.
  • Get CSS – Get all the CSS from a web page.
  • UCSS – Crawl web sites to identify unused CSS.

conclusion

CSS is everywhere around us, and we need to treat it as a first class citizen in every project. It doesn’t matter what other people think of your CSS, but what you think of it really matters. If your CSS is organized and well written, you’ll spend less time debugging it and more time developing new features. In an ideal world, we would educate everyone to write good CSS, but it takes time.

Make today the day you start caring about your CSS code.

I know it’s not fun for everyone to check out CSS. However, if you’re running your code against any of these tools and trying to improve even one part of your CSS code base, then this article has done its job.

If you find any errors in the translation or other areas that need improvement, you are welcome to revise and PR the translation in the Gold Translation program, and you can also get corresponding bonus points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

Diggings translation project is a community for translating quality Internet technical articles from diggings English sharing articles. The content covers the fields of Android, iOS, front end, back end, blockchain, products, design, artificial intelligence and so on. For more high-quality translations, please keep paying attention to The Translation Project, official weibo and zhihu column.