Writing CSS In 2023: Is It Any Different Than A Few Years Ago? — Smashing Magazine

Container Queries Shift Responsive Thinking

Media queries never felt quite right for component-level responsive design. A component’s behavior depends on the space it actually occupies, not the viewport width, so juggling breakpoints across many components in the same viewport always involved compromise. Container queries solve that by letting child elements respond to their parent container’s dimensions.

Setting up a container is straightforward: define a selector as a container-type, and child elements can query that container’s size. This feels natural to CSS’s property-value model — no pre-calculating breakpoints or nesting media queries with preprocessor wrappers just to keep related styles together.

.parent {
  container-type: inline-size;
}

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

Media queries still have a place for page-level layouts that assemble multiple containers, where viewport-based breakpoints are more predictable. But the granular control container queries offer means less fighting with arbitrary breakpoints for individual components.

Cascade Layers for Organized Overrides

Cascade layers change how styles interact with the cascade by grouping rulesets into named layers with explicit priority order. Wrapping a reset or framework CSS in a layer keeps it tucked behind any un-layered styles, since un-layered rules take precedence over layered ones.

For single-file demos, one layer for base styles is enough. Demo-specific rules stay un-layered (and therefore higher priority), keeping them readable and easy to override while the reset and base styles stay neatly tucked away.

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

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

Production projects often still rely on Sass partialization for organization, which layers don’t necessarily replace. But for isolated snippets and experiments, layers offer a clean way to separate base styles from custom logic.

:is() and :where() Control Specificity

These relational selectors work well for their intended purpose, but their real value in daily CSS is specificity management. With :is(), the specificity of the entire selector equals that of the most specific argument in its list. :where(), by contrast, always contributes zero specificity regardless of its arguments.

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

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

That gives precise control. Need a ruleset to win? Wrap the selector in :is() to boost its score. Need global styles that anything can override? :where() keeps them effectively weightless.

A practical use case is containing :not() inside :where() so the negation selector doesn’t inadvertently raise specificity:

/* Specificity: 0 0 0 */
:where(:not(.some-element)) {}

This also eases naming pressure. BEM class names describe element function and relationships, which gets hard to maintain. Lower-stakes specificity means element selectors become viable for many cases, reducing reliance on elaborate naming conventions.

Modern Color Function Syntax

The revised syntax for rgb() and hsl() removes friction that prompted unnecessary function-name choices. The awkward question of whether to use rgba() vs. rgb() whenever opacity is needed disappears — alpha is now just a /-separated argument.

color: hsl(50deg, 100%, 50%);

/* Same */
color: hsla(50deg, 100%, 50% / 1)

That means one syntax, always. The newer oklch() and oklab() color spaces, now fully supported, extend this even further for perceptually uniform color manipulation.

color: hsl(50deg 100% 50% / .5);

Motion and Display Preferences Come First

Preference media queries made dark/light theming practical. But animation is where these queries have the most impact on workflow. The first consideration for any animation-related work is prefers-reduced-motion — not disabling motion entirely, but honoring the user’s choice for less movement.

:root {
  --bg-color: hsl(0deg 0% 100%);
  --text-color: hsl(0deg 0% 0%);
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg-color: hsl(0deg 0% 0%);
    --text-color: hsl(0deg 0% 100%);
  }
}

body {
  background: var(--bg-color);
  color: var(--text-color);
}

A common approach is slowing transitions down significantly rather than eliminating them:

@layer base {
  :root {
    --anim-duration: 1s;
  }

  /* Reduced motion by default */
  body {
    animation-duration: --anim-duration;
    transition: --anim-duration;
  }

  /* Opt into increased motion */
  @media screen and (prefers-reduced-motion: no-preference) {
    body {
      --anim-duration: .25s;
    }
  }
}

These preference queries, along with container queries, cascade layers, and modern selector and color syntax, make CSS more expressive without overhauling fundamentals. The basics — specificity, the cascade, responsive behavior — still apply, but the tools to manage them are far more capable than they were a few years ago.

Color Systems, Abstracted Further

My approach to color variables hasn't changed much since the Sass days: generic palette names feed into functionally named custom properties. What has changed is how much further I’m willing to abstract when a project calls for it. On larger palettes with many similar hues, pulling in color functions to manipulate values at a finer grain is worth the extra indirection.

/* Color Palette */
--red: #ff0000;
/* etc. */

/* Brand Colors */
--color-primary: var(--red);
/* etc. */

:root {
  /* Primary Color HSL */
  --h: 21deg;
  --s: 100%;
  --l: 50%;
  
  --color-primary: hsl(var(--h) var(--s) var(--l) / 1);
}

.bg-color {
  background: var(--color-primary);
}

.bg-color--secondary {
  --h: 56deg;
  background: hsl(var(--h) var(--s) var(--l) / 1);
}

--primary-color: color(display-p3 1 0.4 0);

/* 👎 */
--primary-color: color(oklch 70% 0.222 41.29);

/* 👍 */
--primary-color: oklch(70% 0.222 41.29);

/* 👎 */
--primary-color: display-p3(1 0.434 0.088);