After weeks of scraping and analyzing more than 100,000 websites I’m happy to announce: The CSS Selection 2026! This is the biggest ever attempt (as far as I know) to look at CSS from a high level and draw conclusions from usage of new CSS features and anti-patterns. It features even more metrics than the Web Almanac, although I hope it is obvious that the Web Almanac is the giant on whose shoulders this article stands. On top of that it also highlights some insane outliers, just because it’s fun to do, and it may help you feel good about your own situation.

The CSS Selection is a new concept for Project Wallace that I’ve wanted to do for a long time. It has taken tremendous effort to get this across the finish line but now it’s here and I couldn’t be more proud of it. There is also a big list of improvements that I plan on incorporating in future editions so expect this to become even better.

The run up to publishing this has been so much fun. During analysis I’ve shared several statistics and screenshots on social media. People’s emotions ranged from sheer laughter to outrage. The design aspect of the whole thing was also pretty nice to do. I even attempted so make a card-like image for previews on social media. It took a little bit of fumbling, but I’m happy with how it turned out.

Another very cool aspect of The CSS Selection is that it’s publicly sponsored by Polypane. That means that I had to work in a few pieces of sponsored content, but man, does it fit the rest of the content well! I had linked to at least two Polypane articles/pages already before Kilian came on board. It highlights how well Polypane fits this article and I’m proud to now have a second sponsor, next to Netlify, who kindly sponsor the hosting and deployment of this website.

Read The CSS Selection now!

One of the most common questions around analyzing CSS quality is how to detect unused CSS. Shipping unused CSS to the browser is a waste so we want to avoid it! This post shows how to collect CSS code coverage data with the help of @playwright/test.

Table of contents

1. Writing Playwright tests
2. Collect CSS Coverage from Playwright tests
3. Bonus: Analyzing and linting CSS Coverage

Writing Playwright tests

Start with writing Playwright tests for our website. Playwright tests run in a headless browser and they emulate user behaviour to verify that your website works as intended. The Project Wallace website has 230 of these tests. Here is one of them:

import { test, expect } from './tests/fixtures'

test('Navigation: pressing Escape on the popover closes the popover', async ({ page }) => {
	let trigger = page.getByRole('navigation').getByLabel('Additional navigation items')
	let popover = page.locator('.nav-popover')

	await page.setViewportSize({ width: 420, height: 800 })
	await trigger.click()

	// Press Escape
	await page.keyboard.press('Escape')

	// Check that the popover is not visible
	await expect.soft(popover).not.toBeVisible()
	await expect.soft(trigger).not.toHaveAttribute('aria-expanded', 'true')
})

That’s just one test, but imagine you have your whole website covered by these sort of tests. Extensive test coverage is essential for calculating CSS coverage.

Notice the import of a fixture instead of the default import { test, expect } from playwright/test'. In the next step we’ll look at how to collect the data using these tests and why we use this fixture.

Collect CSS Coverage from Playwright tests

Now that we have tests, we can start collecting data! Playwright provides two functions related to CSS Coverage: coverage.startCSSCoverage() and coverage.stopCSSCoverage(). If you combine these functions with Playwright fixtures you can collect coverage data from within your Playwright tests:

type Fixtures = {
	cssCoverage: void
}

export const test = base_test.extend<Fixtures>({
	cssCoverage: [
		async ({ page }, use, testInfo) => {
			// start before test
			await page.coverage.startCSSCoverage()
			// run the test
			await use()
			// stop after test
			let coverage = await page.coverage.stopCSSCoverage()

			// write coverage to disk
			await fs.writeFile('path-to-file.json', JSON.stringify(coverage))
		},
		{ auto: true }
	]
})

You can peek at our implementation on GitHub. That one is a bit more involved because it automatically generates a unique file name for each coverage file and attaches it to the test.

Let’s break it down:

Creating the fixture

This creates the actual fixture and it tells Playwright to automatically set up this fixture for every test.

type Fixtures = {
	cssCoverage: void
}

export const test = base_test.extend<Fixtures>({
	cssCoverage: [
		async ({ page }, use, testInfo) => {
			// etc.
		},
		{ auto: true }
	]
})

Collecting coverage

The core of the fixture is surprisingly small! Start collecting, run the test and stop collecting.

// start before test
await page.coverage.startCSSCoverage()
// Run the test
await use()
// stop after test
let coverage = await page.coverage.stopCSSCoverage()

Write coverage to disk

To be able to use the coverage data later on we need to write it to disk. In practice you’ll give this JSON file a unique name, probably the name or path of your actual test.

await fs.writeFile('./css-coverage/path-to-file.json', JSON.stringify(coverage))

That’s all! Because of the auto-fixture every test will now self-report all CSS Coverage data.

Bonus: Analyzing and linting CSS Coverage

After running our 230 Playwright tests we have megabytes of coverage data that we can start analyzing. As you could read in my previous blog post there are a lot of gaps to fill. On top of that many tests report the same coverage ranges for the same files so there is also a lot deduplication to do. And prettifying the CSS because no-one likes inspecting minified CSS. This is where our new @projectwallace/css-code-coverage package comes in handy. It does all that for us and generates handy statistics. It even ships with a CLI that works as a CSS Coverage linter!

The previous step generated a /css-coverage folder full with 230 JSON files. We’re going to use @projectwallace/css-code-coverage to make sure that our coverage is at an acceptable number:

css-coverage --coverage-dir=./css-coverage --min-line-coverage=.9  --min-file-line-coverage=.7 --show-uncovered=all

See our implementation here as a package.json script.

This command:

• Tells the linter that our coverage JSON files live at ./css-coverage
• Sets the threshold for line coverage to .9 (or 90%) meaning that at least 90% of all lines of CSS combined must be covered
• Sets the threshold of file line coverage to .7 (or 70%) meaning that each individual CSS file must at least have 70% line coverage
• Instructs the linter to report all CSS files that don’t have 100% coverage

This is the result when running it for projectwallace.com’s repository:

The @projectwallace/css-code-coverage package focuses on lines and not on bytes because as developers we also look at lines of code.

Running this CLI in a GitHub action after the Playwright test gives you have accurate test data in each run and helps you catch shipping unused CSS!

The last couple of months I’ve been working hard on improving how we can inspect what parts of CSS are used by the browser and which parts aren’t. There’s some stuff I’m doing to make large coverage reports so you can inspect several pages in one go by combining coverage JSON files into a single one, prettifying all the CSS etc. But there’s one thing that is being consistently troublesome for me:

Browers often don’t report atrule ranges correctly.

‘Often’ doesn’t mean ‘always’, but more than enough that it has bitten me more than I care to admit. It depends on where in they live and whether neighbouring rules are covered. But take this example that I’ve created using Playwright’s coverage API, but I’ve observed this in Edge/Chrome as well:

<!doctype html>
<html>
	<head>
		<link rel="stylesheet" href="http://localhost/style.css" />
	</head>
	<body>
		<h1>Hello world</h1>
		<p>Text</p>
	</body>
</html>

/* style.css */
@media all {
	h1 {
		color: green;
	}
}
@supports (display: grid) {
	h1 {
		font-size: 24px;
	}
}

Which parts do you think are marked as covered by the browser? The @media all {} rule? Or @supports (display: grid) {}. Well yes. No. Both. Neither. Let’s look at what the browser/Playwright generates for this:

let coverage = [
	{ start: 7, end: 11 },
	{ start: 14, end: 37 },
	{ start: 50, end: 66 },
	{ start: 69, end: 95 }
]

It doesn’t mark the whole stylesheet as covered. Instead there are 4 different ranges. Let’s highlight the bits that the browser says are covered, leaving out tabs and newlines for readability:

1. all (Missing @media and opening {)
2. h1 { color: green; }
3. (display: grid) (Missing @supports and opening {)
4. h1 { font-size: 24px; }

And both atrule ranges also miss their closing }.

What I want

Can browsers please:

• Include the atrule name in the ranges
• Include the opening and closing brackets ({}) in the ranges
• Be smart and then mark my example in a single range covering the whole stylesheet

Thanks.

Over the years I have explored several ways to get hold of a website’s CSS. So far I’ve found these three options, each with their pros and cons. None of these methods actually check if the CSS is actually used, they only collect as much CSS as they possibly can.

Table of contents

1. Option 1: Scrape the HTML
2. Option 2: Use CSSOM
3. Option 3: Use CSSCoverage API
4. Summary

Option 1: Scrape the HTML

Project Wallace scrapes websites by fetching the HTML and then going through all HTML elements to grab bits of CSS out of them. This is a fast and cheap way to scrape websites because it does not involve a headless browser but only a handful of dependencies and some clever thinking. More specifically it looks like this:

1. Fetch the HTML document belonging to the URL you’ve entered (this works best in a NodeJS enviroment but in some cases is also possible in the browser)
2. Parse the HTML into an AST
   1. Tip: use DOMParser.parseFromString() if you’re in a browser environment or linkedom if you’re in a JavaScript engine like NodeJS
3. Walk the AST and grab every <style> element
   1. Each <style>’s contents can be added to our CSS as-is
4. Walk the tree and grab every <link rel~="stylesheet">
   1. Grab the href from the <link>
   2. Fetch the href’s contents
   3. Add the contents to our CSS
5. Walk the tree and grab every [style] element
   1. The style contents of <div style="color: red; margin: 0"> can be taken as-is
   2. Make up a selector and rule for the single element (like div in this example), or one selector and rule for all elements with inline styles (inline-styles { color: red, etc. })
   3. Add the inline CSS to the rule
   4. Add the rule(s) to our CSS
6. Recursively scrape any CSS @import
   1. Parse the CSS into an AST
   2. Walk the tree and take each import atrule
   3. Take the url() of the import
   4. Download the contents of the URL
   5. Add to our CSS

Pros and cons

Option 2: Use CSSOM

The CSSOM is a collection of APIs that can be used to manipulate CSS from JavaScript. Part of this is the document.styleSheets property that we can use to grab all the CSS from a webpage. It’s such a small task that I’ll put the entire script here:

CSSOM Example

function scrape_css()
	let css = ''

	for (let stylesheet of document.styleSheets) { // [1]
		for (let rule of stylesheet.cssRules) { // [2]
			css =+ rule.cssText // [3]
		}
	}

	return css
}

Explanation

1. Go over all the stylesheets of document.styleSheets
2. Take the cssRules of each styleSheet
3. Read the cssText property from each CSSRule and add it to our css string. This sometimes causes Cross Origin issues so you may want to wrap that in a try-catch block.

Pros and cons

Option 3: Use CSSCoverage API

Headless browsers and Chromium-based browsers have the CSSCoverage API which can be used to detect which parts of your CSS are actually used and which parts aren’t. A great API in itself but we can also use it to find all the CSS.

CSSCoverage Example

import { chromium } from 'playwright' // or 'puppeteer'

async function scrape() {
	let browser = await chromium.launch() // [1a]
	let page = await browser.newPage() // [1b]

	await page.coverage.startCSSCoverage() // [2]
	await page.goto('https://example.com') // [3]
	let coverage = await page.coverage.stopCSSCoverage() // [4]

	let css = ''
	for (let entry of coverage) {
		css += entry.text
	}

	return css
}

Explanation

1. Create a new browser and page
2. Tell the browser to prepare to collect some coverage information. This must be done before going to a URL if you want to know all the CSS on the page after it loads
3. Go to the actual URL you want to scrape
4. Collect the coverage that the browser has covered
5. Go over the coverage report and extract the CSS

Pros and cons

Summary

Each of these methods has their pros and cons so it really depends on the use case what you’ll end up using.

Hope this was helpful. Did I miss anything? Let me know!

CSS Naked Day is celebrated each year on 9 April. The point is that navigating a website without CSS applied is a powerful way of doing accessibility testing and adhering to Web Standards. How many accessibility flaws is your CSS hiding for you? Just as much as JS might not always be loaded/executed your CSS might not load as well and that’s equally problematic. The official site suggests ways to remove all CSS, but sometimes that’s not practical. Maybe you’re working in a locked-down CMS, or dealing with a complex build setup (hi Vite and SvelteKit). But adding CSS? That’s usually pretty easy.

So this post shows you how to make your website look naked in just 7 lines of code!

[data-theme="naked"] {
	color-scheme: dark light !important;

	&,
	& :is(*, *::before, *::after) {
		all: revert !important;
	}

	& [aria-hidden='true'] {
		display: none !important;
	}
}

Code breakdown

1. Select the document and all elements inside it. For me the data-theme="naked" is applied to the <html> element: <html data-theme="naked">

   [data-theme="naked"] {
   	/* ... */
   }

2. Revert everything

   Modern CSS gives us all: revert and when applying that in my website’s CSS it basically means that it ‘removes’ all of my styles without deleting my CSS.

   [data-theme="naked"] {
   	/* ... */
   
   	&,
   	& :is(*, *::before, *::after) {
   		all: revert !important;
   	}
   
   	/* ... */
   }

3. Set color scheme (optional)

   Wallace has a dark theme by default so here I tell the browser that removing all styles makes the website still dark by default but also respond to a light preference.

   [data-theme="naked"] {
   	color-scheme: dark light !important;
   
   	/* ... */
   }

4. Bonus: hide inaccessible content

   I’m hiding all elements that have aria-hidden="true" because they are only useful visually, not for assistive technology. So that’s why it makes sense for me to hide these elements just to check how I navigate the website without them.

   [data-theme="naked"] {
   	/* ... */
   
   	& [aria-hidden='true'] {
   		display: none !important;
   	}
   }

There is no automation on this site to automatically apply the naked theme on April 9th. That seems a bit drastic for me. You can choose it in the theme picker in the header, though. I do it myself from time to time and it’s really helpful.

‘Only’ 20 releases on the website this month but also lots of releases outside in our open source projects. Strap yourself in for a big list!

New features

Analyze spacing resets.

Sparked by Ana Rodrigues’ talk on CSS Day which showed that she used Project Wallace (yay!) and CSSStats for auditing purposes. Turns out CSSStats does CSS resets analysis which we didn’t offer before. Now we do (since @projectwallace/css-analyzer@7.2.0) with some improvements over CSSStats’ implementation:

• Also check for logical properties (margin-inline, padding-block-start, etc.)
• Account for zero values that have a unit (0px, 0.0vh, etc.)
• Account for shorthand values that are all zero (0 0 0 0, 0px 0 0em 0.0px)

Analyze nesting depth

Initially sparked by the Web Almanac CSS chapter, this has been on my wish list for years and I finally got to it. It wasn’t even that hard to be honest so I’m a little disappointed in myself for not implementing this sooner. @projectwallace/css-analyzer@7.4.0 has all the details and the website now shows how deep you’re willing to go with your CSS.

Atrule composition

For a quick overview of what your atrule game looks like you can look at the new atrules composition chart. It shows an overview of which atrule was used how often. Neat way to get a quick view of the landscape before you dive deeper.

New CSS design tokens library

Our design tokens page has had a panel for design tokens for a long time but now the output is more compliant with the Design Tokens specification. The code to create these tokens moved to a new package @projectwallace/css-design-tokens and it also powers the design tokens page it was extracted from.

CSS Selector complexity calculator page

Because I sometimes wish I had it. Nothing more. The CSS analyzer page shows a graph and table of selector complexity. Because of that it makes sense to offer a standalone tool to test individual selectors quickly.

Updated features

• When Adam Argyle comes on stage at CSS Day you know you’re up for some great takeaways. This year Adam did a talk on scrollers and my first goal was to fix the ugly scrollbars that appear absolutely everywhere! I highly recommend you watch the talk when it appears on CSS Day’s YouTube channel. Until then you can check out the slides on Adam’s website.
• Implemented additional error boundaries and error logging. Sentry kindly offers an Open-Source Sponsorship Plan which allows me to do more fine grained error logging than I could in the free plan. Thanks Sentry for sponsoring!
• We do a ton of syntax highlight across this website but the highlighting in docs and blog posts looked different from everything else. Well, no more!
• The Prettify CSS page now also allows indenting with spaces. But tabs are still default.

Bug fixes

• A while ago (February 2025) we implemented persisted state when navigating from one tool to another: you no longer need to re-enter your URL and hit that button. The page would remember it for you. Great! Unless you were going to the CSS Scraper page. It would forget. What an odd one. Well, that’s fixed now. Going to get-css keeps the CSS you’ve scraped before.
• Syntax highlighting the CSS input field on the AST Explorer page would often fail miserably. Now it fails less often and a little less miserable.
• When searching for a custom property that contained an uppercase character you’d always be disappointed. Not just by how life treats you but also because Wallace was shit at comparing characters. I taught him a lesson and it’s such a good boy at finding your properties now.

Dependencies

• Updated @bramus/specificity to 2.4.2 to fix a crash that would sometimes occur when people write CSS like :nth-child() or :has() without any contents inside the parentheses. Happens to the best of us.

Website analytics

• Visitors: 4.2K
• Page Views: 8.3K
• Top pages: analyze-css (25%), get-css (21.7%), css-code-quality (18%), design-tokens (7%)

Every time I think the monthly update is going to take a little while to put together and every time I am amazed at how much work it is to slap together all these links, images and ramblings into a somewhat coherent post.

New features

• A light theme! For those who prefer a light website or for those standing in bright sunlight.

  

  The idea for this had long been on the todo list but a recent Syntax video opened my eyes and made me bite the bullet. My implementation uses cookies instead of localStorage but most of the heavy lifting is still done by the CSS light-dark() function.

• A ‘naked CSS’ theme! For those celebrating CSS Naked Day.

  

  Fun fact: implementing this was only 8 lines of code!

  [data-theme="naked"],
  [data-theme="naked"] * {
  	all: revert !important;
  	color-scheme: dark light !important;
  
  	[aria-hidden='true'] {
  		display: none !important;
  	}
  }

  But this is also a darn good way of finding accessibility issues.

• The CSS @layer visualizer page already had some devtools panels on it and now also includes the JSON output panel from the css-layer-tree library that powers it. This allows for easy copy-pasting so you can use the result somewhere else.

• The Custom Property Inspector now also has some devtools panels, like a network panel and a panel with the JSON output of all the properties that were inspected. In there you’ll find arrays of All properties, Unused properties, Undefined properties and Underfined with fallback properties.

• The selectors you enter on the Specificity Calculator are now synced to the URL for easy sharing.

• New website analytics. After saying goodbye to Fathom last fall after many years of using it I found myself needing a new source of analytics. Sentry catches the occassional error but when Sentry stays quiet I get nervous, because how do I know if anyone is still using the website? Luckily Counterscale is a free, performant and privacy-focused solution!

  

  I haven’t looked at my ‘old’ numbers but I have the feeling that there are more page views and visitors than a year ago. Over 4000 visitors and almost 8000 page views seems like a lot! The high number of page views for the CSS Scraper is surprising but according to Google they have been sending more traffic that way so I guess that checks out.

  It’ll be fun to an end-of-year summary again although I need to keep track of these numbers myself because they’ll be gone after 90 days.

Updated features

• Removed the resizeable panes from the AST Explorer and Custom Properties Inspector pages. Paneforge is great but for some reason the panes would always collapse on initial page render without a good reason and even worse: no errors logged.

Bug fixes

• Clicking a used property in the custom property inspector sidebar would always scroll and highlight the declared property, not the used one. This is now fixed.
• Guess what? Some of our own custom properties were broken. Using the custom property inspector helped me find and fix them 🙈
• Several unlisted bugs that Sentry caught. Several. Take that from me.

Dependencies

• All of the @projectwallace packages are now ESM only for a smaller install size, mostly cutting their node_modules size by 50%
  • https://github.com/projectwallace/css-analyzer
  • https://github.com/projectwallace/css-layer-tree
  • https://github.com/projectwallace/color-sorter
  • https://github.com/projectwallace/css-code-quality
  • https://github.com/projectwallace/format-css
  • https://github.com/projectwallace/css-time-sort
• Previously all tests for this website were done by Playwright. Now they’re split into unit tests (Vitest) and end to end tests (Playwright). This makes discovering bugs a little easier because of a better distinction in CI.
• Implemented Stylelint in the repository powering this website. Only a fairly basic config, but helpful nonetheless.

Performance

• Previous release notes mentioned a performance improvement for syntax highlighting blocks of CSS. This is now updated from a arbitrary setTimeout() to requestIdleCallback() if supported by the browser.
• The theme switch, navigation popover and CMD+K menu were previously powered by a Melt popover. They’re now fully HTML popover elements! Hooray for the web!

There are fewer notes than usual but that’s because the weather here has been very nice and I’ve been doing a ton of gardening and chores around the house. I highly recommend going outside more! After all, this is just a side project. 😉

35 production releases this month, 4 less than last month. And almost half of those were related to replacing Tailwind CSS with ‘plain’ CSS and Svelte component-based styles. Yup I finally did it.

Apart from that most effort went into making existing more resilient and adding more test coverage to increase stability.

New features

None this month.

Updated features

• The filter buttons in the network panel have been removed. Before this you were able to filter network resources by type like link tags or style tags. It occurred to me I hadn’t used this feature in years and had no test coverage for it. Additionally the usage differed a little from how the checkboxes in front of the network resources worked so I decided it’s time to let go.
• Aria attributes in sortable table columns have been added in places where they were missing and improved in places where they were already present. Under the hood this involved a bunch of deduplication whic akes it easier to do it right next time.

Bug fixes

• 💥 Do not crash when @font-face contains invalid CSS
• 💥 Do not crash when someone enters a non-URL in a URL field to analyze

Dependencies

Dropped Tailwind CSS, autoprefixer and postcss. There, it’s out there. I still like Tailwind, it’s been good for me the last couple of years. But there’s this itch that tells me that this silly website about CSS should be written in CSS. But even more so I feel I need to reconnect with modern CSS and learn more about view transitions, cascade layers (aka @layer), container queries and theming. So, consider this my first step trying to ship a light theme or a dim one. Or both.

Even though I’ve tried to do the migration in small pieces you may still occasionally see some broken styling here and there.

I even implemented a rudimentary layer architecture right after I finished the migration!

Performance

• Syntax highlighting of <pre> blocks is now postponed 100ms. This should give the browser some breathing room to first apply layout and paint and do syntax highlighting after that. This is mostly noticable when opening our devtools, like when you click a specific color or selector.
• Additionally we now keep track of highlighted strings that we also clean up when the <pre> element is unmounted. This solves a memory leak that was actually noticable after analyzing lots of sites.
• The network panel used to keep a full copy of all resources in memory. That’s right, even with all the CSS that you downloaded. So your CSS could be 1MB and we would keep another 1MB in memory just so you could sort the whole thing by size or URL. Well, now we store the sorting in a Uint8Array that’s only as long as the amount of network resources you have. Phew.
• Sorting design token colors by color would always convert every color twice. It’s now faster because we first map the entire array and then sort the result. This is faster because converting the color is relatively slow.

Resilience

Lots of tests were added this month for the AST Explorer and CSS Coverage pages. This helps me add features more easily because Playwright will warn me when I break something. (not if; when)

Do you enjoy these release notes? Please let me know via BlueSky or LinkedIn.

That’s it for this month!

39 production releases with performance improvements, bug fixes and a couple of new features. Let’s start with an absolute banger!

New features

This one has been on my list for ages and the recent upgrade to Svelte 5 and this video from Huntabyte about Svelte 5, context and classes helped me get it over the line:

🎉 CSS is maintained between page navigations

You rarely audit one website or file in isolation. Wallace has many pages and depending on the CSS or the goal you want to either check code quality scores, CSS @layer composition or custom property usage. Before this change you always needed to re-enter the URL or upload the file again. Well, no more! Click to another page and the CSS will still be there.

Other new stuff

• The CSS Scraper pages now has it’s own network panel. It’s the same one you’re familiar with from the analyzer and layers pages. While writing these release notes I spotted a very nasty UI bug so expect that to be fixed soon.
• Pseudo classes analysis because this is rather useful when looking for usage of :popover-open or other new-ish selectors that might not be readily available yet in all browsers.

Updated features

• Syntax highlighting in the AST Explorer input field. It was a tricky one, but some blog posts from GitHub and Sentry helped me along the way to finetune it. We’re (still) not using a virtualized list because the input for the AST Explorer is usually quite small and doesn’t warrant the overhead of such a tool.

• Syntax highlighting in item usage devtools.

  

  After implementing sytax highlighting in most large <pre> blocks I fgured it was time for smaller chunks of code to look nice too.

• Calculating the diffstat on the CSS Diff page is now a lot more accurate on large diffs as well as being a bunch faster. I’m really into using typed arrays in JavaScript lately, so the diffstat is now a Uint8Array() with 5 integers: 0 for unchanged, 1 for deletions and 2 for additions.

  

Split panes

The AST Explorer was the first page where I implemented the excellent PaneForge library to have resizable elements. I liked the ability of dragging interface elements so much that this is now available in the following places:

• AST Explorer
• Custom Properties analyzer
• CSS Coverage analyzer
• Devtools networkpanel
• Devtools item usage

Resize and render performance isn’t exactly great in some of these places when bombarding it with big CSS input, but it’s on my radar and some day I’ll fgure out how to tackle that.

Dependencies

• @bramus/specificity version 2.4.0 was released and contains some of my own fixes and improvements so projectwallace.com now also uses the latest and greatest.
• css-analyzer v6 is released and it contains some long overdue breaking changes and some bug fixes for issues that I was able to spot because Sentry flagged them.
• css-code-quality v2 is released as an effect of releasing css-analyzer v6. It depends on the analyzer and had one deprecation to be removed.

Performance

A lot of the sorting functions used on the analyzer page are now faster because we store the sorted elements in a Uint32Array() instead of creating copies for every single list. This is worth a blog post on it’s own, so I’ll probably postpone that until… Well. Long.

A lot of this month was preparing releases, upgrading dependencies across the board and making sure nothing broke in the process.

Do you enjoy these release notes? Please let me know via BlueSky or LinkedIn.

That’s it for this month!

January has been a very busy month with over 40+ PR’s merged to production and two new major features added. Here are the most important changes for you.

New features

• CSS Coverage viewer.

  

  This deserves a blog post in itself because it’s quite a big one. DevTools like in Puppeteer, Playwright, Chrome and Edge provide an option to inspect what portions of CSS are actually covered. Playwright and Puppeteer allow to keep track of coverage across pages but it’s hard to inspect. Our new viewer accepts a coverage JSON file, prettifies all the CSS (and adjusts the coverage ranges) and shows you which lines are covered and which are not. This is also the first page where I’ve implemented the loading an example file. This is an advanced tool and getting a coverage JSON isn’t that easy for most developers.

• CSS AST Explorer

  

  Almost every tool on Project Wallace uses CSSTree under the hood. ASTExplorer.net is a tools that visualizes AST’s like the ones generated by CSSTree. However, ASTExplorer is not running the latest version of CSSTree, so in the interest of learning a new skill and getting a useful tool out of it I created this page as well as opening a PR to update CSSTree at ASTExplorer.

Updated features

• Many sections of the css analysis and design tokens pages can be sorted by source order or by count. Many of them can now also be sorted alphabetically. This can lead to better discoverability of issues. Try sorting media queries or selectors alphabetically and you’ll see why this exists.

  

Design tokens

So many changes happened in the Design Tokens page that it warrants it’s own section.

• BREAKING: Design token $extensions were renamed from project-wallace.css-authored-as to com.projectwallace.css-authored-as to align with how the spec suggests authors to prefix their extensions
• Design token names are now hashed for easier readbility and smaller JSON output.
  • Before: black-rgba(0, 0, 0, .1)
  • After: black-1755eb96.
• Font family tokens are now automatically unquoted.
  • Before: ['"Arial Black"']
  • After: ['Arial Black']
• Duration tokens are now formatted per latest spec changes (duration objects with a unit and value)
• Box-shadow tokens are now formatted per latest spec changes
• Line-height tokens are now formatted per latest spec changes (they’re either a Dimension or Number type)
• Font-size tokens are now formatted per latest spec changes
• Change the file extension of the downloaded JSON to .tokens.json as the spec suggests.

Dependencies

• Updated color-sorter to the latest version (6.1.2). It features a smaller bundle size and uses the latest Colorjs.io package.
• All dependencies were updated to their latest versions, including some security updates.
• Replaced eslint and it’s adjecent packages, making installing packages noticably faster. Linting now happens with OxLint.
• Replaced got with the fetch API and AbortController. This saves 24 extra dependencies but more importantly doesn’t require me to read about breaking changes every time we head into a new Node LTS.

Accessibility

• Some improvements to how we handle (scrollable) tables, like providing tab access to the element that allows the table to scroll; Also added scope="col" and aria-sort in most places where apropriate.

Performance

• Refactored some cases where we would JSON.stringify() some data and later on would JSON.parse() the same data again. This is suboptimal in terms of memory usage, so it’s rewritten to handle plain numbers.
• The custom property tree viewer would pass lots of large objects back and forth. These objects are now a lot smaller, reducing memory usage.
• Avoid thousands of DOM nodes in memory: last year we added an option to use arrow keys to navigate through most lists and tables. To achieve that we used to store every row’s DOM node in memory. It is now rewritten to only store row indexes and do a quick DOM node lookup when necessary which in most cases isn’t even needed.
• Upon inspection we saw that the design tokens JS file contained a lot of com.projectwallace.css-authored-as strings. Moving this to a const reduced the bundle size significantly.
• The design tokens JSON would be generated from a ton of Object.entries() with .filter(), .map() and .reduce(). They’re now a single for (let prop in my_object) {} loop per token type.

That was quite the list. Apart from what’s relevent for you, there have been tons of new unit tests, Playwright tests and dependency updates without user facing impact.

The upcoming months will probably introduce a lot of additional updates to the Design Tokens page. I’m also hoping to spend some time to make your CSS ‘stick’ between page navigations to make it easier to navigate between pages without having to pass in your URL every time.

That’s it for this month!

It’s becoming sort of a tradition to look back on another year working on Project Wallace just as I did in 2022 and 2021. This year marked a change in approach as I focused a lot more on things I wanted to build and maintain and not work on things that didn’t spark joy.

Last year’s ideas

Last year I made this list of ideas, so let’s have a quick look at how it turned out.

1. Update the CSS Analyzer to use Bramus’ Specificity calculator. It’s more correct and saves me a bunch of work in maintaining; Done!
2. Adding a page to the website to quickly calculate specificity. There’s already a bunch of them out there, but like the prettifier, I don’t like context switching; Done!
3. Improving the CSS Code Quality page to use the analyzed CSS to explain the bits that are sub-optimal; Sort of done. It’s better than it was before, but not perfect.
4. Implementing lots of new analysis features, like native CSS nesting, reporting on color formats used and most importantly: calculating total CSS complexity! Still didn’t do nesting and total complexity but instead focused more on features that are broadly used already, like the color formats one and a bunch of others.

Let’s call it a 3 out of 4 score in total. Not too bad, as it shows I can stick to my own plan, but also adapt to my own appetite and user demands.

Celebrating successes

• Project Wallace wasn’t mentioned once, but twice on the Syntax.fm podcast this year. I’ll admit that my heart absolutely jumped when I found out. Fun fact: I used the power of Wallace to submit 2 pull requests to the new Syntax website to improve their CSS.
• The State of CSS survey included Project Wallace this year under the ‘other tools’ section
• I was recognized by several people on CSS Day this year for my work on Wallace (this branded shirt may have helped). It’s a vain metric, but it felt like a validation for all the hard work and I highly enjoyed talking to a couple of you.
• Harry Roberts (of CSSWizardry fame) let me put one of the best endorsements ever on the homepage!

Notable releases

Let’s kick things off by looking at what’s new on the website this year. Some features like the prettifier and the specificity calculator aren’t the best in the market, but they’re small, standalone tools. This fits in my plan to make Project Wallace the online workspace for CSS engineers to hone their skills and ease all forms of CSS auditing.

This year I merged 171 pull requests with all kinds of new features, tests, bug fixes, performance improvements and maintenance work. Yes, I’m using pull requests because I don’t trust myself so I review every change. It also makes sure my tests are successful before I merge. Here’s a summary of the list:

• All kinds of new analysis for the CSS analyzer page
• A page to calculate selector specificity
• A page to prettify CSS
• A page to minify CSS
• A fun little game where you have to guess all CSS units!
• A CSS @layer visualizer page to inspect your layer composition
• A page to lint your unused and undeclared custom properties
• There’s a CMD+K shortcut dialog now to quickly jump to the tool you need
• Lots of performance improvements, like the one I blogged about earlier this year: Making Analyze CSS render 6 times faster
• Rewrote wallace-cli from scratch with only 2 dependencies this time (picocolors and our own css-analyzer)

Interesting numbers

Fathom has been collecting stats over the last year again, so let’s have a look!

Traffic

For the first time ever there’s a slight decrease in these stats. My explanation for this is that last year’s traffic was exceptionally high: twice that of the year before. In my review of last year, I had a suspicion that there is a high amount of passers-by traffic. I guess I’m calling that one confirmed. Traffic last year was also particularly high because of my CSS Complexity blog post. That one is still attracting a bit of traffic but it caused a huge spike last year.

Website activity

Website activity has seen a bit of growth even though traffic went down a little bit. Should I tell my Marketing Director that my engagement tactics are working? I don’t know, I’ll stick to analyzing CSS.

New activities like layer analysis are below 100 completions probably because they are very new and more importantly very niche tools.

Time on site

My friend Jelle showed me a year-in-review blog post recently where the author calculated time-on-site which seems like a fun one to do. Let’s define it as _visitors × average time on site_.

Well, it looks like 2023 is a successful year if you look at the total time spent. Even though the amount of page views and visitors went down, the average time on site went up.

‘Failures’

• Tried to build a browser extension to run the CSS Analyzer in your browser, but building cross-browser extensions is horrible and sharing a codebase between this website and the (open source) extension was not a problem I was interested in solving. There is also an issue with cross-site stylesheets and JS not having access to them that was hard to debug, so I gave up for now. Maybe later.
• Multiple times I’ve tried to do a proper upgrade on the color-sorter for it to support additional color spaces like OKLCH, but my brain could not yet figure out how to do the conversion. The library is very simple in its current form and adding another color converter would mean I have to rewrite the whole thing and I simply didn’t have the appetite for that yet.
• Looking ahead to the ideas for next year I started poking around a potential architecture for Project Wallace’s new Projects feature. I know what it looked like in the previous iteration, but I can’t seem to wrap my mind around the problems I encountered there and how to solve them. Not sure how to proceed, but I probably can’t keep running away from it forever. Or wait, I can. It’s my side project, I can do whatever the f*ck I want.

Blogging

I wrote 10 blog posts this year, including the one you are reading now. That’s a whopping 100% increase from the 5 posts I wrote the year before. I still don’t really like doing it. It involves a lot of work like research and testing for the technical posts. This year’s most popular post was Making Analyze CSS render 6 times faster with 1500+ views.

Tech changes

There’s some work I’ve had to do to keep Wallace in tip-top shape for some new things I’m planning.

This year I’ve added a total of 111 Playwright tests to make sure that new releases don’t break any existing functionality. I love using Playwright as it’s quite easy to add new tests and incredibly fast to run them. It takes around 20 seconds on my M2 Macbook, while GitHub needs 2 minutes to run them all in a single worker.

Keeping SvelteKit up to date has been a bit of work since it’s so new and still evolving (2.0 was just released this month), so I had to spend some time here and there to keep things in check.

What is next?

So, what will happen next year? Well, I’m not sure yet. There is a lot going on in my private life and Project Wallace is and continues to be a side project, so my main focus will be on maintaining a healthy balance in my day job and my personal life.

I keep wondering if I’m ready for Wallace’s next big step: CSS complexity history. We used to have this in the past, but I had to shut it down because of (how ironic) massive complexity, technical debt and a lack of funding. So I’m planning to do things differently this time and make it a much greater experience for you, the user, but for myself as well. I haven’t figured out the architecture for this yet, so if you’re interested in helping me out with this, feel free to reach out! No promises or release dates, but if you want to stay up to date: subscribe to updates.

A thing I’ve wanted to try for years is to write a collection of Stylelint rules based on our metrics. It looks like I’ve figured out how to do that now, so let’s add this to the list. For now, I’m combining them all in a single Stylelint plugin. It’s nowhere near ready to use, because it’s dog-slow and I have to figure out how to solve that first. But it’s a start!

Lastly, I’d like to order a big box full of Wallace-themed t-shirts. During CSS Day I came up with some designs that I’d like printed myself. Asking around on Twitter even yielded some enthusiastic folks who’d buy one of them. Again, I’m hesitant because A) shipping outside of The Netherlands is costly and B) it’s a huge gamble to order a lot of shirts upfront not knowing if they’ll ever sell. But still, look at them… I think they’re too good to pass on.

It’s been a great year and I absolutely love working on Project Wallace. It’s been my playground for a long time now and I hope to be playing around for many years to come. I really appreciate you following along and let’s connect in the new year!

Bart

Let’s say you’re writing a CSS pretty printer and you come across the / symbol: what do you do? You add space around it. Except in font: 16px/1.2 serif;, because no one ever seems to do it there. This leads me to think: is space around / even allowed in the font shorthand and does it actually work?

Testing shows that 16px/2 is the same as 16px / 2 and the spacing seems to work in all major browsers (Safari 17.1, Firefox 119, Chrome 119). The spec also does not seem to mention anything around whitespace, so we’re good there too. So why do we write it like this?

I could not find any sources or style guides that dictate the use (or lack) of space of / in shorthands, so if you do, please let me know! I guess the lack of space around the slash in the font shorthand is just an age-old preference and not commonly applied to other places.

What does this mean for our CSS formatter? Well, I’ve grown so used to not using spaces in the font shorthand that I’ve written a single if-statement to not add whitespace in that particular scenario. Other cases, like calc(2em / 2) and background: no-repeat center / cover url('image.png'); still get the extra space.

TL;DR: Project Wallace has it’s own CSS Minifier!

Manually minifying CSS is one of those tasks you run into every once in a while. Sometimes it’s just too much work to setup a bundler or some script to do it for you, so you quickly do a search for an online CSS minifier and pick the first one.

Now, with more CSS tools on this website than pretty much anywhere else, it only makes sense that we have our own page for compressing your CSS as well. Not because we think we do the best job (certainly not), but because for those quick scenarios it’s usually good enough to remove most whitespace and CSS comments. And that’s exactly what our minifier does:

• remove whitespace
• remove comments
• render all CSS on a single line
• it all runs in your browser; no data is sent to us, so your privacy is guaranteed

Like it says on the page: if you need more thorough minification, you’ll need to look at some of the great solutions out there, because they will remove empty rules and atrules, minify colors, strip unnecessary units where possible and so, so much more:

• LightningCSS
• CSSO
• cssnano

We chose not to do that, because there are a lot of intricate problems to solve with removing parts of CSS, replacing values and rewriting rules. We choose to go for a small, fast, client-side solution. The projects listed above are separate projects, maintained by excellent people who spent a lot of time on improving their setups in ways that we never could.

Just a short post to share my excitement that Project Wallace has been mentioned in public by some pretty cool people!

State of CSS

Thanks to Romain we were listed under the ‘utilities’ section, which means we’re not a framework or a bundler, basically. It really helps getting this sort of exposure and I can see a slight increase in traffic and CSS analyzed because of this. Very cool to see Project Wallace listed in such an influential survey, even though I’m fully aware that my impact is very, very small. 30 of you indicated that they’ve been using Project Wallace from time and even though that’s not much compared to the other tools, it’s enough validation for me to keep going!

Syntax.fm

Listening to the latest Syntax.fm episode certainly had me excited when Scott and Wes started talking about Project Wallace! I’ve been a Syntax listener from day one and I really appreciate the hard work they put into making the podcast. They’ve clarified dozens of On this episode they’re discussing the results of the State of CSS survey where they discover that Project Wallace is a pretty neat tool to keep your color distribution in check or to review all font-families in use. My favorite quote from the show, mostly because of Scott’s audible amazement:

This is cool!

You can listen to the full episode on the Syntax.fm website. Project Wallace is mentioned around the 22m30s mark.

Polypane blog

Kilian from Polypane recently reached out to ask for some feedback about devtools he was building to make using @layer easier. He probably spotted that I was working on the layer visualizer and by the looks of it, he did a great job of visualizing layers in Polypane itself. The devtools now show the full layer tree related to the style rule you’re debugging, which is really helpful. He wrote about it in his Polypane 15 release notes, so go try out Polypane if you haven’t yet.

One of the most inspirational things lately is to watch at Adam Argyle’s side projects and see how he’s doing some really nerdy CSS work. It was somewhere in his work where I found it, in all it’s glory. Waiting to be explored, a rich journey ahead, anxious for the CSS developer community’s love and approval. It’s everyone’s favorite CSS at-rule: @import!

Triggered by my feature requests for project Wallace to extract media queries and supports rules from imports, I started reading into the humble rule. And then Romain started a repository with a bunch of browser and bundler tests to verify different levels of support. In this day of the componentized web and scoped styling solutions it’s grown out of favour. For years we’ve been told to avoid @import for performance reasons. But if you take a closer look, you’ll find that @import is packed with a ton of features that actually make you want to use this bad boy.

1. Flexible URL syntax
2. Cascade Layers
3. Conditional imports: supports()
4. Conditional imports: media queries

Flexible syntax: "url", url(''), or url()

The most important thing an @import needs to do is to import CSS rules some location. The location part here is quite important to the at-rule, so luckily it’s very easy to write the URL correctly. Right?

Well. Let’s have a look at these examples:

@import 'https://example.com/style.css';
@import "https://example.com/style.css";
@import url(https://example.com/style.css);
@import url('https://example.com/style.css');
@import url("https://example.com/style.css");

Yup, they’re all the same thing. Even the one wrapped within url() with no quotes at all! Apparently there are legacy reasons to allow that. The spec also says this:

Some CSS contexts (such as @import) also allow a <url> to be represented by a bare <string>, without the function wrapper. In such cases the string behaves identically to a url() function containing that string.

It’s good to know that there’s at least 5 different ways to specify the URL for @import. Look at you being all flexible.

Cascade Layers

Next up: one of the best additions to CSS in recent years: Cascade Layers! This has me all excited because Bramus gave a thrilling talk at CSS Day last year about it’s workings and capabilities. And then I saw Adam’s CodePen profile packed with example usage of layer() in @import. Here’s three from the Pen I linked in the intro:

@import 'https://unpkg.com/open-props' layer(design.system);
@import 'https://unpkg.com/open-props/normalize.min.css' layer(demo.support);
@import 'https://unpkg.com/open-props/buttons.min.css' layer(demo.support);

Because @import needs to be defined at the top of the document it can be troublesome to let the CSS end up in the correct layer, but the import sytax filled that gap by allowing you to specify which layer you want to put the imported rules in. If you know how @layer works, you can probably tell that his layering system looks something like this:

@layer design {
	/* ... */

	@layer system {
		/* ... */
	}
}

@layer demo {
	/* ... */

	@layer support {
		/* ... */
	}
}

These were all named layers, but you can also import into an anonymous layer. It is allowed to specify layers before imports, so you could also name you layers first and then specify your imports:

@layer design.system, demo.support;
@import 'https://unpkg.com/open-props' layer(design.system);
@import 'https://cookie-consent-stinks.com/bad-css-1.css' layer;
@import 'https://marketing-junk.com/bad-css-2.css' layer;

Now that last import’s rules will be assigned to a new, anonymous layer. The benefit here is that the bad CSS in each of these imports will be contained withing their own layers and don’t leak out to the other layers. This might save you a bunch of headaches down the road.

Browser support

It seems like layer browser support in imports has been around for for over a year already. They probably picked this up right alongside developing initial @layer efforts.

The <link> element does not (yet) support importing into a layer, so if you really must add some 3rd party CSS into a layer, this is your bet. For now. Keep an eye on this GitHub thread if you want to know if and when support is coming.

Import conditions

Just like how @import cannot be nested inside @layer, you also can’t conditionally load CSS by writing @import inside an @supports or @media. But you can conditionally load CSS by appending your supports or media query to the end of the import rule.

supports() in @import

You can append a supports() supports-condition to an import to only import the specific CSS in case the supports-condition is met. The spec has a pretty cool example where they load a fallback stylesheet in case the browser does not support flexbox.

@import url('fallback-layout.css') supports(not (display: flex));

@supports (display: flex) {
	/* ... */
}

You could think of this import as this (although this is not valid and will not work):

/* Mental picture only, this does not work and is not valid CSS */
@supports not (display: flex) {
	@import url('fallback-layout.css');
}

MDN goes a step beyond that and loads this CSS only if display: flex is supported and display: grid is not:

@import url('flex-layout.css') supports(not (display: grid) and (display: flex));

The supports-condition is worthy of it’s own blog post, because the amount of checks you can do there is absolutely wild. Check out the examples over at MDN if you want to see some really cool stuff.

Browser support

It seems that only Firefox has shipped support for supports() in @import at the time of writing. And only two weeks ago. Sad trombone.

Media queries in @import

This is one that most developers might actually be familiar with: specifying a media query list to conditionally load CSS. Again some examples:

@import url('desktop.css') (min-width: 1024px);
@import url('print.css') only print;
@import url('dark.css') screen and (prefers-color-scheme: dark);

Let’s make a mental model of this, as with the previous section:

/* Mental picture only, this does not work and is not valid CSS */
@media (min-width: 1024px) {
	@import url('desktop.css');
}

@media only print {
	@import url('print.css');
}

@media screen and (prefers-color-scheme: dark) {
	@import url('dark.css');
}

Browser support

I can’t find any notes for media query list as a separate thing to supported alognside @import, so I’m going to assume here that support has been around since the early days of CSS imports.

Mixing it up

Now we’ve seen some pretty incredible features of @import, but we can combine all of them! I don’t know if anyone would ever need something like this, but I guess this is something you could do (but not saying you should):

@import url('desktop-fallback.css') layer(base.elements) supports(not (display: grid) and (display: flex)) only screen and (min-width: 1024px);

/* Mental picture of the above import */
@supports (not (display: grid) and (display: flex)) {
	@media (only screen and (min-width: 1024px)) {
		@layer base {
			@layer element {
				/* CSS of desktop-fallback.css here */
			}
		}
	}
}

This example does not make a ton of sense, but I bet there are some real-world scenarios that we could solve with clever combinations of import conditions and layers. Even more so with the addition of more supports() capabilities and added media features.

See!? I told you! This at-rule is full of good stuff. After diving into this I’m mostly left with questions though.

• Does anyone actually use this? At what scale?
• Do modern CSS parsers support all these new conditions and layers?
• Will browsers pick up support for supports()?
• What would be a good trigger for us to start using @import again. There’s probably a way to mitigate some of the performance drawbacks, right?
• I remember seeing a GitHub thread of some CSS working group around adding support for layer and supports in the <link> element, but I can’t seem to find the relevant issue. If you know where it is, please send me a message, because I think that really fits the theme here as well. Thanks for tweeting Bramus and Barry!

Some of this is just more research material that I haven’t got to yet. I’d love to know more about @import, so I encourage you to mail or tweet me some good reading material.

Imagine a conference completely dedicated to CSS. And a former church filled with over 300 CSS enthusiasts. It exists! It’s the amazing CSS Day conference and I was lucky enough to attend again this year. During the talks I’ve been taking notes to see what all the new trends and techniques mean for authoring and auditing CSS. Note: while it may seem skeptical at many points I do think we’re living in a golden era of CSS as Una proved in the opening talk this year.

Contents

1. CSS Nesting
2. CSS Cascade Layers
3. CSS Container Queries
4. Scroll driven animations and the shorthand trash fire

CSS Nesting

CSS Nesting was mentioned in almost every single talk! Even though it doesn’t really seem to add any new capabilities to the language itself, everyone seems to agree that the syntactic sugar adds a lot of benefits to the authoring experience. It’s not just nesting selectors, but also nesting atrules like @media inside regular old CSSRules.

This will change what CSS ships to the browser, because preprocessors (PostCSS, Sass) currently ‘unwrap’ nested selectors and make it plainly visible how much nesting authors are applying to their selectors. CSS Nesting will make it harder to debug which ‘resolved’ selector is being applied, so we need browser vendors to level up their devtools to make inspection of nested selectors easier.

In the example above you can see that Chrome Devtools (Chrome 114) are trying to add helpful context about the selector, but there’s multiple levels of nesting, so we don’t get to see the full resolved selector here, which is inconvenient.

Time will tell how much profit CSS nesting will bring us. Writing the CSS will become faster, but debugging it will become harder as it requires more tooling or mental gymnastics to surface the resolved CSS.

CSS Cascade Layers

Many talks mentioned CSS Cascade Layers as a good way to manage specificity and the cascade. And it is! It’s such a useful addition to CSS that will help us avoid overly complex selectors and resorting to !important.

Layers can be nested, it’s even a very nice method to group certain parts of the CSS, like a sort of namespace. But, like CSS Nesting, it brings with it some difficulties in inspecting the final CSS. A declaration can be nested several layers deep, so to debug why certain properties are applied we need some sort of view of the resolved layer tree. Luckily, both Firefox and Chrome devtools are already on the case, but with different levels of completeness.

Chrome showing the full layer tree is something I very much appreciate, because it will help you visualize the high-level architecture of your CSS.

CSS Container Queries

Container queries will change our code from mostly writing @media to writing @container to proportionally size our layouts and components. Miriam Suzanne articulated quite well that it is very likely that we’ll use @container for sizing elements and use @media to make decisions based on the OS level, like dark mode, and reduced motion.

It looks like Firefox is very much on top of the game here, although Chrome’s devtools are perfectly usable as well.

Scroll driven animations and the shorthand trash fire

A couple of demos and talks showed off the amazing things we can build with Scroll Driven Animations. I’m not going to explain them here, so if you need examples you can check the ones from Jhey or Bramus.

One thing that stood out is that the new animation-timeline, animation-composition and animation-range properties cannot be combined with the animation-shorthand property.

/* WARNING: will not work */
#square {
	animation: 3s demoAnimation alternate scroll(block nearest);
}

/* This works */
#square {
	animation-name: demoAnimation;
	animation-duration: 3s;
	animation-direction: alternate;
	animation-timeline: scroll(block nearest);
}

/* Or, if you're a fan of shorthand, this works too */
#square {
	animation: 3s demoAnimation alternate;
	animation-timeline: scroll(block nearest);
}

Adding that extra property to the animation shorthand would have made it a bit difficult, if not impossible, to parse correctly. Or as Tab Atkins said it:

the animation shorthand is already a trash fire of parsing

CSS Working Group meeting notes, 20-03-2023

CSS is moving at rocket-speed pace and I’m a big fan of all the attention it’s getting from all browser vendors. There’s more tools coming in our browsers on a daily basis and I’m so grateful to all browser and devtools teams for their hard work.

Last year we introduced a prettifier to this website because it’s one of those things you often want to do when auditing CSS. Then, not long after that, we added the option to prettify your CSS before analyzing it. Because we have a DevTools panel now on the analyzer page, it makes sense to view the CSS usage in a formatted manner. But this came at a cost: prettifying the CSS took up to twice as long analyzing the CSS! Time to look at a more performant alternative.

The naive way: Prettier

The first iteration of our prettifier used Prettier, a very popular and respectable project that can pretty-print hundreds of different languages. Even before testing, I was already pretty sure this was going to be a slow function call, so I went ahead and made sure to only import the relevant modules and to put the function in a WebWorker to run it off the UI thread.

// prettify-worker.js
import prettier from 'prettier/esm/standalone.mjs'
import cssParser from 'prettier/esm/parser-postcss.mjs'

// The `event` here is the message we send from the UI to
// the worker and `event.data` contains the string of CSS.
onmessage = function (event) {
	try {
		let result = prettier.format(event.data, {
			parser: 'css',
			plugins: [cssParser]
		})
		// Send result back to UI thread
		postMessage(result)
	} catch (error) {
		postMessage({ error })
	}
}

This worked quite well, but after some weeks I noticed more often that the progress back on the analyzer page got stuck on “prettifying CSS” step. It’s not necessarily a bad thing, but if you analyze CSS as much as I do it becomes annoying after some time. And since prettifying CSS isn’t even our core business (if you can call it that), it’s even more frustrating.

CSSTree to the rescue

After thinking about the problem for a while I realized that I could enlist the help of CSSTree to do some of the work. The CSS Analyzer is based on CSSTree’s AST, so I know how the thing works and the dependency is already on the page, so no need to download more dependencies. Prettier + Postcss cost almost 340kB to download, which isn’t huge, but it would be nice if we could reduce that amount.

So how do you turn a string of (potentially minified) CSS into a string of mostly readable CSS with CSSTree? Let’s start by parsing the CSS, so we get an AST to work with. Then, using that AST, we apply our knowledge of CSS structure to turn them into readable strings, line by line.

Fast CSS parsing

CSSTree has some neat parsing options to speed things up a bit. It allows you to skip certain tokens, which will reduce memory usage and all that. The following script creates an AST of our CSS. An example of such an AST can be inspected on ASTExplorer.

let ast = parse(css, {
	positions: true,
	parseAtrulePrelude: false,
	parseCustomProperty: false,
	parseValue: false
})

We can skip parsing Atrule preludes, custom properties and values because we’re only interested in their ‘raw’ string values, not the deeper tokens within them. We do need positions because this will allow us to do a lot of css.substring(x, y) later on.

Creating a readable string of CSS

With the AST in hand, we can begin thinking about how to turn it into pretty-looking CSS. We need the CSS to be pretty enough to show it in a readable way in our DevTools, not any fancier than that. After some thinking, I came up with the following rules:

1. Every AtRule starts on a new line
2. Every Rule starts on a new line
3. Every Selector starts on a new line
4. A comma is placed after every Selector that’s not the last in the SelectorList
5. Every Block ({}) is indented with 1 tab more than the previous indentation level
6. Every Declaration starts on a new line
7. Every Declaration ends with a semicolon (;)
8. An empty line is placed after a Block unless it’s the last in the surrounding block
9. Unknown syntax is rendered as-is

As you can see from this list, we’re dealing with a very limited subset of CSS tokens here: Stylesheet, Atrule, Rule, SelectorList, Selector, Block and Declaration. We’re starting our formatting from the Stylesheet level:

function print(node, indent_level = 0, css) {
	let buffer = ''

	for (let child of node.children) {
		if (child.type === 'Rule') {
			buffer += print_rule(child, indent_level, css)
			buffer += '\n'
		} else if (child.type === 'Atrule') {
			buffer += print_atrule(child, indent_level, css)
			buffer += '\n'
		} else {
			buffer += print_unknown(child, indent_level, css)
		}
		buffer += '\n'
	}

	return buffer
}

This kicks of our prettification, calling print_atrule and print_rule, which look like this:

function print_atrule(node, indent_level, css) {
	let buffer = indent(indent_level)
	buffer += '@' + node.name

	if (node.prelude) {
		buffer += ' ' + substr(node.prelude, css)
	}
	if (node.block && node.block.type === 'Block') {
		buffer += print_block(node.block, indent_level, css)
	} else {
		// `@import url(style.css);` has no block, neither does `@layer layer1;`
		buffer += ';'
	}

	return buffer
}

function print_rule(node, indent_level, css) {
	let buffer = ''

	if (node.prelude && node.prelude.type === 'SelectorList') {
		buffer += print_selectorlist(node.prelude, indent_level, css)
	}

	if (node.block && node.block.type === 'Block') {
		buffer += print_block(node.block, indent_level, css)
	}

	return buffer
}

And this goes on a bit for all the other types as well. There’s even some recursion in here because Atrules can be nested (@media in @layer and CSS nesting, to name a few), so we need to make sure to account for those as well.

If you want to see more: the source code for this can be found on GitHub, where I’m currently in the process of making this a standalone NPM package.

Tradeoffs

No project is perfect and neither is this little script. There are some things that it does well and in a simple fashion, but some things I’ll consider beyond the scope and necessity of this package. And that’s ok because we just need it to format your CSS well enough to audit it easily.

• ✅ super fast (>90% faster than Prettier)
• ✅ ‘tiny’ bundle size (~99% smaller than Prettier)
• ✅ prettifies well enough for our use cases
• 🔸 if your source CSS renders things multi-line (like long selectors or values), they’ll stay multi-line (fine, I guess)
• 🔺 not as configurable and extensive as Prettier

These are tradeoffs I can live with.

One of the main drivers for Project Wallace is performance. Not just analyzing the performance of CSS as you can see in our code quality tools, but also doing the work in a fast and efficient way. With all the extra analysis that we’ve added over the last year, the analyzer page started to become a little slow. Even though the analysis happens completely off the main thread using a WebWorker. But rendering the results on the page sometimes took longer than parsing and analyzing the CSS itself! So I set out to fix that and the result is that the CSS report now renders more than 6 times faster than before! Here’s what I found.

TL;DR;

1. Render expensive components only when they are within the viewport
2. Reduce the amount of DOM nodes

Setting a baseline

All test cases were run against the CSS of CNN.com, because it’s a large dataset (800+ kB), but also a pretty good representation of real-world CSS. Many websites out there are like CNN’s, with lots of unique colors, font-sizes, rules, everything.

Before any changes were made, rendering report took about 1.6 seconds.

The fixes

With this knowledge in mind, it’s time to take action.

Lazily rendering all ScatterPlots

Zooming in shows that there is a single function ($e) that takes up almost 700ms to render. It turns out it’s one of the scatter plots that we use to show Ruleset and Selector complexity.

Here’s the offending scatterplot:

And this is just one. There are four of these in the report, so this is a good starting point to start optimizing.

Rendering all ScatterPlots at once turns out to be quite slow and here’s the catch: they’re not even shown immediately, because you have to scroll down to see them. So what if we only render the ScatterPlots when they’re inside the viewport? Support for IntersectionObservers is quite good these days, so it shouldn’t be too hard to implement.

There’s a pretty nice Svelte package to use IntersectionOberserver, so I installed it and tweaked the ScatterPlot.svelte code a little (abbreviated example):

ScatterPlot.svelte before

<!-- ScatterPlote.svelte (before) -->
<script>
	import * as Pancake from '@sveltejs/pancake'

	/** @type number[]*/
	export let points

	/** @type number */
	export let max
</script>

<div class="chart">
	<Pancake.Chart x1={0} x2={points.length} y1={0} y2={max}>
		{#if points.length > 0}
			<Pancake.Svg>
				<Pancake.SvgScatterplot data={points} let:d>
					<path class="dot" {d} />
				</Pancake.SvgScatterplot>
			</Pancake.Svg>
		{/if}
	</Pancake.Chart>
</div>

<style>
	.chart {
		height: 200px;
	}
</style>

ScatterPlot.svelte after

<!-- ScatterPlote.svelte (after) -->
<script>
	import * as Pancake from '@sveltejs/pancake'
	import { inview } from 'svelte-inview'

	/** @type number[]*/
	export let points

	/** @type number */
	export let max

	let is_visible = false
</script>

<div
	class="chart"
	use:inview={{ unobserveOnEnter: true }}
	on:inview_enter={() => (is_visible = true)}
>
	{#if is_visible}
		<Pancake.Chart x1={0} x2={points.length} y1={0} y2={max}>
			{#if points.length > 0}
				<Pancake.Svg>
					<Pancake.SvgScatterplot data={points} let:d>
						<path class="dot" {d} />
					</Pancake.SvgScatterplot>
				</Pancake.Svg>
			{/if}
		</Pancake.Chart>
	{/if}
</div>

<style>
	.chart {
		height: 200px;
	}
</style>

What happened here?

1. Add the svelte-inview package and create a single local variable called is_visible
2. Make sure the chart element is being observed, so that we get a message when it’s scolled into view: use:inview={{ unobserveOnEnter: true }}
3. When the element scrolls into view, is_visible is set to true: on:inview_enter={() => (is_visible = true)}
4. Only when is_visible is true, the Pancake chart is rendered.
5. There is no layout shift, because the .chart class makes sure the element is always 200px tall.

That’s it! Only 5 lines of code added, for instant benefit.

Lazily rendering Colors

Somewhere down the page there are some colors lists. They’re basically a small <canvas> where we render all known colors too. For websites with many colors this can be quite intensive, so I gave this the same treatment as the ScatterPlots: only when the Colors section of the report is scrolled into view, these canvases are rendered.

Reducing DOM nodes

One thing that is generally true for most performance-related work is the amount of DOM nodes on a page. Whether that’s for React, Svelte or even CSS selector performance. Many nodes make your app slow. In our case, the page has over 7200 DOM nodes, so we should remove a whole lot of them to make our page render faster.

Lazily rendering ColorList

Similarly to how we lazily render the scatter plots, we also lazily render the ColorList as well. For CNN it contains a whopping 504 DOM nodes for 126 unique colors (4 DOM nodes per color), so that’s a huge list of items for Svelte to skip initially.

Reducing font-size nodes

CNN.com has 319 unique font-sizes which is a lot, but unfortunately a pretty common amount.

This is the (stripped down) HTML we used to generate that list (before):

<!-- FontSizes.svelte -->
<ul>
	{#each sizes as [value] (value)}
		<li>
			<!-- useless div! -->
			<div>
				<div style:font-size={value}>AaBb</div>
				<code>{value}</code>
			</div>
		</li>
	{/each}
</ul>

It wasn’t obvious immediately, because the actual implementation has more classnames and attributes, but there is a completely unnecessary <div> in there, so I took it out while maintaining the same layout, which saves us 319 DOM nodes!

Reducing DOM nodes in ShowMore components

To keep the report somewhat easy to digest, I’ve made a component that only shows the top ~15 items when there’s a long list of things. The properties-list and media queries are a good example of this. When there are many properties, like the 220 unique properties on CNN.com, we don’t want to scroll for ages to get to the next section, unless you intentionally want to view them all.

Now, before our performance upgrade, we’d render all 220 items (× 6 DOM nodes = 1320 nodes!) and hide everything after the initial 400px with overflow: hidden. What a waste! Time to be a little smarter with our rendering.

The trick here is to use Svelte slot props:

<!-- ShowMore.svelte -->
<script>
	let status = 'closed'
</script>

<div class="show-more" data-status={status}>
	{#if status == 'closed'}
		<button type="button" on:click=()}>Show more</button>
	{/if}
	<!-- pass `status` to the component using <ShowMore> -->
	<slot {status} />
</div>

<style>
	.show-more[data-status="closed"] {
		max-height: 400px;
		overflow: hidden;
	}
</style>

<!-- Properties.svelte -->
<script>
	export let properties = []
</script>

<ShowMore let:status>
	<table>
		<thead><!-- etc.  --></thead>
		<tbody>
			{#each properties.slice(0, status === 'closed' ? 15 : Infinity) as property}
				<tr><!-- etc.  --></tr>
			{/each}
		</tbody>
	</table>
</ShowMore>

In the above (simplified) components, we see that ShowMore exposes the status value back to the consuming component (Properties.svelte), so that it knows whether it’s open or closed. When closed, we slice the properties array to only render 15 rows (× 6 DOM nodes = 90 nodes, versus 1320 before). When open, we render the full list by setting the end of slice to Infinity.

The result

After these changes the Performance panel shows that a mere 262ms is needed to render the whole report, which is more than 6 times faster than before! The initial DOM node count has gone down from a whopping 7200+ to 3770, which is almost a 50% reduction! 🤯

The image also shows two big blocks of Recalculate Style and Layout, taking up 150ms and 50ms. I have yet to find out what they mean, but I think it’s the document trying to paint the generated report to screen. The tall block on the left is what would previously take up all space and look at it now: it’s tiny in comparison.

Thank you

A big shoutout to Tim Vereecke and John for helping me understand what’s going on! Your feedback really helped me fix the issues and motivated me to write this post. John also found some interesting pointers to potentially speed up Pancake.svelte, but let’s leave that for another time. 😉

Instagram.com ranks pretty high according to the Alexa top visited websites. This means that all the CSS from Instagram.com gets downloaded to millions of devices every day. Let’s have a look at the interesting parts of their CSS analysis.

First impressions

Coming in at 543 kB, the overall CSS size is pretty substantial. It’s not as bad as some other large companies, but I am almost certain it could be way less. With the amount of visitors they have, making their CSS smaller would be a nice bandwidth-saving as well.

Almost 30,000 Source Lines of Code, with declarations making up for roughly 50% of that (16,235). There are 10,449 selectors, which means that the remaining ~4000 lines of code are hidden in at-rules! That will be an interesting one to look at later on in this post.

CSS Rules

One of the first things that jumps out is a massive rule size of 550! Zooming in on that we see a rule with 2 selectors 548 declarations! This is not uncommon since the rise of CSS custom properties because lots of sites declare most of their ‘variables’ on the :root selector. 548 custom properties is just… more than usual. In the graph above this ruleset is visible as the top left dot.

:root,
.__ig-light-mode {
	--fds-black: #000000;
	--fds-black-alpha-05: rgba(0, 0, 0, 0.05);
	--fds-black-alpha-10: rgba(0, 0, 0, 0.1);
	--fds-black-alpha-15: rgba(0, 0, 0, 0.15);
	--fds-black-alpha-20: rgba(0, 0, 0, 0.2);
	--fds-black-alpha-30: rgba(0, 0, 0, 0.3);
	--fds-black-alpha-40: rgba(0, 0, 0, 0.4);
	--fds-black-alpha-50: rgba(0, 0, 0, 0.5);
	--fds-black-alpha-60: rgba(0, 0, 0, 0.6);
	--fds-black-alpha-80: rgba(0, 0, 0, 0.8);
	--fds-blue-05: #ecf3ff;
	--fds-blue-30: #aac9ff;
	--fds-blue-40: #77a7ff;
	--fds-blue-60: #1877f2;
	--fds-blue-70: #2851a3;
	--fds-blue-80: #1d3c78;
	--fds-button-text: #444950;
	--fds-comment-background: #f2f3f5;
	/* hundreds more, etc. */
}

Right after that one, the dark theme:

.__ig-dark-mode {
	--fds-black: black;
	--fds-black-alpha-05: rgba(0, 0, 0, 0.05);
	--fds-black-alpha-10: rgba(0, 0, 0, 0.1);
	--fds-black-alpha-15: rgba(0, 0, 0, 0.15);
	--fds-black-alpha-20: rgba(0, 0, 0, 0.2);
	--fds-black-alpha-30: rgba(0, 0, 0, 0.3);
	--fds-black-alpha-40: rgba(0, 0, 0, 0.4);
	--fds-black-alpha-50: rgba(0, 0, 0, 0.5);
	--fds-black-alpha-60: rgba(0, 0, 0, 0.6);
	--fds-black-alpha-80: rgba(0, 0, 0, 0.8);
	--fds-blue-05: black;
	--fds-blue-30: black;
	/* hundreds more */
}

Selectors

A surprisingly good score for Instagram here: 11,573 selectors with 96.16% being unique. Most websites with such a vast amount of selectors suffer from a lot of duplication.

On the complexity side of things, it’s looking good as well: less than 200 selectors have a higher complexity than 3, which is pretty good.

The most surprising part for me was the specificity: over 10,000 selectors have specificity of either [0,1,0] or [0,2,0]. And even the maximum specificity ([1,3,0]) is way below the maximum of what many sites of this size have. Good job!

At-rules

@media

The first thing that jumps out when checking the at-rules are the @media queries. It’s not just the total of 1,600+, but the fact that there are 135 unique ones. 135 unique media queries! Pretty much all of them use px as units for min-width or max-width and most of them are really, really specific numbers. I wonder if they have some kind of system for that, or if they just eyeball the page layout and apply media queries where they see fit.

@keyframes

Another interesting metric is the 140 unique @keyframes that are in Instagram’s CSS, which is a lot. Usually, this can be explained by the fact that many of the atrules are straight copies because of vendor prefixes in the atrule, like this:

@keyframes thing {
	from {}
	to {}
}

@-webkit-keyframes thing {
	from {}
	to {}
}

… but this is not the case on instagram.com. There are truly 140 unique @keyframes rules, most of which have a random string as a name, so I’m happy that I’m not the one having to go debug that part of their CSS.

@keyframes x104yahw-B
@keyframes x1078a53-B
@keyframes x13f3g3z-B
@keyframes x148q4be-B
@keyframes x166kt1m-B

Declarations

Only one thing worth mentioning here: there are only 167 !importants, which is really low compared to the total of 17,356 declarations. Less than 1% !important usage, that’s something that not many websites at scale can pull off!

Properties

I think Instagram must have broken some kind of record here for having 548 unique custom properties. That’s just bonkers. Other than that, the top usage ones are the usual suspects, with width, height, background-color and display ranking high, just like most other websites.

One thing that’s cool about checking someone else’s CSS is that you can learn a lot by doing it. Today I learned about -ms-scroll-rails and -ms-scroll-chaining, which are obsolete properties, but apparently still used on today’s instagram.com.

Values

Colors

539 unique colors. That just can’t be right. We’ve seen the vast amount of custom properties above, so I’m surprised that there are still so many unique colors. I’m afraid that there must be a part of Instagram that’s old and tucked away and not updated with the same level of care as the rest of the site.

An interesting note about Instagram’s color format usage: they seem to use more different formats than most sites I’ve seen so far. I’m surprised that there are so many named colors in there.

Font-families

Again, a huge list: 78 unique font-families (most sites stop at about ~20). Scrolling through that actually reveals that there’s probably a good reason for this amount because some of them have names like 'Fix for Mac Chrome 80' and I think that font-family alone is worth a blog post on itself.

That’s it for now! I won’t go into more details about other things because A) this post is long enough as it is and B) most things are what you would expect from a website as big as instagram.com.

I highly encourage you to check out the report yourself and see what you can take away from these analytics. Let me know what you think of this type of post! Did you like it? Was it deep enough? Or still too superficial? Ping me at @bartveneman.

It’s been a pretty busy month with lots of fixes and new features.

Specificity Analyzer page

Checking the specificity of a CSS selector is just one of those tasks that any CSS engineer does a lot. I’ve added a quick specificity calculator page, based on Bramus’ excellent specificity package.

The page is nowhere near as good or complete as the one from Polypane, but Wallace aims to be a place where you can audit all of your CSS, so it just makes sense to have our own specificity analyzer here.

CSS Units game

A recent Tweet from Adam Argyle got me thinking that it’d be fun to create a CSS-based game. So I created it! It’s pretty much a copy of HTML memory test that seemed pretty popular a while ago. The game is to remember (or guess!) all possible CSS units. There are 64 of them and I tapped out after 10 units…

Showing actuals in Code Quality analysis

A common complaint about the CSS Code Quality report was that it could use some more details. While the current analyzer doesn’t provide those (yet, because I developed it in a hurry), I added more information to most panels related to selector complexity. Now you can see the actual average line plotted in your complexity chart, for example. That should clear things up a bit.

css-analyzer uses @bramus/specificity

After a long time of doing our own specificity analysis, I finally switched over to using a package to do that. Why? Well, analyzing specificity isn’t exactly difficult, but there’s a lot of gotchas and edge cases. More and more I found myself copying test cases and bits of code from other places. After I spoke to Bramus last summer at CSS Day 2022 I dabbled at bit with implementing his package. At first I was afraid of performance implications, but actually there’s hardly any difference between his and my own implementation. They’re both built on CSSTree anyway and the code was 90% similar. And now, I can benefit from his (and my own) bug fixes to make sure Wallace’s specificity calculations are correct!

My review of 2021 generated lots of encouraging comments. Here’s what happened with Project Wallace in 2022:

Notable releases

• CSS Code Quality is the biggest release in terms of complexity and amount of usage. Read more about it in the introduction post.
• The Online CSS Prettifier is a tool that already exists on a lot of other websites, but I don’t like having to google my way out of this every time, so I decided Project Wallace should have it’s own prettifier.
• The core CSS Analyzer (please star it on GitHub!) has seen 10 releases this year in total:
  • Support for analyzing Embedded Content in CSS, like base64 encoded fonts or images;
  • Lots of browserhacks are now analyzed, ranging from at-rules and selectors to properties and values;
  • The relatively new @layer at-rule is now analyzed
  • Total bundle size went down a lot because CSSTree now supports tree shaking!
  • Lots of performance improvements and less overall memory usage, despite adding more and more features.

Traffic

Although the amount of visitors seems to have doubled, the amount of pageviews has only increased slightly. Part of this is due to an error on my end where analytics was broken on the Projects side, but still it’s a remarkable difference in visitors vs. pageviews ratio.

I’m starting to think that there’s less ‘quality’ traffic to the site, and more one-off visitors. According to Fathom the bounce rate is slightly higher than last year, so I think there are more people coming for a handful of pages and then moving along with their day. At first sight this frustrated me a little, but on second thought I think that’s a good thing: people come here to accomplish a task and then get on with the work they intended to do. Project Wallace is not a social media platform, we don’t need high engagement, we need high quality tools to do our work.

Popular pages

• The CSS Analyzer is still on top in terms of page views, partially thanks to coliss.com, but the gap is becoming smaller with…
• The CSS Code Quality page is catching up in terms of popularity quickly. It has been mentioned of several websites like habr.com, kachibito.net and many others.
• By far the best blog post ever I’ve written: CSS Complexity: it’s complicated peaks at 6,000+ page views at the time of writing and it’s still being visited every single day.

Website activity

It’s amazing to see that there’s such an interest in CSS Code Quality tooling. The funny part is that I started writing it to help someone explain how the plain CSS analytics could be translated to ‘quality’. Apparently there are more people struggling with the raw output of their CSS analytics. And I get it. Having the data is one, but understanding what it means is something different. The CSS Code Quality package is still very crude, so I’m planning on some additions to help explain some of the concepts using the actual CSS that was analyzed. That should give everyone (myself included!) a better understanding on why some rankings are under-performing.

It’s no surprise that the CSS Prettifier isn’t used very often. What does surprise me is that the CSS Scraper is so much less popular than the rest. I expected more people to be in need of a tool like this. Perhaps this is because the link is not in the site header. Ultimately, everyone analyzing CSS by URL uses this feature under the hood, so the actual total is more in the 11,000+ range, which is bonkers.

Ideas for the new year

• Update the CSS Analyzer to use Bramus’ Specificity calculator. It’s more correct and saves me a bunch of work in maintaining;
• Adding a page to the website to quickly calculate specificity. There’s already a bunch of them out there, but like the prettifier, I don’t like context switching;
• Improving the CSS Code Quality page to use the analyzed CSS to explain the bits that are sub-optimal;
• Implementing lots of new analysis features, like native CSS nesting, reporting on color formats used and the most important: calculating total CSS complexity!

Closing thoughts

I’m pretty happy with these numbers, but even more happy with the feedback that comes from the CSS community in many forms. A part of that community was at CSS Day Conference this year and I was lucky to meet some inspiring people there, like Bramus and Vadim. Also, Roman just keeps pushing CSSTree to the next level, which is incredibly generous and exciting.

Their enthusiasm and generosity really help driving Project Wallace forward and I can’t wait to see what 2023 will bring us.

Keep an eye on this little website!

It’s one of those common tasks that you do when auditing CSS: making minified CSS readable, to easily navigate it. There are so many existing websites out there that do this, so it may come as a surprise that you now can prettify CSS online at Project Wallace too. But the reason for this is simple: ProjectWallace.com is a place where developers can inspect and learn about their CSS, so apart from all the metrics that we generate we also make a human-readable version of your CSS for you. This means you don’t have to jump to another site to do this exact task, meaning you can complete your task faster. And that’s what you came here for. To get a job done.

For now, the prettifier is a standalone page, but perhaps we’ll eventually add ‘prettify CSS’ buttons to other pages as well, like the Analyze CSS or CSS Code Quality pages.

This online CSS prettifier is powered by Prettier and runs in your browser, so our servers never see that CSS.

Years ago I read a blog post by Harry Roberts about Cyclomatic Complexity in CSS. You know, one of those classic Computer Science metrics that traditionally only classically trained engineers get to use. And for years this has me thinking that with CSS we also need a way to express cyclomatic complexity.

There are many occasions where someone will audit the codebase and will want to know the overall state of the code, detect weak spots and find outliers. The proof of that in the many visitors on this very website that check their CSS analytics or Code Quality. And to my knowledge there doesn’t exist a tool that give you hints about the complexity of your CSS and I am convinced that we need this.

And then came Bramus at CSS Day 2022, who told us that most CSS architecture solutions like BEM and ITCSS are primarily aimed at selectors and the struggle with the cascade. This has been stuck in my head ever since. It makes so much sense: selectors are usually the frustrating part of the authoring experience (opposed to the debugging experience). Once you have a specific enough selector, you keep adding declarations until it looks good.

Selector complexity beyond specificity

Some recent additions to CSS have made it easier to deal with specificity issues, like :where() and :is(). Both give us the opportunity to write more complex selectors at the cost of little specificity added (or none, in the case of :where()). But they can make selectors more complex. Let’s take a look at these two examples:

/* specificity: 0,1,2 */
:is(header, main, footer) p:hover {}

/* specificity: 0,1,2 */
header p:hover {}

Specificity for both selectors is 0,1,2, but I’d argue that the first one is more complex than the second, because of the arguments in :is(). For me there’s at least 6 parts to this selector, instead of the 3 (2 + 1) that the specificity would hint at. This is one example of specificity being not enough to explain the complexity of a selector.

More than just selector complexity

Rarely do we talk about the ‘hidden’ complexity in CSS. The complexity that becomes visible when debugging. This is where the order of things comes into play, as well as things like RuleSets being nested inside at-rules, like @media or @supports or soon @container, but also vendor prefixes and browser hacks being used in selectors, properties, values, at-rule conditions. And you probably didn’t author some of these, but they were added by Autoprefixer, PostCSS, Sass or ParcelCSS and now there’s even more code to dig through! Even @layer will not save us from all the nasty stuff that’s tucked away in these rules, because it will only help with controlling the cascade, which in itself is another form of adding complexity.

My goal is to work on a complete list and implement all these into Project Wallace’s analyzer, so we can all inspect the things we’ve made. Here’s a list of things I’m considering to add to CSS complexity:

• Atrules
  • @import can include media queries, supports conditions and a layer: @import url(reset-mobile.css) supports(not (display: flex) and screen, (min-width: 1000px) layer(reset);
  • @supports can contain vendor prefixes: @supports (-webkit-appearance: none) {}
  • @keyframes can be vendor prefixed: @-webkit-keyframes {}
  • @media can be a browserhack: @media \\0 screen {}, @media screen\9 {}
• Selectors
  • Attribute/value selectors: [type], [type=text]
  • Vendor prefixes: -moz-any(p)
  • Combinators: .item ~ .sibling
  • Forms: input[type="tel"]:invalid:not(:focus):not(:placeholder-shown) + label
• Declarations:
  • Usage of !important
• Properties:
  • Vendor prefixes: -webkit-appearance
  • Browserhacks: *zoom
  • Custom properties: --brand-surface (I’m actually still undecided if this should count towards complexity, so I’d love to hear your thoughts. Again, Bramus shows us there’s definitely a complexity cost to pay in some circumstances and Lea Verou’s talk also highlighted that custom properties can be really powerful, but that power comes with a complexity cost)
• Values
  • Browserhacks: 10px !ie, green \9
  • Vendor prefixes: -webkit-linear-gradient()

See? There are so many things! At first I thought it would be a little far fetched to start looking into these, but when I started working on selector complexity metrics a long time ago I noticed that many websites have plenty enough of any of these complexity issues going on. So I’m really looking forward to experimenting with this and what insights it will bring to us.

On a closing note: I think Project Wallace is the most powerful tool to explore your CSS, but I also think that browser makers should step up their game here. Google Chrome had a nice start with their CSS Overview, but I think the topic is still largely overlooked and developers are looking for ways to learn more about their CSS, beyond looking at the different colors and fonts.

Special thanks to Bramus van Damme for proof-reading this post!

TL;DR: See your CSS Code Quality in numbers in a single glance on our Online CSS Code Quality Calculator

Ever since I started Project Wallace years ago, I’ve been missing something. Because every time you open a project or do a one-off analysis it’s difficult to see in a quick glance how you’re doing. Is it good? Is it bad? Is it really bad? Well, let’s scroll for a couple of seconds and try to make sense of what is shown on the page. If you understand most metrics, that is.

Well, at the start of this year, it finally clicked:

Starting off the new year with an attempt to write a CSS code quality tool… :sweat_smile:

Points deducted for complexity, performance anti-patterns etc etc.

Think @____lighthouse, but for CSS specifically.

The responses were quite good. A couple dozen likes, retweets and folks showing interest. It doesn’t seem much, but for an account as small as Project Wallace that’s a lot. That was enough to get me started and after a couple of evenings, it started to look pretty good. I decided to not polish it too much at this stage but to put it online and gather feedback to improve it.

The basic idea is that you give us your CSS and we will come up with a code quality score that’s made up of 3 separate topics: maintainability, complexity and performance. Each topic’s score is the result of several tests that we run against your CSS. We deduct points for each anti-pattern we encounter. The end score will be what’s left of an initial 100 points for each topic.

So here it is: Project Wallace’s Code Quality Analyzer.

The score list shows each test and whether you’re scoring poor (red), ok (orange) or good (green).

I hope you’ll enjoy this feature. Please let me know what you think of it and have fun checking your own website(s) and those of your frenemies ;)

First day of a new year! Let’s have a look at some numbers of this silly little website from 2021.

Traffic

During 2021 we’ve had 10.9K visitors with a total of 40.3K page views! No idea what that means compared to other sites, but this is a very niche site so the numbers look good to me.

Apparently a lot of people have some form of interest in the CSS of their website. That’s a sign of hope for me. Project Wallace is a great educational tool, whether you’re a seasoned developer or a new kid on the block. And having lots of folks around here means that many people are getting better at understanding the CSS they wrote.

Important referrers

Pretty much all traffic on this website comes from a handful of blog posts on the internet. Most of these posts are either on Smashing Magazine or CSS Tricks. Some big spikes in traffic this year because of some posts gaining traction or a popular newsletter that was just sent. Let’s list the top ones:

• Smashing Magazine (3.6K views):
  • CSS Auditing Tools by Iris Lješnjanin: 2.4K views
  • Refactoring CSS: Introduction by Adrian Bece: 915 views
• CSS Tricks (2.3K views):
  • Tools for Auditing CSS by Silvestar Bistrović: 1.2K views
  • Design v18 by Chris Coyier: 530 views
  • Several more newsletter pages and older blog posts that gained less traction.
• Google: 2K views
• Twitter: 1.2K views
• GitHub: 844 views
• LinkedIn: 734 views
• A shoutout to the several visitors that keep coming back from specific Jira URL’s. I see you and I applaud the people who thought it would be useful to create a ticket for themselves or someone else to have a look at Project Wallace.

I am so grateful for any of these authors for mentioning this website with positive remarks. It’s so inspiring to see other people being enthusiastic about this space. Especially Chris Coyier holds a special place for me because he let me write a piece on CSS Tricks about monitoring CSS quality. Thanks Chris, you’re such an amazing person!

Activity

Looking at the raw database numbers for projectwallace.com, combined with data from Fathom Analytics:

• 3.2K analyze CSS via URL. That means entering a URL, a headless browser spins up in a serverless function, it scrapes the CSS, and Wallace analyzes that CSS online. In just a couple of seconds.
• 503 analyze CSS via direct input. Copy your CSS, paste it in the <textarea> on projectwallace.com/analyze-css, hit the button. 503 times. That’s a lot.
• 264 times Get CSS. Sometimes you just need the CSS for a URL. This does just that. Less popular than analyzing CSS, but apparently still useful.
• 340 users created. That’s the amount of people whow thought it might be useful to keep track of their CSS over time, instead of only having a one-time look only. Amazing number, if you ask me.
• 23 users deleted their account. And deleted means deleted forever. I can only keep count of the amount of deletions, because I don’t keep any record of anyone cancelling their account.
• 349 projects created. Slightly more than the amount of people signing up.
• 59 projects deleted. Didn’t expect that many, but I think folks on the free plan need new projects sometimes, so they need to delete their existing one. Maybe you should consider upgrading so you can have more projects?
• 3621 imports created. 2910 via a webhook, 244 via pasting CSS in a <textarea>, 467 via entering a URL.
• 184 login failures. Apparently, logging in is hard sometimes. No worries, we’re all struggling from time to time.

Conclusion

Frankly, it baffles me that so many people take an interest in breaking down their CSS and it’s really motivating to keep this project running.

Bart

With a few hours left before the end of the year I am happy to announce that @projectwallace/css-analyzer is now on version 5! It is a complete rewrite of the previous version. The TL;DR:

• More metrics added
• Existing metrics are more detailed
• Less dependencies (faster installation)
• Runs faster
• Browser compatible

If you’re in a hurry, go grab it on GitHub or run npm install @projectwallace/css-analyzer.

New features 🥳

• The most exciting feature of all: see where colors are defined! It’s cool to see all the unique colors in a list, but it’s even better to see that background uses 3 different colors, whereas color uses 12!
• Metrics like selectors per rule now have a full list detailing the amount of selectors/declarations per rule. This means you can now graph out these metrics and that’s exactly what I’m doing on the online analyzer;
• For many metrics I’ve added the mean, median, mode, minimum, maximum and sum of that metric. That means that you can now see what the most common specificity of a selector is, or the highest complexity of a selector, or the maximum amount of selectors in a single rule;
• You can now see all the CSS units that are used in the CSS. Whether they are rem, px or even vmin: it’s all visible now. And you can even see if font-size is using more px than em or that transition-duration only uses s instead of ms ;)

Migration from v4 to v5 🪜

• Drop support for Node 8 and 10 (see Node.js releases)
• Rename all metrics ending on .share to .ratio
  This is only a better word for the exact metric;
• Rename stylesheets to stylesheet
  Because we're always analyzing exactly one stylesheet;
• Remove stylesheets.simplicity
  This is now `rules.declarations.mean`
• Remove stylesheets.cohesion
  This is now `rules.selectors.mean`
• Remove stylesheets.browserhacks.*, atrules.supports.browserhacks.*, atrules.mediaqueries.browserhacks.*, selectors.browserhacks.*, values.browserhacks.*
  These are hard to maintain because they relies on _a lot_ of complex regexes.
• Remove atrules.documents.*
  This metric added very little value.
• Drop atrules.namespace.*
  This metric added very little value.
• Drop atrules.page.*
  This metric added very little value.
• Remove selectors.js.*
  This metric added very little value.
• Remove values.total
  This is the exact same value as `declarations.total`, so use that one instead;
• Remove values.colors.duplicate.*
• Add rules.selectors mean/median/mode/etc
• Add rules.declarations mean/median/mode
• Add selectors.specificity.*
• Add selectors.complexity.*
• Add atrules.keyframes.prefixed.*

Dependencies 📦

An upcoming trend in Node land is to have a closer look at the node_modules of your project. The running gag is to compare node_modules to a black hole, but the undertone is more serious: it has gotten out of hand and many projects face insane install times with all the environmental impact that comes along with that. To turn this trend, projects like PostCSS and Vite have gone the route of closely inspecting their dependencies and replacing big libraries with smaller alternatives.

For this project it meant getting rid of a whole list of my own dependencies, as well as swapping existing ones with smaller and faster alternatives. The biggest change in dependencies is that all existing dependencies have turned into a single dependency: css-tree. CSSTree is amazing and I am a big fan of the work of CSSTree’s author Roman Dvornov.

For devDependencies, I’ve replaced Ava with Uvu (by Luke Edwards). Uvu is insanely fast and I find it easier to use than Ava because it doesn’t rely on magical global variables.

Conclusion

Let’s hope this new version can serve the community well the next couple of years. The previous version that ran on PostCSS was released in 2017, so I hope there’s not another big rewrite for the next couple of years. Enjoy!

Bart Veneman

For more than a year I’ve been working behind the scenes on a complete rewrite of the CSS analyzer that powers all of Project Wallace. Although it’s not in a production-ready state, I decided to take it for a test run on projectwallace.com’s online CSS analyzer. And the results were staggering. It’s so much more stable than the previous version. This was one of the (many) design goals for the new version, but to see it work out in real life brought absolute joy.

Apart from implementing this new analyzer, I thought it would also be a good time to give the analyzer page a complete overhaul. The new design focuses more on high-level graphs and average/median/maximum/minimum numbers for a lot of metrics. And of course, the good-old existing details like the color bar, font-size chart are also still there.

Another new thing is that the analyzer now runs on your machine instead of running on a serverless function. Less HTTP roundtrips means better stability and improved performance. Even low-end devices benefit from running the analyzer locally, because the analyzer runs in a WebWorker and doesn’t block the main JS thread while doing heavy calculations.

Here’s a list of what you can expect from the new online CSS analyzer:

• Charts for getting a quick overview of stylesheet complexity
• A chart for selector complexity
• More concise lists for font-sizes, colors, etc.
• The ability to sort colors, font-sizes, z-indexes, etc.
• Big reduction in errors; You’ll only get an error now if your site can’t be reached for scraping the CSS.

I really hope you enjoy the new analyzer as much as I do and if you have ideas or suggestions to improve it, let me know on Twitter via @projectwallace!

With COVID-19 raging across our planet, sales for Project Wallace have pretty much dried up. Hardly any new paying customers are showing up. And I get that. These are incredibly challenging times. This is probably not the time to make (even a tiny) investment in a tool like Wallace, that you don’t strictly need anyway. This is why I have decided to move my attention to serving the developer community with writing documentation for all Project Wallace’s CSS metrics.

On writing docs

There are so many different metrics in Project Wallace and there’s no good explanation for any of them to be found. This needs to change. To do that, I have created a /docs folder and copied every existing CSS metric and created a Markdown file for it. From here I have started writing documentation. For at least 130 Markdown files.

Writing documentation that someone might actually want to read

Truth be told, I think the progress is pretty slow. I’ve been looking at many websites to figure out what makes documentation pages right. Websites like Mozilla Developer Network and TailwindCSS make it look easy, but look at the details that go into these pages. Here’s a small list of things that I think they do a great job of documenting:

• Code and usage examples.
• Versioning. It’s so useful to have a browser compatibility table or a note about some thing being deprecated or removed.
• Short paragraphs of explanations. No-one wants to plough through a pile of unreadable text.
• Beautiful design. These docs are pleasant to the eye.
• Linkable sub-headings. Don’t underestimate the power of being able to link to a heading far below the fold of a page. I love it when a heading is clickable and gives me the url of that exact heading so I can easily share it.
• Links to related content. It can be useful sometimes to read more about a certain topic on the same or a different website.
• A link to edit the given page directly on GitHub. This is what makes open source great, I think. There is no easier way to get started in OSS than to write or change some documentation.

Certainly I’m going to take a couple of these goodies and apply them to Wallace’s documentation pages!

The way forward

This is where I just need to put in the effort and write all the pages. It’s quite the task I’ve set out for myself, but it helps to have a big chunky checklist in Basecamp and seeing a little progress almost every day. I’ll get there. Eventually.

TLDR; Getting all CSS from a webpage requires a couple of different methods and some filtering. Go straight to the summary or the GitHub repository.

Project Wallace would be nowhere without the prior art of CSS Stats. They came up with get-css and this got me started in figuring out how to scrape CSS myself. Their algorithm is as simple as it is genius.

• Take all <link> tags from the page, go to it’s href and take the CSS
• Follow any @import rule and take it’s CSS
• Take all <style> tags from the page and take it’s CSS
• Follow any @import rule and take it’s CSS
• Combine all these chunks of CSS into a single piece.

When this approach doesn’t work

At the moment, they haven’t included a way to scrape inline styles. I don’t know whether that’s intentional or not. For pages that utilize CSS-in-JS, the above method will not work. For that we need a browser that is able to evaluate styles at runtime, and looking at <link>s and <style>s is not enough. And with the rise of usage of CSS-in-JS, it’s time for an improved version.

The in-depth way

The complicated way of getting all CSS involves a (optionally headless) browser and three key ingredients:

• The CSS Coverage API (available in Puppeteer, so available for Firefox and Chromium-based browsers).
• The HTML StyleSheets API
• A plain old document.querySelectorAll()

The algorithm

For the complete algorithm, check out the source code GitHub. The short and readable version is something like this:

• Start the CSS Coverage reporter
• Go to the webpage
• Stop the CSS Coverage reporter
• Get all CSS-in-JS and <style> tags with document.styleSheets
• Get all inline styles with document.querySelectorAll('[style]')
• Combine all chunks of CSS in a single chunk.

Coverage API

The CSS Coverage API gives us all <link> tag CSS (and their @imports). It also finds a lot of <style> CSS, but not the ones that were created with JavaScript, so we’re ignoring those.

await page.coverage.startCSSCoverage()
await page.goto(url, { waitUntil })
const coverage = await page.coverage.stopCSSCoverage()

const links = coverage
	// Filter out the <style> tags that were found in the coverage
	// report since we've conducted our own search for them.
	// A coverage CSS item with the same url as the url of the page
	// we requested is an indication that this was a <style> tag
	.filter((entry) => entry.url !== url)
	.map((entry) => ({
		href: entry.url,
		css: entry.text,
		type: 'link-or-import'
	}))

Source on GitHub

document.styleSheets API

With document.styleSheets we have access to all <style> tags that were server rendered, client-side rendered and all CSS that was generated with StyleSheet.insertRule(), as used in many CSS-in-JS frameworks.

// Get all CSS generated with the CSSStyleSheet API
// This is primarily for CSS-in-JS solutions
// See: https://developer.mozilla.org/en-US/docs/Web/API/CSSRule/cssText
const styleSheetsApiCss = await page.evaluate(() => {
	return (
		[...document.styleSheets]
			// Only take the stylesheets without href, because those with href are
			// <link> tags, and we already tackled those with the Coverage API
			.filter((stylesheet) => stylesheet.href === null)
			.map((stylesheet) => {
				return {
					type: stylesheet.ownerNode.tagName.toLowerCase(),
					href: stylesheet.href || document.location.href,
					css: [...stylesheet.cssRules].map(({ cssText }) => cssText).join('\n')
				}
			})
	)
})

Source on GitHub

Inline styles

Now, this part may be a bit controversial, but I think it’s worth to look at inline styles as well as all the rest. It’s often overlooked, but many WordPress Themes, Magento plugins and other Big Web Players© utilize inline styles for their themes and plugins. There’s one catch, though. A CSS Rule consists of one or more selectors and zero or more declarations. The declarations are the ones present in the style="", but there is no selector. That’s why I decided to give each individual block of inline styles it’s own [x-extract-css-inline-style] selector. This way, it’s possible to count the amount of inline style attributes after they were extracted from the page.

// Get all inline styles: <element style="">
// This creates a new CSSRule for every inline style
// attribute it encounters.
//
// Example:
//
// HTML:
//    <h1 style="color: red;">Text</h1>
//
// CSSRule:
//    [x-extract-css-inline-style] { color: red; }
//
const inlineCssRules = await page.evaluate(() => {
	return (
		[...document.querySelectorAll('[style]')]
			.map((element) => element.getAttribute('style'))
			// Filter out empty style="" attributes
			.filter(Boolean)
	)
})
const inlineCss = inlineCssRules
	.map((rule) => `[x-extract-css-inline-style] { ${rule} }`)
	.map((css) => ({ type: 'inline', href: url, css }))

Source on GitHub

Bringing it all together

The final step is to take the CSS of every step and merge that into one giant chunk of CSS:

const css = links
	.concat(styleSheetsApiCss)
	.concat(inlineCss)
	.map(({ css }) => css)
	.join('\n')

That’s it! A lot of work to get some CSS off of a page, but so far it’s the most reliable way I’ve found to do it.

The people at Chrome DevTools are joining the CSS Analytics game! Harry Roberts posted a tweet showing a screen in Chrome that lists colors on a page, complex CSS selectors, and more.

This is awesome. We need developers and designers to be more aware of the branding and complexity they create in their websites. And more players in this field means that there is an interest. If more people are going to show interest in these metrics, that means that more people will be inclined to use Project Wallace. 😁

I am curious to see where the Chrome folks will take this new addition to their (already huge) ecosystem of devtools. They have a huge benefit over Project Wallace, because they have way more context over all HTML and CSS, whereas Project Wallace only does static analysis of the CSS. Martin Donath (@squidfunk) already gave a nice presentation about this concept, and I think he and the DevTools team are on the right track. Good stuff!

Now, if I could only find out how to enable this Chrome experiment…

In the previous blog post I announced that Project Wallace now supports analysis of animation-duration and transition-duration. One of the neat things about Project Wallace is that it always shows all your values sorted in a sensible way. For example, font-sizes are sorted from small to large, colors are sorted by hue, etc. So it only makes sense to sort CSS <time> values from short to long. Enter css-time-sort.

The functional requirements

• Sort durations from short to long
• If a ms value is the same as a s value, sort the ms value first
• Be able to sort an array of ['1s', '200ms'] with the native .sort() method

With this relatively simple piece of code it’s possible to sort an array of CSS durations like so:

const { sortFn } = require('css-time-sort')
const sorted = ['1s', '200ms'].sort(sortFn)

// RESULT:
// => ['200ms', '1s']

Check out the source code on GitHub.

Animations and transitions are becoming part of many design systems. In the early days of style guides it used to be enough to keep track of font-sizes and colors. But these days design systems have evolved into full-blown user experience documents and animations are now first-class citizens. That’s why Wallace now also analyzes animation-related properties. Let’s take a look at the new features.

Animation and transition durations

Most design systems with animations have standardized their animation durations. The animation-duration is the time it takes from the start of an animation until it has finished.

.example {
	/* in seconds */
	animation-duration: 2s;
	/* in miliseconds */
	animation-duration: 200ms;

	/* with shorthand notation */
	animation: 2s animationName;
	/* with shorthand AND animation-delay */
	animation: 2s animationName 1s linear;

	/* with transition shorthand */
	transition: color 200ms ease-in;
}

Analysis result:

{
	"values.animations.durations.total": 5,
	"values.animations.durations.totalUnique": 2,
	"values.animations.durations.unique": [
		{
			"value": "200ms",
			"count": 2
		},
		{
			"value": "2s",
			"count": 3
		}
	]
}

The Wallace CSS Analyzer finds an animation-duration of 2s or 200ms for all these declarations. Note that Wallace also analyzes transition-related declarations.

Animation and transition timing functions

Similar to analyzing animation-durations, the Wallace CSS Analyzer looks at animation and transition timing functions. Timing functions can be keywords like linear, or ease-in-out, but also cubic-bezier(0, 1, 1, 0) or even steps(4, step-end). These timing functions add liveliness to your animations and a lot of studies have been done to optimize timing functions. So once you have found the perfect timing for your animation, it’s good to stick to it.

.example {
	transition: background 0.2s ease-in-out;
	animation: 2s animationName steps(4);
	animation-timing-function: cubic-bezier(0, 1, 0, 1);
}

Result:

{
	"values.animations.timingFunctions.total": 5,
	"values.animations.timingFunctions.totalUnique": 2,
	"values.animations.timingFunctions.unique": [
		{
			"value": "cubic-bezier(0, 1, 0, 1)",
			"count": 1
		},
		{
			"value": "ease-in-out",
			"count": 1
		},
		{
			"value": "steps(4)",
			"count": 1
		}
	]
}

Next steps

These reports are also available in projectwallace.com, Wallace CLI and Constyble. What are you going to do with these reports? What scary values did you find? Let me know on Twitter!

After using Project Wallace for quite some time, I found it hard sometimes to compare projects. For example, Facebook.com’s CSS is way larger than that of Twitter.com, but that’s because it has some base64-encoded fonts inlined in their @font-face declarations and parts of either website aren’t minified. So what is the best option to compare project sizes at a glance? Other programming languages have figured this out before: the Lines Of Code metric.

What is Lines Of Code

From Wikipedia:

Source lines of code (SLOC), also known as lines of code (LOC), is a software metric used to measure the size of a computer program by counting the number of lines in the text of the program’s source code.

So we use SLOC to determine the size of bunch of code. This works for CSS too! Let’s discuss LOC and SLOC in relation to CSS.

Lines Of Code for CSS

Lines of Code in relation to CSS is basically all your CSS, split by newlines. It actually just is that for Project Wallace. Checkout the source code for that:

const splitLines = require('split-lines')
const totalLinesOfCode = splitLines(rawCss).length

Note that splitLines() is basically string.split(/\r?\n/).

Source Lines of Code for CSS

There are three things in CSS that are important to keep track of when counting lines:

• At-Rules (@media queries, @font-face rules, @keyframes rules, etc.)
• Selectors (#header, .some-list, h1 > span)
• Declarations (color: blue)

You might wonder why rules aren’t counted here, but rules only consist of selectors and declarations. The source code for counting Source Lines Of Code in CSS is seemingly simple as well:

const totalSourceLinesOfCode = atRules.length + selectors.length + declarations.length

Here is a practical example of counting Lines Of Code in CSS:

/* 2 Source Lines Of Code */
.selector {
	color: blue;
}

/* 4 Source Lines Of Code */
.selectorA,
#selectorB {
	color: red;
	border-radius: 3px;
}

/* 5 Source Lines of Code */
@media (min-width: 400px) {
	.selector,
	.another-selector {
		color: green;
		background: yellow;
	}
}

/* 4 Source Lines of Code */
@media (min-width: 400px) and (max-width: 800px) {
	@supports (display: grid) {
		.deep-selector {
			color: tomato;
		}
	}
}

Closing thoughts

There is still a lot more counting to do, but with regards to Lines Of Code, this is pretty much it. The next step for @projectwallace/css-analyzer is to calculate the cyclomatic complexity for CSS. But that’s a whole different can of worms.

Integrating Constyble into your build process will help you automate complexity testing for CSS. Depending on how you actually integrate, it will fail your build if some unexpected complexity is detected. And with the latest release error output is even more clear, so fixing those issues should be a lot easier. Let’s dive in.

Constyble configuration

For Constyble to do its job, we need a config file and some CSS to run our test against. The CSS part should be easy. You probably already do some kind of processing your CSS into a final .css file. We use that CSS file to run our tests against. Constyble by itself does not know what to check, so we need to provide a configuration with thresholds. Here is a small piece of a configuration I use for Project Wallace itself:

{
	"selectors.identifiers.average": 1.45,
	"values.colors.totalUnique": 25,
	"values.colors.unique": [
		"hsl(0, 70%, 42%)",
		"hsl(42, 100%, 55%)",
		//... [truncated] ...
		"hsl(0, 0%, 0%)",
		"rgba(0, 0, 0, 0)"
	]
}

In short, I expect the average selector to not contain more than 1.45 identifiers. And no more than 25 unique colors and no other colors than the ones I provided. Check the Constyble readme if you want to know more about setting up Constyble.

CI configuration

For Constyble to become most effective, we need to run it after we’ve created a Pull Request. If someone makes a change to our CSS that increases the complexity, we need to prevent that change from being added to our codebase, or update our Constyle config accordingly.

The ‘trick’ is to run Constyble in your NPM test script. It will look something like this package.json:

{
	"name": "my-package-name",
	"scripts": {
		"test": "constyble styles/main.css"
	},
	"devDependencies": {
		"constyble": "^1.1.0"
	}
}

Here is an example repository that includes the example above. This example repo has an integration with Travis, so that every push and Pull Request will run the npm test script to validate that CSS changes do not exceed the thresholds set in .constyblerc.

That’s all there is to it. Do you find this a useful addition to your tool chain? Let me know via Twitter!

TLDR; there’s no tracking on Project Wallace.

A recent episode of the REWORK podcast triggered me to question the only client-side script that Project Wallace contains: Google Analytics. The folks at Basecamp had decided to become a 100% Facebook-free business. One of the reasons being that Facebook is more and more known for privacy-related scandals. It got me thinking about the privacy of my users. I decided that there is no good reason to include a library like Google Analytics (GA) on Project Wallace.

Reasons to remove the Google Analytics snippet

• I have no idea what Google does with the data it gathers, and it just doesn’t feel right that I cannot control how much data it gathers and shares.
• I’m no GA expert, and I don’t even know how to setup goals or advanced tracking, so all I do is including the default snippet and hoping that some day something smart can be seen.
• The snippet is only loaded if the browser did not have ‘Do Not Track’ (DNT) enabled, because I tried to be thoughtful of users’ privacy preferences. This leads to incomplete tracking results and might give misleading insights.
• The snippet isn’t loaded if you have any kind of tracking blocker. Again, leading to misleading results.
• Loading client-side JS is essentially making the site slower. The impact of a default GA snippet is pretty minimal, but still, it’s going to make the site load slower.

The GA snippet was removed on 28 January 2019, making Project Wallace completely tracking-free. As a user of many other sites, I always hope that other site owners think really hard about the trackers they include in their pages. Is it really necessary? Can your business live without it? Are there other, less-invasive ways of gathering the data points you need to answer your questions?

Default privacy on Project Wallace

• There are no tracking scripts. Actually, there are no client-side scripts at all, except on the pricing/payment page, because that’s powered by Stripe.
• Project Wallace only asks for a minimal amount of user data, like email and name. There’s nothing to steal or leak if you cannot give us any more data. So we won’t let you, except if you want to fill in your bio or relevant links in your profile.
• The only tracking that I can do is reading directly from the data storage and a tiny bit of logging around malicious requests, but that’s all. And it’s all I need.
• No data is shared with, or sold to anyone else. There never has been.

Anyway, I have decided that the data I need to improve Project Wallace will have to come from talking to the users of the platform. Luckily the @projectwallace Twitter account is picking up steam quickly and conversations are starting to take place. That’ll do. Stay safe everyone!

On the 1^st of January CSS-Tricks.com got a fresh coat of paint, and what a looker she is! Chris Coyier and his team have done an excellent job at delivering a stunning looking website. A redesign at such scale (CSS Tricks is no tiny website) is interesting to look at from a CSS analysis perspective, so let’s do that.

(If you just want to take a look at the raw numbers: Compare CSS Tricks 30 Dec 2018 21:18:23 to 1 Jan 2019 20:27:56)

A quick overview of numbers

Here are some numbers that’ll tell us just how big this redesign has been. These are some stylesheet-wide numbers that tell something about the CSS in general.

The drop in filesize is one of the most significant changes. A reduction of more than 40%! That is a massive achievement and I suspect the team have thrown away a large chunk of the previous codebase that became obsolete.

Changes in design

The most notable change in a redesign is the visual aspect of things, so let’s find out how that reflects on the brand-related metrics in the statistics.

The amount of unique colors and font-sizes have decreased quite a lot. I suspect that the team focused on building a more consistent looking UI. Fun fact from the font-family department: no more icon fonts!

Changes in complexity

Complexity in CSS is hard to define based on a couple of numbers, but here is a small list of numbers that I use to audit a codebase that I don’t own on complexity.

One metric in particular draws my attention here: average identifiers per selector. This metric is a tough one to improve and seeing that it went down with a whopping 17% just blows my mind. That means that a lot of selectors have gotten a lot less nesting. In terms of complexity that means that the CSS is a lot less tied to the HTML, which is usually a good thing. Also, having a lot less ID selectors means that there’s a whole lot less of specificity to deal with.

Closing thoughts

I think the CSS-Tricks Team have done a great job at this redesign. The design aspect is excellent and it feels so much fun to browse around the site. While having ’good’ stats was certainly not something that the team had in mind when working on the redesign, I think they did an excellent job on decreasing complexity and increasing cohesion. Bravo!

I would love to read a blog post from the engineering/design team that created this new design to see what they think about these numbers.

I love looking at the color-metric pages of projects and I found a pattern while browsing through a bunch of projects. Many of them have multiple notations for the same color, like #000 and rgb(0, 0, 0) that result in the same black color. I’m calling them aliases. I’m pretty sure that these aliases are not intentional, so keeping track of them may help us understand why they appear and how to fix them.

Examples

First, some examples to show you what I mean by aliases:

• cloud.google.com
• facebook.com
• stackoverflow.com

What does it mean having aliases in my CSS?

To my experience, this usually means one of the following things:

• Colors are not standardized in your codebase.
  Projects like Tailwind and Bootstrap define all their colors in variables and use those variables in the rest of their codebase. As long as you use a variable for any color, it means that you’ll always use one of the predefined colors.
• Code isn’t minified at all or temporarily broken.
  I’ve seen a couple of cases where websites started serving un-minified CSS, just by looking at their CSS colors. Where they just had #000 initially, they suddenly added #000000 too and the same for a lot more colors.
• A piece of CSS that you don’t control is loaded.
  Very often a piece of CSS is loaded that belongs to a third party plugin or some advertiser. You probably can’t control the CSS that is in their source, so if they decide to use #f00 and you use red instead, there’s not a lot you can do.
• Colors are created dynamically.
  Some developers have a list of base colors, like in the above example of Tailwind. To have a list of shades for every color they apply a transformation to the colors to darken, mix or saturate them. Most preprocessors like Sass, Styles or Less allow you to do something like mix(#fff, #000, 50%). The resulting color might be a color that is already in your definitions, but in a different notation, depending on what the preprocessor decides is best.

Are aliases bad?

No, they are not. As long as a browser can understand the different color notations and paint them on a screen, I don’t see why this could be harmful.

What’s the benefit of fixing aliases?

The most obvious benefit is that you can inspect your codebase outdated or unused pieces of CSS. A certain color notation could be used in only an old part of your application that could be removed entirely. Secondly, there is the tiniest benefit in compression of the CSS file if there are more common substrings. This benefit is negligible, so it should not trigger you to refactor your codebase to remove all aliases.

How can I fix aliases?

A good CSS minifier should be able to fix most or all aliases. A minifier like CSSNano parses all colors and tries to use shortest possible notation for each of them. The second option is to go to your project and manually ctrl/cmd + f your way through your CSS, but that’s probably not such a good idea. It will take a lot of time and the benefits will only be small.

TLDR; Sorting colors in CSS is hard. I’ve found a method to make it look pretty decent (highly opinionated): Color Sorter repo on Github

One of the goals that I’ve had since the inception of Project Wallace is to show which colors are present in your CSS. Ever since the beginning the most feedback has been around the color analysis. People seem to enjoy a list of colors ¯_(ツ)_/¯. One thing that bothered me however was that it was hard to visually grep how colors were related so I decided to start sorting them.

The solution

My knowledge of color theory is limited to the basics of the color wheel, so I’m using this as my starting point. I also already know that I want to make a clear difference between black-grey-white values and saturated colors. Thanks to TinyColor every color can be converted to an HSL value, so I can use the hue, saturation and lightness properties of each color. So, here we go:

1. Sort the colors by hue (red/yellow/green/blue/purple (0-360) degrees on the color wheel)
2. If the hue of two colors is the same, order them by saturation
3. Take every color in the grey spectrum (meaning that the saturation equals 0), and move that to the end of our color list
4. Order the grey-ish colors by their alpha channel
5. If the alpha channel is the same for both colors, sort them by lightness

Take a look at the examples in the repo to see the results for several well-known sites.

The bad parts

• It is pretty much impossible to properly handle the differences in the alpha-channel (opacity). A color that is 90% transparent will look totally different than that same color with 0% transparency.
• This sorting is based on my own taste and has no solid base in color theory. It just needs to look good for me.

Woof! 🐶 Introducing Gromit, a guard dog for your CSS. It is built on top of Project Wallace’s CSS Analyzer and checks if your final output CSS does not exceed any tresholds that you’ve set.

A quick look

Gromit is at his best when you let him play in your build pipeline. You feed him your CSS and a configuration with tresholds, and he will entertain himself.

npm test
> cat my-concatenated-styles.css | gromit --config=.gromitrc

TAP version 13

# Subtest: atrules.fontfaces.totalUnique
    ok 1 - atrules.fontfaces.totalUnique should not belarger than 1 (actual: 1)
    1..1
ok 1 - atrules.fontfaces.totalUnique # time=2.298ms

# Subtest: atrules.mediaqueries.totalUnique
    ok 1 - atrules.mediaqueries.totalUnique should notbe larger than 11 (actual: 11)
    1..1
ok 2 - atrules.mediaqueries.totalUnique # time=1.169ms

# Subtest: selectors.id.total
    ok 1 - selectors.id.total should not be larger than 0 (actual: 0)
    1..1
ok 3 - selectors.id.total # time=0.877ms

# Subtest: selectors.js.total
    ok 1 - selectors.js.total should not be larger than 0 (actual: 0)
    1..1
ok 4 - selectors.js.total # time=1.455ms

# Subtest: values.colors.totalUnique
    ok 1 - values.colors.totalUnique should not be larger than 28 (actual: 28)
    1..1
ok 5 - values.colors.totalUnique # time=1.041ms

1..5
# time=40.526ms

 ✔ "Well done, lad! Very well done..."
✨  Done in 2.66s.

The configuration

The configuration is based on all the metrics that Wallace’s CSS Analyzer can measure. All metrics are optional by default. Here’s an example from the Gromit repo readme:

.gromitrc config file example

{
	// Do not exceed 4095, otherwise IE9
	// will drop any subsequent rules
	"selectors.total": 4095,
	"selectors.id.total": 0,
	"values.colors.totalUnique": 2,
	"values.colors.unique": ["#fff", "#000"]
}

This example configuration disallows having more than 4095 selectors in total, disallows any ID selectors, and allows only the colors #fff and #000 to be present in the CSS.

Why not use CSS linters?

Who said you can’t use both? Linters like Stylelint, EsLint and many more have proven to be very helpful in many ways, but we usually configure them to look at our to-be-transformed CSS, like Less or Stylus. That means that we don’t often look at the CSS that these preprcessors generate. Using a preprocessor sometimes makes it hard to guess what CSS eventually comes out. Gromit looks at the actual CSS and warns you if some Sass mixin accidentally created a color you don’t want to exist.

Example of preprocessor creating undesired values

// This will produce a color based on your $grey variable,
// but darker and less opaque
.box {
	box-shadow: 1em 1em 1em opacify(darken($grey, 10%), 0.5);
}

Setting up Gromit or any linter is probably equally hard or easy for both (which isn’t very hard).

When I was scrolling to some of my competitors’ websites, I noticed that analyze-css by Maciej Brencz was counting the amount of empty rules in your CSS. It seemed to me that this was easy to add to Wallace, so I did it in a short amount of time. Here is the explanation that will eventually end up in the docs in some form:

A rule (or ruleset) is considered empty when it contains no declarations. Whitespace is ignored when determining whether a rule is empty or not.

Examples

/* This is an empty rule */
.header {
}

/* This is also an empty rule */
.header {
}

/* This is not an empty rule */
.header {
	margin: 10px;
}

Please note that at-rules are not part of this analysis, so an empty media query rule is not counted here. That might be a future improvement.

Finally, a link to the commit that contains this change.

As of today it is possible to install css-analyzer via NPM! I released it as 1.0.0, so it means that as from now I am committed to adhering to SemVer and keeping the API stable until a next major version. I hope to find more users and contributers by publishing it to NPM.

npm i @projectwallace/css-analyzer

Here is some piece of CSS you’ve probably seen before:

@font-face {
	font-family: 'MyCustomFont';
	src: url('/path/to-font.woff2');
}

.my-component {
	font-family: 'MyCustomFont';
}

When it comes to analyzing CSS it is tempting to count that font-family and src inside the @font-face as regular properties, but technically they are not. They are descriptors.

The theory

A CSS descriptor defines the characteristics of an at-rule. At-rules may have one or multiple descriptors. Each descriptor has:

• A name
• A value, which holds the component values
• An “!important” flag, which in its default state is unset

CSS Descriptor, MDN web docs

In the case of our example, the font-family and the src are the descriptors of the @font-face at-rule.

Common CSS parser implementations

Most CSS parsers, like PostCSS and ReworkCSS take those lines as declarations because it fits better in the Abstract Syntax Tree that they are constructing. And that’s fine, because these parsers are aimed at performing operations on the CSS to transform it into something else. But when it comes to analyzing the tree, we must take note that the ‘properties’ inside @font-faces are actually descriptors.

Consequenses for CSS statistics

• Less properties are counted than you might expect
• Specifically: less font-related properties, which usually means there are less font-families to show in your projects’ font-family details pages

More information

Read more about CSS descriptors:

• The W3C Spec If you’re into the fine details of the @font-face descriptors
• CSS font-family Descriptor A readable explanation, and more great docs about CSS
• @font-face at MDN Docs

So you start making a brand new CSS analyzer and you’re all fired up to get to work on it. You find a CSS parser, transform the AST into some kind of statistics and there you go: your own pretty little analyzer! But… in this case I made a mistake very soon in the process: choosing Reworkcss over PostCSS, because PostCSS seemed so much harder to work with. Of course I was wrong.

The old way

1. Let Reworkcss transform the CSS into an AST;
2. Analyze the AST, including making the AST simpler in some cases; For example, Reworkcss creates an AST that reflects the actual tree structure of the CSS file, so nested Media Queries could appear, nested rules and many more complex structures. This is ok if you want to do some in-depth analysis of things, but for a quick analysis it’s easier to have a flat structure, like PostCSS does. In the case of using Reworkcss we have to do some recursion at a couple of places to make sure that we don’t miss out on some (edge) cases.
3. Unit tests for analysis; Only test the output of the whole application, without intermediate steps for the parser for example. If something in the parser fails, it’ll fail in the eventual output. That’s not the right way to approach it.
4. Done.

The new way

1. Let PostCSS create a flat AST; And flat means that there’s no need to worry about nesting or other complex structures. When asking for all Media Queries, it returns all Media Queries, regardless of the document structure. That’s exactly what we need.

2. Transform the AST a tiny bit into something a little more suitable for analyzing; By creating an intermediate layer for the AST, we’re able to write tests for it and we’re making it easier to switch between parsers, because they will all be turned into simple arrays of strings of tiny objects.

3. Run tests for the analyzable AST;

4. Analyze the CSS; Run the analysis on the simple arrays and objects created in step 2.

5. Run tests for the analysis;

6. Done!

PostCSS is actually easier to work with than Reworkcss because of the ease of which you can get all rules, instead of having to go through the whole document yourself. It pays off to split even a relatively small application like this one into multiple layers to increase testability and maintainability. Have fun using Project Wallace CSS Analyzer!

Today marks the point where a PHP library accepting incoming HTTP requests, parsing CSS into an Abstract Syntaxt Tree (AST) and analysing it into a hash of statistics was released on GitHub. And abandoned immediately.

The reason was explained in the previous blog post: it is too slow to process a lot of stylesheets, so work on a NodeJS based system has already started and expected to be ready for use somewhere late this summer. The now published and abandoned PHP library served as a great starter for doing the first stages of this rather large project. It was easy to setup, easy to test and a pain to deploy.

The architecture of the PHP library is a mess, because the single project serves three different purposes:

• A REST API that accepts incoming CSS for analysis and serves historical data for those analysis
• A CSS Parser (based on Parker), because it was hard to find a PHP library that parsed CSS into a AST
• A CSS analyser that created an analysis based on the CSS AST

That alone already made the project poorly constructed, but also the less than ideal construction of using an out-of-date version of Slim and just not enough knowledge of and care for the PHP syntax made it a recipe for disaster. Everything worked quite well, a lot of tests have been written, but it just didn’t cut it. Stylesheets from sites like CSS-Tricks and Schiphol Airport caused the API to time out every time and increasing the timeout to 30+ seconds just didn’t make sense. Also, smarter developers will probably say that Dependency Injection, Domain Driven Design, and all that fancy stuff is missing or implemented incorrectly.

So there you have it: a new library that will not be worked on. Hope you enjoy the new one soon!

Today I released two libraries on GitHub that will ultimately power projectwallace.com! Both libraries are brand new and take part in replacing a slow PHP API that times out on a lot of CSS files. Because that’s such a big and important part of what Project Wallace is, I decided to make the open source. That way our fantastic community will get a chance to contribute to the Project.

css-collection

This project can be used to get a little more powers with arrays. I often found myself writing functions for sorting, making unique lists and getting the first and last item from a list. This repository takes care of those issues.

See the repository on GitHub: css-collection

css-analyzer

Here’s the real powerhouse of Project Wallace. This repository contains all the stuff that analyses CSS, from rules to values and from at-rules to stylesheet-wide stats. It currently is pretty basic and could definitely benefit from some more async operations, but because of it’s simplicity it’s pretty easy to maintain. The css-collection library is used quite a lot in this repository because of all the collections of selectors, values etc. that are in it.

See the repository on GitHub: css-analyzer

Next steps

The last step in replacing the slow PHP API is to write a new API, probably also in Node, since it can use the other projects as dependencies. 💖

In the meantime, keep an eye on the Project Wallace GitHub profile for updates that will most definitely come.

Hi. How are you? Just wanted to let you know that we’re going to do it! Wallace is going to be open for anyone to use this thing! It will be a hell of a journey, but let’s get started.

Before we start though, a small word of warning. This project will change and it will change a lot. Here’s a small breakdown of it:

• URI’s are going to change. No doubt about it. The current way they are used are too verbose and it would be nice to have cleaner, shorter URI’s but for now these have to do.
• The design will undergo some transformations here and there. Although the dark purple looks cool and has some character, the color scheme needs fixing and so does the general look and feel.
• Page layouts will very likely change to something more useful. The project overview page is now pretty cluttered with all kinds of graphs and the detail pages also could use some improvements here and there.

One thing that will not change a lot is the actual analysis of the CSS itself. All that is largely done and tested and will remain stable, apart from the occasional bug fix here and there.

So here we go: Project Wallace is live 🎉