Forem: Bart Veneman

CSS @imports are awesome

Bart Veneman — Fri, 22 Sep 2023 07:16:47 +0000

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.

Flexible URL syntax
Cascade Layers
Conditional imports: supports()
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.

CSS Day 2023 takeaways

Bart Veneman — Sun, 11 Jun 2023 20:08:56 +0000

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.

CSS Nesting
CSS Cascade Layers
CSS Container Queries
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.

Project Wallace should definitely help you figure out the complexity of your CSS, even when CSS nesting is present. It will involve a structural overhaul of the core of our CSS analyzer, but I feel strongly about this and our analysis should be able to help calculate Selector and AtRule complexity, even in complex situations.

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.

See the Pen @layer resolution by Bart Veneman (@bartveneman) on CodePen. Firefox (v113) devtools showing the cascade layers involved Chrome (v114) devtools showing the resolved layers as well as the resolved layer tree of all layers in the CSS.

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.

Wallace should add support for showing the layer tree as well and it's been something I've been thinking of for over a year now, because Bramus showed this excellent visual last year at the same conference (!).

This visual has been on my mind all year and I hope we can bring it to this silly little website very soon!

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.

Firefox devtools shows the actual size of the container element which makes for easy debugging, as well as showing the container-type, container-name and size query. Chrome devtools shows the container-name, container-type and size query.

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

One thing I would add to our own analyzer is to write detection for unused container-names and unknown named @containers. We warn for empty CSS Rules, so why not unused/undeclared container names?

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

This problem strengthens my belief that CSS shorthands are an anti-pattern and should be avoided in most cases. Maybe we should even go so far as actively warning against them on this website as they make auditing your CSS more complex too. Anyway, this could easily be a blog post in itself…

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.

Building a lightweight CSS formatter

Bart Veneman — Sun, 11 Jun 2023 20:02:20 +0000

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.

<img alt="Example output of formatted CSS that we need to audit" src="https://user-images.githubusercontent.com/1536852/244181349-9824fdf7-abfe-45f5-b2c4-859d87f7e8d1.png">
<figcaption>CSS that is being audited where the source code was originally minified, making the auditing process difficult, because those lines become pretty much unreadable.</figcaption>

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 realised 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:

Every AtRule starts on a new line
Every Rule starts on a new line
Every Selector starts on a new line
A comma is placed after every Selector that's not the last in the SelectorList
Every Block ({}) is indented with 1 tab more than the previous indentation level
Every Declaration starts on a new line
Every Declaration ends with a semicolon (;)
An empty line is placed after a Block, unless it's the last in the surrounding block
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's 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.

A deep dive into the CSS of Instagram.com

Bart Veneman — Mon, 06 Mar 2023 13:07:42 +0000

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 it their CSS analysis.

First impressions

Filesize	543 kB
Source Lines of Code	27,992
Rules	10,314
Selectors	10,449
Declarations	16,235

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 is 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's 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 that they just eyeball the page layout and apply media queries where they see fit.

Query	Count
`(max-width: 767px)`	340
`(min-width: 1025px)`	321
`(min-width: 768px) and (max-width: 1024px)`	319
`(max-width: 899px)`	52
`(min-width: 900px)`	20
`(max-width: 900px)`	14
`(max-width: 905px)`	3

Excerpt from instagram.com's @media at-rules. Note the almost-but-not-quite-identical breakpoints around 900px.

`@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 go debug that part of their CSS.

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

Excerpt from Instagram's 140 unique @keyframes with randomly generated names.

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 are able to 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's 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 is.

An insteresting 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 themhave 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.

This post is the first part of a series of posts focusing on disecting the CSS of popular websites. The goal is to see how big companies structure their CSS, what mistakes they make and what we can learn from their CSS architecture.

Project Wallace 2022 in Review

Bart Veneman — Fri, 30 Dec 2022 10:09:41 +0000

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.

	2020	2021	2022
Visitors	6,510	10,942	20,577
Page views	24,767	40,256	46,689

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

	2020	2021	2022
Analyze CSS (url)	742	3,161	6,341
Analyze CSS (raw input)	8	503	2,327
CSS Code Quality (url)	-	-	4,762
CSS Code Quality (raw input)	-	-	758
Scrape CSS	138	264	248
Prettify CSS	-	-	37

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!

Things I learned giving CSS workshops

Bart Veneman — Mon, 05 Dec 2022 15:33:55 +0000

Being so frustrated at the capacity of modern day Frontend Devs to write 'proper' HTML and CSS, I decided to host a worskhop. For everyone interested, individually, minimal 3 hours each. These are the things I learned. About the devs, but also about myself and frontend in general.

The setup

Bring a design you like. A magazine, a dashboard, some conference site, whatever motivates you to build;
We'll start writing some meaningful HTML as we walk through the design, no wrapper <div>s allowed without purpose;
After the HTML is (mostly) done, we start writing CSS;
Work until satisfied or energy has run out.

The lows

Devs writing <input /> elements without <label> and without <form> (No description of the field, no place to send the data to…)
Devs wanting to write their own event handler to listen for keydown on said input to check if enter was pressed. (Please use a regular <form> instead, because hitting enter in the input field or pressin enter/space while the submit button is focused will submit the form)
Apply display: flex until it looks good(Trust me: flexbox is great, but not the solution for all your problems)
Wrap a div around pretty much anything because it might come handy when starting to write the CSS(No it doesn't and using a particular CSS framework put you in a mindset that you need to wrap every single element if you want to somehow align them. Even though the framework didn't advertise that at all.)
Nobody seems to have an idea about how position: absolute works. Like it's some kind of magic box and tinkering with it will eventually solve their issue;
Devs didn't recognise that their DevTools were telling them why their properties/values weren't working. DevTools do an excellent job these days of showing a warning when a declaration isn't applied because a parent element is missing a certain property, or some other reason. Clearly folks had never heard of this option;
Some folks thought it's only possible to create rows and columns using <div>s.I don't even…

The highs

We got to spend roughtly ~50% on writing the HTML in workshop that was supposed to teach them about CSS and everyone loved it, no exceptions! Folks were generally unaware of all the options available in HTML. Also, they were very open to the idea of building the HTML first and then solving the styling with CSS, instead of trying to let their HTML match the design as closely as possible;
Devs were really grateful for doing a walkthrough of these things together, as they felt it's so different from what they've always done but faster and with better results;
Folks are pretty excited when they see what's prossible in modern CSS (with pretty good browser support): CSS Grid, Flexbox "magic", accent-color and way more;
Devs were pretty much aware that images need an alt attribute 👍, but what to write in it is a mystery to them 👎;

Frequently asked questions during the workshop

How do I know when to use px, em or even something else? A recent article from Josh Comeau answers most of their questions: rem in most cases, em for some and hardly ever anything else (in our field, at least);
How does CSS Grid even work? It looks way too magical to me! Usually I refer them to either CSS Tricks or Wes Bos' excellent course on the topic;

How Project Wallace extracts all CSS from any webpage

Bart Veneman — Thu, 01 Dec 2022 13:10:03 +0000

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.

CSS complexity: it's complicated

Bart Veneman — Thu, 17 Nov 2022 09:09:57 +0000

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!

Forem: Bart Veneman

CSS @imports are awesome

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

Cascade Layers

Browser support

Import conditions

supports() in @import

Browser support

Media queries in @import

Browser support

Mixing it up

CSS Day 2023 takeaways

Contents

CSS Nesting

CSS Cascade Layers

CSS Container Queries

Scroll driven animations and the shorthand trash fire

Building a lightweight CSS formatter

The naive way: Prettier

CSSTree to the rescue

Fast CSS parsing

Creating a readable string of CSS

Tradeoffs

A deep dive into the CSS of Instagram.com

First impressions

CSS Rules

Selectors

At-rules

@media

@keyframes

Declarations

Properties

Values

Colors

Font-families

Project Wallace 2022 in Review

Notable releases

Traffic

Popular pages

Website activity

Ideas for the new year

Closing thoughts

Things I learned giving CSS workshops

The setup

The lows

The highs

Frequently asked questions during the workshop

How Project Wallace extracts all CSS from any webpage

When this approach doesn't work

The in-depth way

The algorithm

Coverage API

document.styleSheets API

Inline styles

Bringing it all together

CSS complexity: it's complicated

Selector complexity beyond specificity

More than just selector complexity

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

`supports()` in `@import`

Media queries in `@import`

`@media`

`@keyframes`

`document.styleSheets` API