Is writing CSS in 2023 different or weird from what it was a few years ago?

In 2023, CSS is undergoing a rapid evolution, surpassing its previous pace of progress. With the introduction of new and upcoming features, the language has significantly changed the way it is written since the emergence of Flexbox and Grid years ago. In this article, Geoff Graham highlights the features that have greatly impacted his current CSS practices, while also mentioning those that haven’t had a considerable effect, at least not yet.

---

Is there anything in the world of front-end development that is evolving as rapidly as CSS these days? After a significant period of time following the introduction of groundbreaking features like Flexbox and Grid, observing the continuous release of new CSS features over the past few years has been akin to watching an exhilarating game of rugby on television. The pace of evolution is both exciting and, at times, overwhelming.

However, despite the abundance of new bells and whistles, one may wonder if these changes have truly revolutionized the way CSS is written. Undoubtedly, the introduction of new features has influenced my current CSS writing style, although not as dramatically as I initially expected.

Despite encountering numerous blog posts showcasing high-level examples and creative experiments utilizing these innovative features, practical applications in production or everyday use seem to be scarce. I remember how Sass gained widespread popularity in CSS tutorials, often being the preferred syntax for code examples and snippets. However, I haven’t witnessed the same level of organic adoption for features like logical properties, despite having full browser support for about two years now.

I want to clarify that I don’t intend to criticize anyone or anything. On the contrary, I am genuinely thrilled about CSS’s evolution. Many of the latest features fulfill long-standing desires of developers. Indeed, some of these features have found their way into my CSS code as well. While the impact may not be revolutionary, it has been enough to make the process of writing CSS more enjoyable than ever.

Let me share the various ways in which these CSS advancements have made a difference.

More And More Container Queries

Let me confess: I have never been fond of writing media queries for responsive layouts. The content’s behavior varies based on the viewport width and the component it’s placed within. Striking a balance for one component always involves a complex juggling act with the content in other components, leading to a clutter of media queries at seemingly random breakpoints. Although using Sass to nest media queries within a selector has made it somewhat bearable, it still doesn’t make the process of creating and modifying queries enjoyable, especially when presented with a new design and UI changes.

For me, container queries are the perfect solution. Now, I can encapsulate child elements within a parent container and rely on the container’s size to determine layout shifts without worrying about other surrounding components.

“I find container queries particularly appealing because they have a CSS-like essence. Being able to define a container directly within a selector follows a natural property-value structure, which eliminates the need for upfront mathematical calculations to determine breakpoints.”

.parent {

container-type: inline-size;

}

@container (min-width: 600px) {
.child {
align-self: center;
}
}

I continue to utilize media queries to create responsive layouts, although I predominantly employ them for larger designs that consist of grouped containers. By doing so, breakpoints become more foreseeable, and they can effectively target particular devices without the need to factor in the content within each separate container.

Learn About Container Queries

• CSS Containment Module Level 3 (W3C)
• “A Primer On CSS Container Queries”, Stephanie Eckles
• “CSS Container Queries: Use-Cases And Migration Strategies”, Adrian Bece
• “A Cornucopia of Container Queries”, Geoff Graham

Grouping Style In Layers

I really enjoy using this approach to manage the cascade! It allows me to wrap any reset or third-party CSS from frameworks neatly in a cascade layer and place them at the bottom of the file, ensuring my own styles take precedence.

Although I haven’t used cascade layers in a production environment yet, they have become my go-to choice for almost every CodePen demo I create. The good thing is that browser support is not an issue for this technique. However, when working on larger projects, I still rely on Sass for specific advantages, and I find it more comfortable to maintain styles in partialized files.

Yet, for isolated demos like those on CodePen where all my styles are in one place, cascade layers are perfect! I usually only need one layer for the base styles since non-layered styles have higher specificity than layered ones. As a result, my demo-specific styles remain clean, uncluttered, and still have the ability to override the base styles, making it incredibly convenient to access and manage them.

body {
display: grid;
gap: 3rem;
place-items: center;
}

@layer base {
body {
font-size: 1.25rem;
line-height: 1.35;
padding: 3rem;
}
}

Learn More About Cascade Layers

• “A Complete Guide to CSS Cascade Layers”, Miriam Suzanne
• “Getting Started With CSS Cascade Layers”, Stephanie Eckles
• CSS Cascading and Inheritance Level 5 (W3C)
• “Cascade Layers Are Coming To Your Browser”, Una Kravets”

 :is() And :where()

I frequently utilize these newer relational pseudo-selectors, not primarily for selecting elements based on relationships, but rather for effectively managing specificity. Unlike cascade layers, I find these selectors valuable in real-world applications.

The reason for this preference lies in the behavior of :is() – it determines specificity based on the most specific selector within its argument list, rather than the main selector.

/* Specificity: 0 1 1 */
:is(ol, .list, ul) li {}

/* Specificity: 0 0 2 */
ol li {}