26 May 2024 · code

A lot of new CSS features have shipped in the last years, but actual usage is still low. While there are many different reasons for the slow adoption, I think one of the biggest barriers are our own brains.

New feature fatigue

Right now, we’re in the middle of a real renai-css-ance (the C is silent). It’s a great time to write CSS, but it can also feel overwhelming to keep up with all the new developments.

Prominent voices at conferences and on social media have been talking about the new stuff for quite some time, but real-world usage seems to lag behind a bit.

Quick question: how many of these have you actively used in production?

👉 (Disclaimer: I’ve used one.)

All of these are very useful, and support for most is pretty good across the board - yet adoption seems to be quite slow.

Granted some things are relatively new, and others might be sort of niche-y. But take container queries, for example. They were the number one feature requested by front-end devs for a looong time. So why don’t we use them more, now that they’re finally here?

From my own experience, I think there’s different factors at play:

The support excuse

I can’t use [feature X], I need to support [old browser].

That old chestnut.
Browser support is an easy argument against most new things, and sometimes a convenient excuse not to bother learning a feature.

The answer there is usually progressive enhancement - except that’s easier to do for actual “enhancements”, if they are optional features that don’t impact the usability of a site that much.

For some of the new features, theres no good path to do this.

CSS Layers or native nesting for example are not something you can optionally use, they’re all-or-nothing. You’d need a separate stylesheet to support everyone.

And while support for Container Queries is green in all modern browsers, people still seem reluctant to go all-in, fearing they could break something as fundamental as site layout in older browsers.

Invisible improvements

Why use [feature X] if the usual way works fine?

Some of you might be old enough to remember the time when CSS3 features first hit the scene.

Things like border radius or shadows were ridiculously hard to do back in the day. Most of it was background images and hacks, and it required a substantial amount of work to change them.

Suddenly, these designs could be achieved by a single line of CSS.
Writing border-radius: 8px instead of firing up Photoshop to make a fucking 9-slice image was such a no-brainer that adoption happened very quickly. As soon as browser support was there, nobody bothered with the old way anymore.

A big chunk of the new features today are “invisible” though - they focus more on code composition and architecture.

Layers, Container Queries, etc are not something you can actually see in the browser, and the problems they solve may not be such an obvious pain in the ass at first glance. Of course they offer tremendous advantages, but you can still get by without using any of them. That might slow down adoption, since there is no urgency for developers to switch.

Examples and design trends

I don’t know where I would even use [feature X] in my project.

The initial use-case for container queries I always heard was “styling an element that could be in the main column or the sidebar”. I think that came from a very common WordPress blog design at the time where you had “widgets” that could be placed freely in different-width sections of the site.

Nowadays, the widget sidebar isn’t as common anymore; Design trends have moved on. Of course there are plenty of other use-cases for CQs, but the canonical example in demos is usually still a card component, and people seemed to struggle for a while to find other applications.

The bigger issue (most recently with masonry grids) is that sometimes the need for a CSS feature is born out of a specific design trend. Standards move a lot slower than trends though, so by the time a new feature actually ships, the need might not be that strong anymore.

Spec authors do a very good job of evaluating the long-term benefits for the platform, but they also can’t predict the future. Personally, I don’t think the new features are tied to any specific design - but I think it’s important to show concrete, real-world usecases to get the developer community excited about them.

Breaking the habit

Whatever the technical reasons may be, I guess the biggest factor in all of this are our own habits.

Our monkey brains still depend on patterns for problem solving - if we find a way of doing things that works, our minds will quickly reach for that pattern the next time we encounter that problem.

While learning the syntax for any given CSS feature is usually not that hard, re-wiring our brains to think in new ways is significantly harder. We’ll not only have to learn the new way, we’ll also have to unlearn the old way, even though it has become muscle memory at this point.

So how can we overcome this? How can we train ourselves to change the mental model we have for CSS, or at least nudge it in the new direction?

Re-thinking established patterns

If we want to adopt some of the broader new architectural features, we need to find ways to think about them in terms of reusable patterns.

One of the reasons BEM is still holding strong (I still use it myself) is because it provides a universal pattern of approaching CSS. In a common Sass setup, any given component might look like this:

// _component.scss
.component {
    // block styles
    position: relative;

    // element styles
    &__child {
        font-size: 1.5rem;
    }

    // modifier styles
    &--primary {
        color: hotpink;
    }

    // media queries
    @include mq(large) {
        width: 50%;
    }
}

The BEM methodology was born in an effort to side-step the cascade. While we now have better scoping and style encapsulation methods, the basic idea is still quite useful - if only as a way to structure CSS in our minds.

I think learning new architectural approaches is easier if we take existing patterns and evolve them, rather than start from scratch. We don’t have to re-invent the wheel, just put on some new tyres.

Here’s an example that feels similar to BEM, but sprinkles in some of the new goodness:

/* component.css */

/* Layer Scope */
@layer components.ui {
    /* Base Class */
    .component {
        /* Internal Properties */
        --component-min-height: 100lvh;
        --component-bg-color: #fff;

        /* Block Styles */
        display: grid;
        padding-block: 1rem;
        min-block-size: var(--component-min-height);
        background-color: var(--component-bg-color);

        /* Child Elements, Native CSS Nesting */
        & :is(h2, h3, h4) {
            margin-block-end: 1em;
        }

        /* States */
        &:focus-visible {
            scroll-snap-align: start;
        }

        &:has(figure) {
            gap: 1rem;
        }

        /* Style Queries as Modifiers */
        @container style(--type: primary) {
            font-size: 1.5rem;
        }

        /* Container Queries for component layout */
        @container (min-inline-size: 1000px) {
            --component-min-height: 50vh;
            grid-template-columns: 1fr 1fr;
        }

        /* Media Queries for user preferences */
        @media (prefers-color-scheme: dark) {
            --component-bg-color: var(--color-darkblue);
        }

        @media (prefers-reduced-motion: no-preference) {
            ::view-transition-old(component) {
                animation: fade-out 0.25s linear;
            }
            ::view-transition-new(component) {
                animation: fade-in 0.25s linear;
            }
        }
    }
}

My preferred way of learning new techniques like that is by tinkering with stuff in the safe playground of a side project or a personal site. After some trial and error, a pattern might emerge there that sort of feels right. And if enough people agree on a pattern, it could even become a more common convention.

One step at a time

When learning new things, it’s important not to get overwhelmed. Pick an achieveable goal and don’t try to refactor an entire codebase all at once.

Some new features are good candidates to test the water without breaking your conventions:

You can try to build a subtle view transition as a progressive enhancement to your site, or you could build a small component that uses container queries to adjust its internal spacing.

In other cases, browser support also does not have to be 100% there yet. You can start using logical properties in your project today and use something like postcss-logical to transform them to physical ones in your output CSS.

Whatever you choose, be sure to give yourself enough space to experiment with the new stuff. The devil is in the details, and copy-pasting some new CSS into your code usually doesn’t give you the best insight - kick the tyres a bit!

Finding inspiration

One thing I’d really love to see more of are “best practice” examples of complete sites, using all the new goodness. They help me see the bigger picture of how all these new techniques can come together in an actual real-life project. For me, the ideal resource there are (again) the personal sites of talented people.

• How do they structure their layers?
• How do they set up containers?
• What sort of naming conventions do they use?
• What problems are they solving, and how does the new architecture improve things?

Answering these questions helps me to slowly nudge my brain into new ways of thinking about all this.

Having said all that: you absolutely don’t have to use all the latest and greatest CSS features, and nobody should feel guilty about using established things that work fine. But I think it helps to know which specific problems these new techniques can solve, so you can decide whether they’re a good fit for your project.

And maybe we can still learn some new CSS tricks after all.

Published in [code] · 26 May 2024
Edit this Post