12 Days of Web

CSS margin-trim and line height units

2024-12-24T00:00:00.000Z

It’s been possible to create gorgeous layouts on the web for decades, but often, refining the details to perfection can take a lot of effort. Arguably too much effort, and developers just don’t have the time.

Happily, the last few years of CSS have seen a lot of new tools, sometimes very simple tools, that when used in a smart fashion suddenly make polishing graphic design details incredibly easy. In this article, I’ll show you two such tools.

Line height units

Gaining a new unit that represents the line height might seem like no big deal. Support shipped in every browser in 2023 without much fanfare. But wow, are they powerful.

Basically, 1lh equals the height of one line of text for the current font at the current line height. “LH” stands for Line Height. The accompanying 1rlh unit is the equivalent of one line height at the root, just like how rem is the em at the root. “RLH” stands for Root Line Height.

My favorite thing to do with the lh unit is to set margins on content. Let’s set a new universal margin on paragraphs with the following paragraph rule.

p { margin-block: 1lh; }

You can see the results in the following screenshots. On the left, the margin in the block direction is set to 1em, the default in UA stylesheets since the '90s. On the right it’s changed to 1lh.

Many people with an eye for layout and spacing can immediately see the difference. You might agree that the version on the right just looks more polished. It looks refined. In comparison, the version on the left looks a bit clunky. It looks, well, like everything on the web has looked for decades. Slightly awkward.

Many other people will look at this comparison and think, “I don’t see it” or “What’s the big deal?” Let’s draw a line grid over the text to make the difference clearer. Hopefully, now it’s more obvious that the blank space between paragraphs is equivalent to a line of text when it’s defined in lh units.

Line height units give us a direct way to tie any size in our layout to the vertical rhythm of the text. Margins are just one possibility — padding is another, as well as gaps, width, height, or any other measurement in the layout.

Line height units are supported in over 90% of the browsers people use today. For that last 10%, you can use progressive enhancement to ensure they get a good experience.

article {
    padding: 1em; /* fallback for browsers lh without support */
    padding: 1lh;
}

Using this technique causes browsers without support to render 1em of padding, while the browsers with support render 1lh of padding.

Margin trim

Now let’s look at the second seemingly-unimportant-but-actually-powerful tool that’s come to CSS — margin-trim.

Imagine multiple paragraphs inside an article element styled as such.

article {
    padding: 2lh;
    font-size: 1.2rem;
    line-height: 1.3;

    p {
        margin-block: 1lh;
    }
}

By using lh for the margins between the paragraphs and the padding on the article box, we’re attempting to create a beautiful typographic layout. But what’s happening with all the extra space above and below the text?

Let’s turn on some guides to see better what’s happening. The padding on the article box is seen here in yellow, while the paragraph margins are marked in green.

Turns out, the margins on the first and last paragraphs (1lh) are being added to the padding (2lh) to create a space that measures 3lh. This feels like too much space.

It will be better for the design if we get rid of the margin above the first paragraph and the margin below the last paragraph. The new margin-trim property gives us an easy way to do so. It provides a mechanism to tell the box, in this case the article, to eliminate any margins that are butting up against that box.

For example:

article {
    /* Added: */
    margin-trim: block;

    font-size: 1.2rem;
    line-height: 1.3;
    padding: 2lh;

    p {
        margin-block: 1lh;
    }
}

Now, the browser automatically chops off any margins that touch the edge of the article box in the block direction — in this case, the top and bottom of the box.

While the margins are defined on the <p> element, you declare margin-trim on the <article> element. Here’s the result. It looks pretty great.

Support for margin-trim shipped almost two years ago in Safari 16.4. So far, Safari is the only browser with support. But you can start using it today with progressive enhancement techniques.

What should you do for browsers without support? For our demo, you could write fallback code inside of feature queries, like this:

article {
    margin-trim: block;
    font-size: 1.2rem;
    line-height: 1.3;
    padding: 2lh;

    p {
        margin-block: 1lh;
    }
}

@support not (margin-trim: block) {
    article {
        :first-child {
            margin-block-start: 0;
        }

        :last-child {
            margin-block-end: 0;
        }
    }
}

When using :first-child and :last-child, any element that’s the first or last direct child of the container will have its margins trimmed. But any content that either isn’t wrapped in an element or that is nested further deep will not.

For example, if the first element is a figure with a top margin, and the figure contains an image that also has a top margin, both of those margins will be trimmed by margin-trim, while only the figure margin will be trimmed by :first-child.

<article>
    <figure style="margin-top: 1em">
        <img  style="margin-top: 1em" src="photo.jxl" alt="[alt]">
        <figcaption>[caption]</figcaption>
    </figure>
</article>

The margin-trim property makes trimming such margins easier and more robust than older techniques.

You can, of course, also trim margins that bump up against a box in the inline direction. These are all valid options:

margin-trim: none
margin-trim: block
margin-trim: inline
margin-trim: block-start
margin-trim: block-end
margin-trim: inline-start
margin-trim: inline-end

If you want to trim in both directions at the same time, you can do so by combining long-hand values. For example:

margin-trim: block-start block-end inline-start inline-end

More recently, the CSSWG resolved to allow the shorter block and inline keywords in combination, allowing for syntax like this:

margin-trim: block inline

Safari still needs to update our implementation to support this last option. Follow this issue for updates.

Try it yourself

You can try out combinations of options to see the effects of both lh and margin-trim: block by interacting with this demo.

See the CodePen.

Take your typography to the next level

It really is a great time for typography on the web. Over a dozen small features that shipped in the last few years empower web designers and developers to polish typographic details to a far better result, especially with the kind of easy robustness that makes it practical to accomplish. It’s my hope you use them!

Let me know what you think on Bluesky or Mastodon. I’d love to hear your stories, plans, and questions.

Jen selected MEAction for an honorary donation of $50

MEAction or "Myalgic Encephalomyelitis Action Network" is a patient-led advocacy org for post-viral illness & disability like Long Covid.

How to Use Baseline Data

2024-12-23T00:00:00.000Z

I’m one of the leads of the Baseline initiative that was started by a team at Google Chrome and is now defined by the Web DX Community Group. The idea behind Baseline is to make it easier for developers to understand what’s available to use across browsers in a web platform that is changing at a faster rate than ever before. In this post, I will answer the question I’m most often asked, “why doesn’t Baseline consider polyfills or progressive enhancement?” but also demonstrate how Baseline can make the decisions about using polyfills and progressive enhancement much easier.

Why not include polyfills in Baseline?

A small group within Chrome thought about the idea that became Baseline for almost two years before an announcement was made. We spent a lot of time looking at research and what developers were actually doing and telling us. We tried to work out the best way to solve this constant issue of it being hard to understand when things on the platform were ready to use.

Initially, we considered a path that included polyfills. We thought it might be possible to have a less conservative version of Baseline that also included things with a solid polyfill. What became quickly apparent, however, was that very few features can be completely polyfilled so that you can just drop in the polyfill and use the feature as specified.

Take container queries, for example. It’s possible to write a polyfill for container queries, and in some cases, it will work without causing huge performance issues. You would be likely to hit problems, however, if it were used without careful consideration.

In addition, polyfills often only cover part of a feature, so to use them, you need to understand what is available. In almost all cases, the answer to the question of whether a polyfill was a good idea for a feature was “it depends.”

The aim of Baseline is to have a clear and objective line for support, so we didn’t pursue the idea of a line that included polyfills. That doesn’t mean we don’t think you should use them, but that the decision needs to be made with an understanding of your project, use case, and audience.

Why not include things that are easy progressive enhancements?

Several features are currently newly available that are very straightforward progressive enhancements, for example, text-wrap: balance. This is the sort of feature where if it isn’t available, nothing bad happens, but those users with the feature get a slightly better experience.

There are other features – subgrid, for example – that you could allow to fallback to a regular nested grid, thus losing some alignment but leaving things readable for everyone.

The problem with progressive enhancement is that the appetite different people and teams have for it varies. I’ve been telling people for well over twenty years that websites do not need to look the same in all browsers. There are many developers (or their bosses or clients) who very much disagree, even as we approach 2025. This means that any decision around what makes or does not make for good progressive enhancement is entirely subjective. As with polyfills, it also depends on where and how the feature is used.

Both polyfills and progressive enhancement involve decisions we can’t make with availability data.

This discrepancy means I might think it’s absolutely fine to use some feature even if it means some people don’t benefit, whereas your project requirements would mean it can’t be used.

Baseline reduces the number of features you need to make a decision about

Polyfills and progressive enhancement of newly available or limited availability features are probably best left to individual teams to make decisions on. Baseline, however, can still help you here.

For Baseline to work, we first had to understand the web platform as a set of features and then work out the status of those features. This feature grouping work has given us, for the first time, a view of the interoperability of the entire platform. This means we can see how many features are currently Baseline Newly available. At the time of writing, there were 139 features.

If you’ve decided to adopt Baseline Widely available as the point at which you’ll use features, you can feel free to use those features. You can then decide on a case-by-case basis whether to use Newly available features, and because you know exactly which features these are, it’s much easier to do that.

For example, you might want to use the new small, large, and dynamic viewport units. You can see that they've been Baseline Newly available since the end of December 2022. If you are just starting work on a brand new project next year, which you don’t intend to ship until the middle of the year, this feature will be widely available by then. This may give you confidence to use it.

Perhaps you’ll consider container queries, which won’t be Baseline Widely available until August 2025, but feel happy to take the approach explained by Philip Walton in How to use container queries now to offer support to those users with a browser that hasn’t caught up yet. Or you’ll cheerfully use text-wrap: balance, which won’t be Baseline Widely available until November 2026, acknowledging that it’s just a nice enhancement for those who have it.

What Baseline Newly available gives you is a defined group of features that you know you can use with a little extra care. You know they are interoperable, so they aren’t likely to change. You know that the vast majority of your audience will, in most cases, already have them. You know that as time passes, more of your audience gets the enhanced experience they bring. Importantly, you have a clear date when you can expect the feature to be available pretty much everywhere.

Finding the Widely available date

On the Web Platform Status dashboard, click the columns button and select Show Baseline status high date and Show Baseline status low date. The Baseline low date is when the feature becomes Newly available, and the Baseline High date is Widely available.

Customizing the columns shown on the Web Platform Status dashboard.

The future of Baseline

Creating the web features data set has been a huge project. As I write this, however, that work is over 80% complete, and the data is available in the npm web-features package.

I believe this dataset will open up so many possibilities for incorporating Baseline into our work. It should allow tooling to be created that helps you know which features you need to consider more carefully. If you could see the Baseline status of any feature in your editor, then you know when you need to make decisions about polyfills or fallback code. I think it would be useful to have a way of identifying things that have become Widely available since being used in a project, to make it easy to remove polyfills that were no longer useful.

We’re already starting to see the first experiments along these lines. For example, the bl2bl project turns Baseline thresholds into browserslist configurations. There are so many possibilities, and I’m excited to see what we and the community can create.

Rachel selected Feline Fine Foundation for an honorary donation of $50

This local charity helps keep cats and their owners together by providing crisis fostering when an owner is made homeless, goes into hospital, or escapes domestic abuse.

BroadcastChannel API

2024-12-22T00:00:00.000Z

State syncing can be tricky to accomplish with web apps, but it's one of the scenarios improved by using the BroadcastChannel API.

This native web API allows messaging between browsing contexts from the same origin. In other words, if a user has multiple tabs, windows, and even an iframe open from santas-list.tld, use of this API can push messages between all of those contexts. How you handle those messages enables state syncing or other actions.

Sending and Receiving Broadcast Messages

We're going to create a simple app for Santa and his elves to track children's naughty or nice status.

The first step is to set up a broadcast channel. You can name this whatever fits the purpose of your app, and depending on your needs, you can have one channel or multiple.

const santasList = new BroadcastChannel("santasList");

Next, we can send our first message using the API's postMessage method. The content can be a string, as shown, or another data type, like an array or object.

santasList.postMessage("Hello World");

We can receive and then respond to the message by adding an event listener to the broadcast channel we set up, listening to the message event. Any information contained in the message is available in the data property.

santasList.addEventListener("message", ({ data }) => {
  console.log(data);
});

We'll wrap that up in a simple button to test it out. You can do this by opening this article again in a new tab. Then, try pressing the button in one tab and then returning to the other tab to see the message output.

Hello World test message

const santasList = new BroadcastChannel("santasList");

document.getElementById('hello-world').addEventListener('click', () => {
  santasList.postMessage("Hello World");
});

santasList.addEventListener('message', ({ data }) => {
  const messageBox = document.getElementById('hello-world-message');
  
  messageBox.textContent = data;
});

A couple of things to note:

The message will only be output in the non-broadcasting tab (or window)
The message will only sync to currently open contexts, so it will not appear if you open an additional tab (or window)
The broadcast channel is for real-time messaging and will not persist any data

Demo App: Santa's List

For our example, a list of names is presented with options for a "Nice" or "Naughty" behavior. To enable Santa and the elves to check the list twice, we must keep the behavior state in sync across browsing contexts.

In other words, if Priscilla's behavior is updated from "Nice" to "Naughty," we want that immediately reflected in any other open tabs to prevent duplicate updates and stale data.

The demo uses all the same methods we've reviewed. However, the logic is extended to update the button state instead of outputting the message.

This app—even as simple as it is—shows just how flexible the API is since you can send data in any shape, and it's entirely up to your application what you do with that data.

You'll see a little extra fluff in the CodePen because I chose to create a web component for managing each list item to isolate sending and receiving messages per item.

The basic logic is that once either behavior is selected for a list item, its aria-pressed state is toggled. The alternate button is also toggled to the opposite state since the behaviors are mutually exclusive binary choices.

Coupled with the name data and the id ('nice' or 'naughty') of the pressed button, the following message is broadcast.

santasList.postMessage({
  name,
  id,
  pressed // updated aria-pressed state
});

A custom event is used to pass the data from the message event listener. This enables a single message event listener rather than instantiating one per custom element. In the future, we might have additional actions we want to take upon a received message.

const updateListEvent = (detail) =>
  document.dispatchEvent(new CustomEvent("update-list", { detail }));

santasList.addEventListener("message", ({ data }) => {
  const { name, id, pressed } = data;
  updateListEvent({ name, id, pressed });
});

The list item listens for the custom event and checks if its name data matches, and if so, hands off the data to update the corresponding button state for itself.

document.addEventListener("update-list", ({ detail }) => {
  if (detail.name !== name) return;

  // `handleListUpdate` updates button state from 
  // both in-page button presses and broadcasts
  handleListUpdate(detail.id, detail.pressed);
});

Here's the CodePen putting it together. Again, to see it in action, duplicate this tab to see the state reflected in both.

See the CodePen.

Note that since there's no actual data service behind this simple example, and remembering that the BroadcastChannel in and of itself does not persist data, changes made before opening a new tab will not be reflected. This means that, ultimately, you are likely to need some sort of database or storage solution if data changes need to be saved.

Other Opportunities for Use

Here are a few ways to use the BroadcastChannel API.

Syncing of all kinds of states, including:

logged in status
notifications (read, unread, new)
file or progress saving
form and uploaded data
chat messages
profile details
store cart changes

You can also use it to take more advanced and involved actions. I became familiar with the API by using it for my custom conference presentation framework (example presentation). I used it to navigate slides from a "notes" view via key presses. I also used messages to trigger custom events to mimic element states like hover and focus, reflect typed text updates, and resize code vs. result panels.

Resources

Check out the following to learn more about the BroadcastChannel API.

Broadcast Channel API overview on MDN
Overview from the Chrome blog, which also reviews differences from other available messaging APIs
Tutorial with additional examples for use from Christian Nwamba

Stephanie selected The Trevor Project for an honorary donation of $50

The Trevor Project’s mission is to end suicide among LGBTQ young people.

CSS light-dark()

2024-12-21T00:00:00.000Z

light-dark() makes it easy to build websites that respect the user's preferred color scheme while also providing the ability to override the color scheme without code duplication. Be sure to check out the demo at the bottom!

Before we dive into light-dark(), let's take a quick detour to understand color-scheme.

Color scheme

Browsers have a built-in "color scheme" mechanism, which can be specified using the color-scheme CSS property or the corresponding meta tag.

The color-scheme can be set to either "light" or "dark" to indicate which mode the page supports. It can also be set to a space-separated "light dark" value, which indicates that the page supports both modes.

Typically, you would set this on the html element so that it gets inherited by everything on the page.

html { 
  color-scheme: light dark; 
}

This is kinda like saying, "Hey browser, this page supports both light and dark modes, so go look at the user's preferences and decide which mode to actually use."

The browser then uses the resolved color scheme value to determine the default colors for things like the page background, text color, scrollbars, form controls, and system colors.

It's worth clarifying at this point that color-scheme is a completely separate concept from the prefers-color-scheme media query, which you might have used in the past to implement a dark mode. The media query is only concerned with looking at the user preferences. Even if you're using the media query, it should be paired with the color-scheme property so that scrollbars and form controls get more appropriate default styles.

@media (prefers-color-scheme: dark) {
  html {
    color-scheme: dark;
  }
}

Everything we've learned about color-scheme thus far has been widely available across browsers for many years now.

Now that we understand color-scheme, we can look at the new light dark() feature!

Enter light-dark()

You might have noticed that, up until now, color-scheme is somewhat of a one-way signal. Browsers can use color-scheme to adjust the default colors (and system colors), but authors cannot use it in their own code to adjust their custom styles.

This is where light-dark() comes in. From the spec:

System colors have the ability to react to the current used color scheme value. The light-dark() function exposes the same capability to authors.

light-dark() is a CSS function that accepts two color values and returns one of them based on the used color-scheme. The following snippet will make all links be DeepPink in light mode and HotPink in dark mode.

:any-link {
  color: light-dark(DeepPink, HotPink);
}

It's a clean and concise way of doing something that would have required multiple CSS rules and media queries in the past.

The two colors don't need to be hardcoded; they can reference custom properties (aka "CSS variables"). And they can also be referenced by other custom properties (as we'll see later).

:any-link {
  color: light-dark(var(--accent-light), var(--accent-dark));
}

light-dark() has been newly available across modern browsers since early 2024. For older browsers, we can transpile our code using LightningCSS or a PostCSS plugin.

Themed variables using light-dark()

To get the most out of light-dark(), it is best used globally for the purpose of setting up themed custom properties.

Let's start by defining three custom properties: --accent, --bg, and --fg.

html {
  --accent: light-dark(DeepPink, HotPink);
  --bg: light-dark(White, Black);
  --fg: light-dark(Black, White);
}

Don't pay mind to the actual values in this example. It's probably not desirable to use the built-in named CSS colors. Usually, you'll want to agonize over picking the right colors. I'll leave that as an exercise for the reader. (If you need a little push, Open Props provides a few different color scales which can be a good starting point for your color system.)

Once the custom properties are set up, we can use them everywhere in our CSS. Notice how we don't need to repeat the raw color values. Because these custom properties were set up using light-dark(), the whole page automatically works in both light and dark modes without needing to adjust anything at the component level.

html {
  accent-color: var(--accent);
  background-color: var(--bg);
  color: var(--fg);
}
*:focus-visible {
  outline: 2px solid var(--accent);
}
:any-link {
  color: var(--fg);
}
button {
  color: var(--fg);
  border: 1px solid var(--fg);
}
.surface {
  background-color: var(--bg);
}
/* and so on... */

Overriding color-scheme

So far, we've only seen how light-dark() can replace a media query. This is great, but we usually want more: the site should respect the user's preference by default, but the user should also be able to override the default color scheme.

The key insight here is that light-dark() is tied to the color-scheme, rather than to user preference. While setting color-scheme: light dark will match the user preference, we can also override it manually.

Let's say our website has a theme toggle, which sets a data-color-scheme attribute on the <html> element.

/*
 * Call this function from your theme toggle.
 * @example
 * setColorScheme("light");
 * setColorScheme("dark");
 */

function setColorScheme(mode) {
  document.documentElement.dataset.colorScheme = mode;
}

Now, we can use this data attribute as a CSS selector to change our color-scheme.

html {
  color-scheme: light dark;
  
  &[data-color-scheme="light"] {
    color-scheme: light;
  }
  
  &[data-color-scheme="dark"] {
    color-scheme: dark;
  }
}

Changing the color-scheme will automatically result in all instances of light-dark() returning the appropriate color value. In this instance, we are setting color-scheme on the same element (<html>) where our custom properties are defined. However, light-dark() also works for descendant elements because color-scheme is an inherited property.

That's really all the code we need to implement light and dark modes. It respects the user preference (without a media query!) and can also be overridden.

For comparison, implementing the same functionality without light-dark() would look something like the following. We would need to define the custom properties four different times, two of which are entirely duplicate copies of each other.

/* without light-dark() */
html {
  color-scheme: light dark;
  
  @media (prefers-color-scheme: light) {
    --accent: DeepPink;
    --bg: White;
    --fg: Black;
  }
    
  @media (prefers-color-scheme: dark) {
    --accent: HotPink;
    --bg: Black;
    --fg: White;
  }
}
    
html {
  &[data-color-scheme="light"] {
    color-scheme: light;
    
    --accent: DeepPink;
    --bg: White;
    --fg: Black;
  }
  
  &[data-color-scheme="dark"] {
    color-scheme: dark;
    
    --accent: HotPink;
    --bg: Black;
    --fg: White;
  }
}

Meanwhile, with light-dark(), we can keep all our custom properties neatly defined in a single place.

/* with light-dark() */
html {
  --accent: light-dark(DeepPink, HotPink);
  --bg: light-dark(White, Black);
  --fg: light-dark(Black, White);
}

The future is bright (and dark)!

To the CodePen!

Let's take everything we've learned about light-dark() and put it to use.

This demo shows a tri-state toggle that works only by changing the document's color-scheme. All of the theme-related CSS is wrapped under @layer theme.

See the CodePen.

JS Import Maps

2024-12-20T00:00:00.000Z

Introduction

Just as holiday shopping requires careful planning and organization, managing JavaScript dependencies in web applications demands thoughtful coordination. Traditionally, web developers have relied on bundlers like webpack or browserify to handle bare module imports.

But what if we could easily manage our dependencies? Enter Import Maps, a native browser specification that lets you control JavaScript module loading without the need for bundling tools.

Understanding Import Maps

The Problem with Bare Imports

When we write modern JavaScript, we often use bare import statements like:

import { Snowflake } from "winter-animations";

Without build tools, browsers can't resolve these bare module specifiers - they need complete URLs. It's like trying to deliver presents without knowing the full address!

How Import Maps Help

Import Maps tell browsers exactly where to find these modules, mapping bare import names to their actual locations. Think of them as your holiday shipping manifest—a clear guide showing where each package needs to go.

Example Usage

Let's create an example using Import Maps to build a winter-themed countdown timer.

First, create your index.html:

<!-- Define our Import Map -->
<script type="importmap">
  {
    "imports": {
      "date-fns": "https://cdn.skypack.dev/date-fns",
      "snowfall-effect": "https://cdn.skypack.dev/snowfall-effect"
    }
  }
</script>

<script type="module" src="./winter.js"></script>

<div id="countdown"></div>

Then create a file called winter.js:

import { differenceInDays } from "date-fns";
import { createSnowfall } from "snowfall-effect";

// Create countdown to winter solstice
const winterSolstice = new Date(2024, 11, 21);
const countdown = document.getElementById("countdown");

function updateCountdown() {
    const daysLeft = differenceInDays(winterSolstice, new Date());
    countdown.textContent = `${daysLeft} days until Winter Solstice!`;
}

// Update daily
updateCountdown();
setInterval(updateCountdown, 86400000);

// Add some winter magic
createSnowfall({
    density: 50,
    speed: 1.5
});

Advanced Features

Scoped Imports

Like organizing different gifts for different family members, Import Maps allow you to specify different versions of the same package for different parts of your application.

{
  "imports": {
    "animation-lib": "/shared/animation-v2.js"
  },
  "scopes": {
    "/legacy/": {
      "animation-lib": "/shared/animation-v1.js"
    }
  }
}

Version Management

Need to maintain different versions for different features? Import Maps let you handle this elegantly:

{
  "imports": {
    "snowfall-effect": "/modules/snowfall-v2.js",
    "snowfall-effect-legacy": "/modules/snowfall-v1.js"
  }
}

Browser Support and Fallbacks

As of late 2024, Import Maps are supported in all modern browsers. However, for broader compatibility, you can use the ES Module Shims polyfill:

<script async src="https://ga.jspm.io/npm:es-module-shims@1.7.0/dist/es-module-shims.js"></script>

VS Code Extension

Alternatively, there is a VS Code extension which can automatically generate and inject import maps for modules and HTML pages. You can learn more about this extension here.

Project Ideas

Here are some projects you can build over the holidays to help you master Import Maps:

1. Winter Task Tracker with Snowfall Effects

Build a task management system where completed tasks trigger animated snowflakes. Use these libraries.

<script type="importmap">
{
  "imports": {
    "tsparticles": "https://cdn.skypack.dev/tsparticles",
    "sortablejs": "https://cdn.skypack.dev/sortablejs",
    "date-fns": "https://cdn.skypack.dev/date-fns",
    "@lit/reactive-element": "https://cdn.skypack.dev/@lit/reactive-element"
  }
}
</script>

Key Features to Implement:

Use tsparticles for snowflake animations when tasks are completed
Implement drag-and-drop task reordering with sortablejs
Add due date handling with date-fns
Create custom task components with @lit/reactive-element

2. Holiday Gift List Organizer

Create a gift tracking application with categories, budgeting, and progress tracking.

<script type="importmap">
{
  "imports": {
    "alpine": "https://cdn.skypack.dev/alpinejs",
    "currency.js": "https://cdn.skypack.dev/currency.js",
    "chart.js": "https://cdn.skypack.dev/chart.js",
    "uuid": "https://cdn.skypack.dev/uuid"
  }
}
</script>

Key Features to Implement:

Use alpine for reactive UI components
Handle gift budget calculations with currency.js
Create spending visualizations with chart.js
Generate unique IDs for gifts using uuid

3. Winter Weather Dashboard

Build a weather dashboard that pulls data from multiple sources and displays it with winter-themed visualizations.

<script type="importmap">
{
  "imports": {
    "d3": "https://cdn.skypack.dev/d3",
    "axios": "https://cdn.skypack.dev/axios",
    "dayjs": "https://cdn.skypack.dev/dayjs",
    "weather-icons": "https://cdn.skypack.dev/weather-icons"
  },
  "scopes": {
    "/weather/": {
      "temp-conversion": "./utils/temperature.js",
      "weather-api": "./services/weather-service.js"
    }
  }
}
</script>

Key Features to Implement:

Create weather visualizations with d3
Handle API requests with axios
Manage dates and times with dayjs
Display weather conditions using weather-icons

Additional Resources

Import Maps Specification: https://github.com/WICG/import-maps
MDN Documentation: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap
ES Module Shims: https://github.com/guybedford/es-module-shims

Conclusion

Import Maps provide a powerful way to manage JavaScript dependencies directly in the browser. By eliminating the need for bundlers in many cases, they simplify development workflows and provide more direct control over module loading.

Thanks for reading. I hope this article has been helpful in getting you started with import maps. Happy holidays! Cheers!

Victoria selected Girls Who Code for an honorary donation of $50

Girls Who Code is an organization working to close the gender gap in technology by inspiring, educating, and equipping young women with the computing skills needed to pursue modern opportunities. They offer coding clubs, summer programs, and college/career prep.

CSS box-decoration-break

2024-12-19T00:00:00.000Z

box-decoration-break is a CSS property that lets you decide what the decorations of a box should do if that box is broken across multiple lines.

Now that sentence probably means nothing if you don't already know what box-decoration-break does, so let's back up a whole bunch of steps and figure out why this is something that needs to be decided on.

What is a box?

Let's start with the first part: boxes. In CSS, everything is a box. Every element in your DOM is a box, every pseudo-element you add in CSS is a box, and even every text node is a box.

In other words, the entire web page is made up of rectangles. There are different types of rectangles, but for box decoration-break, there are two types we need to know about: block boxes and inline boxes. In CSS, elements can either be "block" or "inline."

Example of a block element

.block-el {
  text-align: center;
  aspect-ratio: 1/1;
  max-block-size: 200px;
  display: grid;
  place-items: center;
  border: 4px solid dodgerblue;
  padding: 40px
}

This is a block box

When an element is a block element, it takes up the entire width of the parent element, and if you add a new block element after it, that will be placed below the first block element. Things like divs, headings, and paragraphs are block elements: They stack on top of each other.

Inline elements, on the other hand, only take up the space they need and sit "inline" with the surrounding text. Examples include spans, links, and strong elements.

Example of an inline elememt

.inline-el {
  line-height: 2.5;
  text-align: center;
}

.inline-el span {
  border: 4px solid dodgerblue;
  padding: 4px 10px
}

Hello, this is a long unbroken inline box in a text line.

What are decorations?

In CSS, (box-)decorations are things like borders, outlines, backgrounds, and shadows (but also margin, padding, and clip-path). They let you change the box from a transparent rectangle into a nicely glowing pill button, a floating card, or a recessed input field.

Usually, these decorations are applied to all sides of the box: top, right, bottom, and left, though you can also apply borders and outlines only to specific sides.

Simple decorated box

.decorated {
  font-size: 1.5rem;
  font-weight: bold;
  color: white;
  outline: 5px dashed red;
  border: 5px dashed green;
  padding: 20px;
  aspect-ratio: initial;
  background: repeating-linear-gradient(45deg,  red,  red 10px,  green 10px,  green 20px);
  border-radius: 999px;
  box-shadow: 0 0 20px yellow, 0 0 10px 5px inset yellow;
}

This is a decorated box

What’s a break?

Most inline elements are short and fit start-to-end in a single line. If an inline element is very long, it will automatically wrap across multiple lines.

To do that, the browser first renders the inline element as a very wide rectangle that includes all the contents in a single line. Then, it will break that rectangle up into however many lines it needs to make the content fit the screen.

This breaking is where things might not happen as you expect. Let’s say you have an inline box with a blue border on all sides: top, right, bottom, and left. Those borders are exactly where you think they are when the browser first renders that very long inline element.

Initial box styles

.initial-box {
  border:4px solid dodgerblue;
  padding: 4px 10px;
}

This is a long unbroken inline box

But then the browser chops it up into multiple segments, and while the element still has the border at the left and right sides, there’s now a bunch of new left and right sides to this element, and they look awful.

Broken appearance box styles

.broken-box {
 width: 100px;
}

.broken-box span {
  border:4px solid dodgerblue;
  padding: 4px 10px;
}

This is a long unbroken inline box

Enter box-decoration-break

With box-decoration-break, we can tell the browser how to handle those breaks in one of two ways:

Slice

This is the default value, and it’s like the example above. The browser renders the inline element in one long line and then chops that line up into multiple segments, leading to “frayed” edges on either side for everything but the first and last lines.

Clone

Setting box-decoration-break to clone will take those decorations and clone them to each segment, meaning that each line is turned into its own little box.

Using box-decoration-break: clone

.box-decoration-break-clone {
 width: 100px;
}

.box-decoration-break-clone span {
  border:4px solid dodgerblue;
  padding: 4px 10px;
  
  box-decoration-break: clone;
}

This is a long broken inline box

Not only does this cause the borders you might have expected to appear again, also see how the padding on the left and right sides are now also applied to each line, rather than only to the beginning and end.

A practical application of this is when you want to create a marker-like effect on some text to make it seem like you have highlighted a couple of lines.

Here’s that effect without cloned box-decoration-break.

Marker effect - no box-decoration-break

.marker-1 {
  width: 250px;
  line-height: 1.5;
  font-size: 1.75rem;
}

.marker-1 span {
  padding-inline: 20px;
  background: linear-gradient(105deg, transparent 10px, cyan 10px, cyan calc(100% - 10px), transparent calc(100% - 10px));
}

This is a long broken inline box

And here it is with cloned box-decoration-break.

Marker effect - with box-decoration-break

.marker-2 {
  width: 250px;
  line-height: 1.5;
  font-size: 1.75rem;
}

.marker-2 span {
  padding-inline: 20px;
  background: linear-gradient(105deg, transparent 10px, cyan 10px, cyan calc(100% - 10px), transparent calc(100% - 10px));

  box-decoration-break: clone;
}

This is a long broken inline box

The re-introduction

As I said at the start of this article, you might have already used this feature! It’s been available in Firefox since 2014, Chromium-based browsers since 2013, and Safari since 2013.

The Chromium and Safari implementations, however, had the -webkit- prefix because they only had partial support. It only supported the box-decoration-break of inline boxes. Inline boxes are where you encounter this issue most frequently so there is a high chance that you’ve already used this at some point in the last decade.

But there are cases where block boxes can also get broken apart: in (infrequently used) multi-column layout. Chrome implemented support for that earlier this year and thus removed the prefix, while Safari has no support for that yet and still has the prefix.

To support both browsers, always first write the prefixed version:

-webkit-box-decoration-break: clone;
box-decoration-break: clone;

We do this because in CSS, the last declaration wins. When that last declaration is the unprefixed one, as soon as Safari also adds support, it will default to using the proper, full implementation. Until that time, Safari doesn’t understand box-decoration-break and will ignore it, using only the prefixed version.

Block-level box-decoration-break for multi-column layout.

In the same way that inline boxes can get split up across multiple horizontal lines if they don’t fit horizontally, block boxes can get split up across multiple columns if they don’t fit in a single column vertically, like the following demo adapted from MDN:

Multi-column and box-decoration-break

/* our block style */
.multi-col span {
  display: block;
  font-size:1.5rem;
  font-weight:bold;
  color: white;
  outline: 5px dashed red;
  border: 5px dashed green;
  padding: 20px;
  aspect-ratio: initial;
  background: repeating-linear-gradient(45deg,  red,  red 10px,  green 10px,  green 20px);
  border-radius: 999px;
  box-shadow: 0 0 20px yellow, 0 0 10px 5px inset yellow;
}

.base {
  width: 33%;
}

.columns {
  columns: 3;
}

.default {
  box-decoration-break: slice;
}

.clone {
  box-decoration-break: clone;
}

The quick orange fox

'box-decoration-break: slice'

The quick orange fox

'box-decoration-break: clone'

The quick orange fox

That’s box-decoration-break

When an element is broken across multiple lines (or columns), box-decoration-break enables you to decide whether each segment should clone the decorations for themselves or if the box should remain sliced.

It’s fully available in Chromium-based browsers and Firefox. In Safari you can use it for inline boxes with the -webkit- prefix. If you want to learn more, here are some additional resources:

Kilian selected Giving Green Fund for an honorary donation of $50

The climate crisis sits at the heart of many problems around the world, increasing inequality and disproportionately affecting those least responsible for it. If we want to keep earth livable for our children, we need to fight it at many fronts. Giving Green is a fund that research projects and funds those most effective.

Declarative Shadow DOM

2024-12-18T00:00:00.000Z

What we are able to build using the web platform has gone into overdrive, especially in the last two years. Most of the action has been in the areas of CSS and JavaScript, but there have also been some important additions to HTML.

However, one piece of the puzzle has proven to be elusive: the ability to build reusable and isolated components.

But wait, what about web components? I hear you ask, and you would be correct. With the HTML template element, custom elements, and the shadow DOM finally getting widespread adoption in user agents, we can build components that satisfy most of our needs.

The Problem

Leaving the complaints about the general developer experience when writing web components aside for the moment, there is one rather striking challenge that still has most web developers reaching for a framework: server-side rendering and/or static site generation.

There are multiple reasons we may want to take advantage of server-side rendering. Some of these are related to performance and accessibility, but also to search engine optimization, which is still an important topic in 2024, even though Perplexity and friends might want us to believe differently.

I would much prefer to know that users can access a page's content even if JavaScript fails to execute for whatever reason. Also, some applications (both desktop and web-based) do not execute JavaScript and instead opt to provide the user with a clean and distraction-free reading environment.

In these instances, web components will let you and your users down.

But…

The web and the technologies that power it are constantly evolving, and so too have web components. In this article, I will first highlight the challenge that has made using web components, specifically the shadow DOM, a non-starter for many projects. But then, we will explore an evolution of shadow DOM that is already well-supported in modern browsers, known as declarative shadow DOM, and learn how it breaks down one of the final obstacles and enables us to write reusable, isolated web components that can be server-side rendered or used as part of a statically generated website.

The Problem with Shadow DOM

To understand some of the challenges with shadow DOM and why you would want to use It, we will build a simple user card component. We do have a couple of requirements that need to be met when building and using this component.

Above is an example use case for the card component we will be building.

Our Requirements

We want clean, semantic, and accessible HTML.
We want our CSS to be scoped to our card component but, we do not want to have to write our CSS in JavaScript and would prefer to have our component CSS in its own CSS source file.
The data for each card will come from an external API so we need a way to load this data.
We want to be able to access our card components with their data available, even if JavaScript is not available.
We want to be able to use our component during server-side rendering, as part of a statically generated site, or even in more traditional server based frameworks such as those mentioned in the note earlier in this article.
We would very much appreciate a great developer experience that allows for ease of implementation and maintainability.

That is quite a set of requirements, but they are not uncommon when building software and websites for the web.

The HTML

Let us start by satisfying our first requirement: we want clean, semantic, and accessible HTML.

<nimbus-team></nimbus-team>

<template id="nimbus-team-user-card-tmpl">
  <li>
    <article class="user-card">
      <h2 class="user-card-title"></h2>

      <img class="user-card-avatar" src="" height="150" width="150" alt="" />

      <span class="user-card-role"></span>
      <span class="user-card-email">
        <span class="visually-hidden">Email:</span>
        <a href=""></a>
      </span>
      <span class="user-card-phone">
        <span class="visually-hidden">Phone:</span>
        <a href=""></a>
      </span>

      <ul class="user-card-social">
          <li>
              <a class="icon icon-social-bsky" href="" target="_blank" rel="noopener noreferrer">
                  <span class="visually-hidden">Follow @employee on @platform</span>
              </a>
          </li>
          <li>
              <a class="icon icon-social-linkedin" href="" target="_blank" rel="noopener noreferrer">
                  <span class="visually-hidden">Follow @employee on @platform</span>
              </a>
          </li>
          <li>
              <a class="icon icon-social-mastodon" href="" target="_blank" rel="noopener noreferrer">
                  <span class="visually-hidden">Follow @employee on @platform</span>
              </a>
          </li>
      </ul>
    </article>
  </li>
</template>

That is a lot of HTML! For the most part, though, you have most likely seen all of it before. The only two items that might be new are the nimbus-team element and the template element. The first, nimbus-team is our custom element that does not really exist yet. The second is the template element we are using to well house our user card template.

There are some optimizations we can make to this template when we use it within a framework such as Astro, but for the moment, we will focus more on the more “traditional” way you would build this type of web component even when not inside a framework such as Astro. We will take full advantage of it later when we refactor this to use declarative shadow DOM.

If you open the HTML document in your browser right now, you will be presented with a blank page. This is because our custom element has not been defined and registered yet, and the content of a template element is not visible when viewed in a browser.

The initial custom element JavaScript

To address the first part, we need to add some JavaScript. In a folder called js, at the root of your project, create a new .js file called nimbus-team.js. Add the following to this file:

class NimbusTeam extends HTMLElement {
  static #selectors = {
    UserCardTmpl: "nimbus-team-user-card-tmpl",
  };

  #shadow;

  constructor() {
    super();
    this.#shadow = this.attachShadow({ mode: "open" });
  }

  connectedCallback() {
    const template = document.getElementById(
      NimbusTeam.#selectors.UserCardTmpl
    );

    if (template) {
      const content = template.content.cloneNode(true);
      this.#shadow.appendChild(content);
    }
  }
}

customElements.define("nimbus-team", NimbusTeam);

Let’s break down what is happening here. We start by defining a class for our component and extending the HTMLElement base class so that we can inherit from it. We set two private JavaScript properties (those marked with #), one of which is marked as static.

Next, we define our constructor, and critically, we call super.

Next, we attach our shadow DOM root to our component and store a reference in our private #shadow property. Custom elements have several life cycle events with associated predefined functions (this will sound very familiar to you if you have been using almost any of the popular frontend JavaScript frameworks).

Here we are using the connectedCallback to insert the templates of our content into the shadow DOM we attached a little earlier. It is important to note that we do not simply get a reference to the template element and insert it into the shadow DOM. What we need to do instead and clone the content of the template and then inject this into the shadow DOM.

Finally we register our custom element using customElements.define. To avoid potential conflicts with native HTML element, custom element must always be hyphenated. The second argument to the function call is a reference to our class.

We need to do one more thing before we start seeing the fruits of our labor in the browser. Back in the HTML document, just before the closing body tag, add the following script element.

<script type="module" src="js/nimbus-team.js"></script>

The CSS

When you reload your browser, you will see our user card. Of course, it is a bit of a mess and completely unstyled right now.

I have provided the social media icon SVG files and the CSS, which you can find in this GitHub commit.

With the CSS and icons in place, we can link the stylesheet in the head of our HTML document.

<link href="css/user-card.css" rel="stylesheet" type="text/css" media="screen">

If you had reloaded the HTML page at this stage, absolutely nothing would have changed. But why? This result is because the shadow DOM is doing exactly what it is supposed to and what we want based on our second requirement.

We want our CSS to be scoped to our card component but, we do not want to have to write our CSS in JavaScript and would prefer to have our component CSS in its own CSS source file.

The shadow DOM is encapsulated, and we cannot pierce it from the outside (see the note below). As such, the CSS has no effect. There are several ways to get our CSS to be part of the shadow DOM, but in this article, we will load and apply it using fetch.

Fetching the CSS

Because we will fetch and apply our CSS using JavaScript, we can remove the link element from the HTML, as it will not be needed. We will add the following function to our JavaScript to load and apply our CSS.

async #loadCSS() {
  const style = document.createElement("style");
  const response = await fetch("css/user-card.css");

  if (response.ok) {
    style.textContent = await response.text();
    this.#shadow.appendChild(style);
  }
}

The code here is rather simple. We create a style element, load our CSS file using fetch and if it was successful, we get the text from the response and set it as the text content of the style element. Lastly we append the new style tag to our shadow DOM.

There is one more thing: we need to call our new function. We can do this either in the constructor or the connected callback as long as it is called after the shadow DOM root has been attached. I opted for doing so in the constructor.

constructor() {
  super();
  this.#shadow = this.attachShadow({ mode: "open" });
  this.#loadCSS();
}

Reloading the page now will show a still rather broken card, but as you will note, some of our global CSS, notably the custom properties, have pierced the shadow DOM. If you read the linked post from earlier, this will be expected and is actually pretty neat!

We have met our second requirement, but if you look in the developer tools’ elements panel, you will notice that the browser is actually being pretty forgiving. 🙃 Right now, we are injecting a list element without a parent, which breaks our first requirement of clean, semantic, and accessible HTML

Let’s fix this.

Some more DOM manipulation

To fix our HTML, we will add the following to our connectedCallback:

const listContainer = document.createElement("ul");
...

listContainer.classList.add("card-list");
listContainer.appendChild(content);

With this, our DOM is fixed, but we have a problem. The visually-hidden class from our global CSS file is not having any effect (as we would expect). To remedy this, we will unfortunately have to either load the global CSS file (not recommended) or duplicate the class into the CSS file we are already loading.

With this change (view the commit here on GitHub), we are getting close to our final implementation.

Loading the data

To get some fictional data for our card and satisfy out next requirement, we will use a simple Netlify serverless function I spun up called Fictional Folks. We will first add a private Class property called #users and then add a function to load and store our user data in this property.

The data for each card will come from an external API, so we need a way to load it.

#users;

async #loadUsers() {
  const response = await fetch(
    "https://fictionalfolks.netlify.app/.netlify/functions/users?count=1"
  );

  if (response.ok) {
    this.#users = await response.json();
  }
}

With the above we will get one random user each time we reload our page. The code to actually update the user card with the data is quite a lot but there is nothing super interesting so, instead of listing all of it here, please review the commit on GitHub for all of the details (I do quite a bit of refactoring in the commit so, please read over the changes in the commit carefully).

You should now have a successfully rendered user card with all of the relevant data filled in and functional! You can also play around with the API call and see what happens when you load more than a single user.

A fork in the road

We have now reached the point where we will start to hit the limitations of this version of our web component. If we review the remaining requirements, we will quickly see that we cannot satisfy them.

We want to be able to access our card components with their data available, even if JavaScript is not available.
We want to be able to use our component during server-side rendering, as part of a statically generated site, or even in more traditional server based frameworks such as those mentioned in the note earlier in this article.
We would very much appreciate a great developer experience that allows for ease of implementation and maintainability.

On the last item, I will leave it up to you to determine how close or far we are from a great developer experience. While the experience thus far has definitely not been terrible, it has not been stellar either. To be honest, there is quite a bit one can do to optimize some of the code, but we will definitely still be left wanting.

Declarative shadow DOM to the rescue!

Before we dig into this part, I want to make clear that I will primarily share the coding parts that change. I will link to the repository with the full code, but to not stretch out this post, I will refrain from sharing all of the step-by-step details where they are not absolutely required.

Also, for this part I will hard code the data for the user card but, I will also link to an example where I use the same declarative component within the context of an Astro project where the data and construction of the cards will happen at build time.

With those stated caveats, let’s refactor!

The template

We will change two things concerning our template element.

We will move it inside our custom element
Remove the id attribute and instead add the shadowrootmode attribute

<nimbus-team>
  <template shadowrootmode="open">
    <ul class="card-list">
      <li>
        <article class="user-card">
          <h2 class="user-card-title">Marlowe Solace</h2>
          ...

          <ul class="user-card-social">
            <li>
              <a class="icon icon-social-bsky" href="https://bsky.app/profile/marlowe.solace" target="_blank" rel="noopener noreferrer">
                <span class="visually-hidden">Follow MArlowe on Bluesky</span>
              </a>
            </li>
            ...
          </ul>
        </article>
      </li>
    </ul>
  </template>
</nimbus-team>

You can review the full HTML as part of the following commit on GitHub.

If you started a new HTML file for this part of the article, also make sure that you have linked the global CSS in the head as we did in our previous example. Now for the first mind-blown moment. If you open this file in your browser, you will see an unstyled instance of the card.

No JavaScript. What!?

If we link the user-card.css file in the head and reload the page, you will still find that the CSS does not impact the card. What is happening here?

This is the beauty of declarative shadow DOM. The browser is simply ignoring the unknown nimbus-team element and parsing the next line of HTML. The word "parsing" is critical here as this conversion from template to shadow-root happens through the HTML parser which is why we do not need any JavaScript yet and why this can now be part of a server-side rendered or statically generated website or application.

You can see this by inspecting the DOM using the elements panel of the browser developer tools.

Shows the declaratively created shadow-root with the nested card list.

The Shadow and the Custom Element

Something else is also happening, though, as soon as we register our custom element, so let’s do that. Feel free to create a new blank JavaScript file as we will need very little of the previous JavaScript. All that is in my .js file now is the following:

class NimbusTeam extends HTMLElement {
  constructor() {
    super();
  }
}

customElements.define("nimbus-team", NimbusTeam);

Notice that we have not called attachShadow anywhere in the script yet. And we will not need to. Because our static HTML is now being upgraded due to us registering the custom element, the browser has also already exposed the shadow-root to the custom element.

This means adding the following to the code above will indeed return an instance of the shadow-root and not null:

console.log(this.shadowRoot);

It is important to know that calling this.attachShadow inside a custom element that already has a declarative shadow-root attached will not throw an error. Instead, the Declarative Shadow Root will be emptied and returned. So, be careful here, as it literally means what it says. If you call this.attachShadow, everything that was added to the shadow-root during parsing will be removed, and you will need to rebuild the DOM for the shadow DOM. In other words, our entire unordered list and all of its children will be removed.

Although we can check for the existence of our shadowRoot using this.shadowRoot the shadowRoot is now also exposed on ElementInternals. ElementInternals is an entirely other topic, but it essentially means we can do the following:

class NimbusTeam extends HTMLElement {
  constructor() {
    super();
    
    const internals = this.attachInternals();
    let shadow = internals.shadowRoot;
    
    if (!shadow) {
      // we can now safely attach out shadowRoot without worrying
      // that we will blow away any existing shadow DOM elements
			shadow = this.attachShadow({ mode: "open" });
    }
  }
}

customElements.define("nimbus-team", NimbusTeam);

Depending on your use case, you may or may not need to do any of the above. I would say that if you know that the underlying HTML uses declarative shadow DOM, you can assume that a shadowRoot will exist and can proceed. The one use case where you may need to do this is if you need to support browsers that do not yet support declarative shadow DOM.

The folks over at Salesforce did quite a deep dive into polyfilling declarative shadow DOM, but there is also a simplified polyfill available in the Declarative Shadow DOM post on Web.Dev.

If you choose not to go with a polyfill, remember that in instances where declarative shadow Dom is not supported, the original template element will still be present in the DOM and can, therefore, be referenced, cloned, and inserted into the manually created shadow-root (this means you may want to keep the id attribute around for this purpose—choose your own adventure 🙃).

CSS in the Declarative Shadow

You may be a little disappointed here because all we need to do to get our CSS to work and be scoped to our component is to take the link element that is currently in the head and move it into the template element like so:

<nimbus-team>
  <template shadowrootmode="open">
    <link href="css/user-card.css" rel="stylesheet" type="text/css" media="screen">
    ...
  </template>
</nimbus-team>

With this, you can go ahead and reload the page. As before, though, the visually-hidden class is not going to pierce our shadow, and we will need to copy it into our user card CSS file. To further prove to ourselves that our component is isolated and that only CSS we want to pierce the shadow get through and nothing leaks out, add the following to the HTML just before the custom element:

<h2>Marlowe Solace outside the Shadow</h2>

In global.css add the following:

h2 {
  color: hotpink;
}

And inside user-cards.css change .user-card-title to h2:

h2 {
  font-size: var(--typography-font-size-heading);
  margin: 0;
}

When you reload the page, you will see that the outer heading is not affected by the font-size setting inside the user-card and is hotpink. You will also notice that the h2 inside our component is our dark purple color and not hotpink.

Conclusion: Embracing Declarative Shadow DOM

Web components have always promised reusable, isolated, and standards-based solutions for building modern web applications. Yet, challenges like server-side rendering (SSR), static site generation (SSG), performance, and accessibility have often kept developers reliant on frameworks and custom solutions. Declarative Shadow DOM bridges these gaps, unlocking the full potential of web components for the modern web platform.

By simplifying integration with SSR and SSG, Declarative Shadow DOM makes web components more approachable, scalable, and powerful across a variety of tools and frameworks. Whether you’re working with JavaScript-based solutions like Astro or React, or traditional server-side frameworks like Django or Laravel, the benefits are clear: faster load times, improved developer experience, and seamless browser parsing of components.

Now it’s your turn to explore Declarative Shadow DOM! Try implementing it in your next project or experiment with the provided demos to see how it can transform your workflow. Start small with a simple component or take a bold step by integrating it into your production-ready web applications.

Check out the demo repositories linked below, and don’t forget to share your feedback and experiments. Let’s build the future of the web—declaratively. 🚀

Some common questions

What about including the same component with the same CSS multiple times on the same page?

This is not a problem at all, and browsers are highly optimized for this exact case. To quote from the article on web.dev:

The browser uses a single backing CSSStyleSheet that is shared by all of the shadow roots, eliminating duplicate memory overhead.

What about a Flash Of Unstyled Content (FOUC)?

This is another problem that goes away with declarative shadow DOM. Should you need or prefer to support browsers in which declarative shadow DOM is not supported, I would recommend that you read the section in the web.dev article that touches on this very topic.

Could you generate the template server side for non-declarative shadow DOM?

You surely can, but your content will still not be available in the following cases:

JavaScript fails or is not executed at all
Search engine indexing

To clarify the second point here. As of the writing of this post at the tail-end of 2024, only Google’s crawler will crawl with JavaScript enabled for indexing when needed. None of the other large search engines that maintain their own index does this. This means that the content inside the template element will not be indexed.

There may also be some performance impacts to consider should one be cloning multiple large template elements and inserting them into the DOM. I have not done extensive testing in this regard, but it is something to keep in mind.

You can try out an example of this in the Shadow Core example project.

Demo projects

As part of writing this article, I created several example projects that demonstrate using web components using the different approaches outlined here. Below is a list of these along with a short description of each.

Shadow Core HTML

As the name suggests, this one is a pure HTML implementation with no framework. This one also does not use Declarative ShadowDOM.

Find the code and the live example below:

Shadow Core

This example project is the same as the above but implemented using Astro. This means that the page is generated during the build phase and then upgraded using JavaScript on the client. Try disabling JavaScript and reloading the page.

Find the code and the live example below:

Neo-Shadow HTML

This is like Shadow Core HTML but uses Declarative ShadowDOM. Find the code and the live example below:

Neo-Shadow

Are you seeing a pattern here? 🙈 This is the Declarative ShadowDOM variant implemented in Astro. Try disabling JavaScript and reloading the page.

Find the code and the live example below:

Neo-Shadow Laravel

Same as the other two Neo-Shadow examples but implemented in Laravel. In this example, the content is hard coded in the controller, but you can imagine this coming from a database call and then returned. From a front-end and user experience perspective, this does not matter and the behavior will be the same. As with the Astro example, try disabling JavaScript and reloading the page.

Find the code and the live example below:

The support landscape

Additional Resources

An example Astro project with declarative shadow DOM loading data from a third-party API - NeoShadow on GitHub
The HTML template element on MDN Web Docs
Declarative Shadow DOM article on web.dev
Web Components documentation on MDN Web Docs
Custom elements reference on MDN Web Docs
Shadow DOM reference on MDN Web Docs
ElementInternals documentation on MDN Web Docs

Schalk selected Distribute Aid for an honorary donation of $50

Distribute Aid is a nonprofit that enhances humanitarian logistics by supporting grassroots aid organizations with scalable infrastructure. Its mission is to meet basic human needs through efficient aid delivery while empowering local communities.

CSS content-visibility

2024-12-17T00:00:00.000Z

Newly available in Baseline 2024 is the content-visibility CSS property and as its name implies, it controls the visibility of an element’s content.

What makes this property different than selecting all of an element’s children and setting a rule for them like display: none or visibility: hidden is that content-visibility applies to all of an element’s content — including text nodes and pseudo-content — not just child elements.

In the following demo, the visibility of the content is different due to the use of display: none versus content-visibility:hidden. Validate what's happening by inspecting with browser dev tools.

Comparison of using content-visibility

.display-none > * {
    display: none;
}

.content-hidden {
    content-visibility: hidden;
}

This element is hidden.

This is the only visible text because its a text node inside of display: none

This element is hidden.

This text is also hidden.

It’s also different than having display: none or visibility: hidden directly applied to the element itself, since for those properties the entire box isn’t visible, while for content-visibility its own box is generated and visible.

But there’s more to content-visibility than just being a visibility on-off switch — it allows browsers to fully skip rendering for the contents. This means skipping style calculation, layout, and paint. The property is a power tool in a web author’s performance kit. Before we unwrap the syntax of content-visibility, we need to talk about CSS containment.

CSS Containment

If you’ve used container queries, then you’ve already encountered containment, whether you were aware of it or not.

Containment isolates a subtree of the document to improve performance and stability. This also allows features like container queries to exist since it helps avoid infinite loops.

There are four types of containment:

Size containment ignores the element’s contents when determining its size.
Layout containment prevents contents inside and outside from affecting each other’s layout. For example, margin on content will not collapse with the parent’s margin (and therefore surrounding elements). Other features like baseline alignment do not affect an element with its layout contained.
Paint containment clips any content from within the element that is protruding outside and isolates the content, which affects properties like mix-blend mode.
Style containment affects features like CSS counters: contained content cannot affect counters outside of the container.

Containments can be explicitly applied to an element using the contain property. container and content-visibility both automatically apply the containments they need for their intended purpose.

Containment allows browsers to skip rendering an element’s contents when it’s hidden, which can improve performance, since the browser is free to focus on what’s relevant to the user. Browsers can also save rendering work, since the isolation created by containment makes rendering more predictable, improving the speed at which content can be hidden or made visible.

Now that we have a cursory understanding of containment let’s dig into content-visibility.

Using content-visibility

There are three values for content-visibility: visible, hidden, and auto. We’ll explore how each works, but we’ll end up focusing on auto as it’s extremely useful.

The initial value: visible

The initial value of the property is visible. When this is applied, no containments are applied to the element, and it has no performance optimizations. This is the regular old element you’re familiar with.

Manually hiding content with hidden

content-visibility: hidden hides the element’s contents and applies a strong set of containments to the element: size, layout, paint, and style. It’s very important to note that when content-visibility is set to hidden that content will be hidden from the accessibility tree and “find-in-page” browser features. Later we’ll touch on a couple of emerging web platform features that use content-visibility: hidden and differ a small bit in this regard.

In this example, we’ve got the same box with content using both the visible and hidden values of content-visibility. In the latter case, the box is still generated, but the content takes up no space.

See the CodePen.

While the contents are hidden, it’s possible to measure them. This will trigger the browser’s rendering process for the contents, but the content will remain hidden.

Letting the browser decide using auto

When the auto value is used, the browser hides the element’s contents while it’s not relevant to the user. This can serve as an easy performance win for many use cases.

Whether the contents are skipped for rendering or not, a set of containments is applied to the element:

When the contents are rendered: layout, paint, and style containment are used on its containing element.
When the contents are skipped: layout, paint, style, and size containment are used on its containing element.

An important difference between hidden and auto is that auto keeps the content in the accessibility tree and ensures it’s still findable with a browser’s “find-in-page” feature.

Pairing with contain-intrinsic-size

When content-visibility is set to hidden or auto, and the element’s content is skipped, size containment is applied to the element. This means that the size of the element will be purely based on whatever dimensions are set for itself, its own padding, border-size, or the layout that it’s a part of. In many cases that’s not an issue, however, for some it can create problems. This is where the contain-intrinsic-size property and its longhands can help.

Long, overflowing lists are a great use case for content-visibility: auto, but that on its own can create some issues, as the scrollbar no longer becomes a reliable indicator of scroll progress.

In this example, we don’t have an intrinsic block-size for the element, so when it’s hidden the content take up no space which causes the scrollbar to be larger than what it would be if all of the list items are rendered. As the list items render, notice that the scrollbar changes sizes, getting smaller as it renders more items.

See the CodePen.

If the block-size of the list items is consistent, we can set contain-intrinsic-block-size to whatever the size of the content is.

li {
    content-visibility: auto;
    contain-intrinsic-block-size: 2lh;
}

In this example, the content of each list item is stable, so we can set contain-intrinsic-block-size to the block-size of the content. Notice that the scroll remains stable and doesn’t jitter.

See the CodePen.

In cases where there is no consistent size, but you have a good idea of what the average is, you can set auto before that value, and this will cause the property to remember what its size was if it ever was rendered. Before then, it’ll use the other value as a fallback.

li {
    content-visibility: auto;
    contain-intrinsic-block-size: auto 2lh;
}

In this example, we don’t have a stable item size, so instead we’ve taken the average which we’ll use with contain-intrinsic-block-size as a fallback. We’ve set auto as the preferred which uses the last known rendered size as its value. Again, notice that the scrollbar mostly remains stable without jittering.

See the CodePen.

When content-visibility is used on elements within a complex layout, it can accidentally trigger undesirable layout reflow, when the content becomes visible again, and the size containment is dropped. This is another case where setting the intrinsic size of the contained element will help.

What makes content relevant?

content-visibility: auto doesn’t just render content when it’s on-screen; it’s a bit more nuanced than that: it renders content when it is considered relevant to the user. The following are conditions that make content relevant for the user:

The content is close to the viewport.
The content has an element with focus.
The content’s text is selected.
The content is in the top layer (i.e. the <dialog> element and Popover API both use the “top layer” to keep their content on top of everything else).
The content is part of a view transition.

Observing whether content is skipped with JavaScript

You can listen for the contentvisibilityautostatechange event — yes, it’s a doozy to spell out. The event has a skipped property which indicates when the content is currently skipped. While this is helpful for being able to confirm that the feature is indeed working, you can also use it to either start up or tear down expensive features depending on the skipped state (e.g. rendering on a <canvas> element or make network requests).

This is the same example we used for using an average intrinsic block-size for the elements, but I’ve included some JavaScript to log out whether elements are skipped using the contentvisibilityautostatechange event, so make sure to view the console as you scroll the items.

See the CodePen.

What does content-visibility not do?

While the auto or hidden value can skip rendering the content, this does not prevent resources such as images from downloading eagerly, so it’s a good idea to employ some sort of lazy-loading strategy alongside content-visibility. That could look like using the loading=lazy attribute.

How does the platform use content-visibility?

There are a few emerging features in the web platform that use content-visibility.

::details-content

One is the ::details-content pseudo-element. This is a part of the <details> element’s shadow tree — yes, many HTML elements are implemented with the Shadow DOM. ::details-content is a part-like pseudo-element that exposes the internal container element. In Chromium that container element is <slot> which defaults to display: contents, ::details-content sets the element as display: block and then hides the content with content-visibility: hidden. This means you can both style the element that houses the content and more easily animate it.

As of writing, this feature is only available in Chromium-based browsers (versions 131 and later — see Can I use… for ::details-contents current availability).

hidden=until-found

The other emerging feature is the hidden=until-found attribute and value combination, which hides an element's contents until it’s found using the “find-in-page” feature. Instead of setting display: none for the element, the until-found value sets content-visibility: hidden.

As of writing, this feature is only available in Chromium-based browsers (versions 102 and later — see Can I use… for hidden=until-found current availability).

Differences with content-visibility: hidden

One important note for both of these features that is unlike how content-visibility: hidden works by both hiding the content from the accessibility tree and “find-in-page” features, both the <details> element and hidden=until-found allow their content to be findable. Once found, the <details> element expands, and the hidden attribute is removed.

Summary

Let’s cover what we’ve learned:

content-visibility makes it easy to hide content, completely skip rendering, and to opt-in to greater performance when we find ourselves in situations filled with content.
Having a grasp of CSS containment is important when using content-visibility because it causes different types of containments to be applied to the element.
We can use another feature of the CSS containment suite, contain-intrinsic-size and its longhands, to create an intrinsic size for elements with their contents skipped to avoid strange scrollbars or unexpected layout reflows.

CSS text-wrap

2024-12-16T00:00:00.000Z

In print typography, a lot of attention is paid to line-breaking and text wrapping (among many other things). In web typography, where we have no guarantee of line length, display area, or even font face, we’ve traditionally either ignored those things or hacked like mad scientists. It’s all part of the Dao of web design, even if that does sometimes mean weirdly balanced text or hanging single words (known as “runts”, at least sometimes).

But now, thanks to the shorthand property text-wrap — I’ll break it apart into the longhand properties later — we can exert… well, some influence. Plus we can do things that we used to rely on white-space to do. For example, we can prevent text wrapping!

Figure 1. Text wrapping normally, and not wrapping at all.

nowrap, as its name implies, prevents line-wrapping. You can still use white-space: nowrap if that’s what your fingers’ muscle memory has programmed, so don’t worry about that going away.

Beyond that, text-wrap offers two very welcome new values. First up, you can have the browser balance your element’s line lengths. Compare the following example of text-wrap: balance to the text-wrap: wrap shown in Figure 1.

Figure 2. Balanced text wrapping.

There are no line-breaks or other extra bits in the HTML content. Instead, the browser has looked at the element’s layout size and its content, and then shifted the line breaks around so that the individual lines of text are as close as possible to the same length.

You might think this would be computationally expensive, and you’re right, it is. That’s the reason some browser engines limit the number of lines of text to which this can be applied: six for Chromium, and nine for Gecko. WebKit, on the other hand, either doesn’t impose a limit, or has a limit higher than my testing could find (I went up to 25 lines).

Still, it’s really an effect to be used on headings, pull quotes, and other elements that will have enough content to run more than one line, but not so much content that they go past around five lines.

There’s also a way to have “normal” line wrapping while avoiding runts: text-wrap: pretty. Here’s a comparison of the default behavior to the “pretty” version.

Figure 3. Preventing last-line loners with pretty wrapping.

Here, the only line balancing is to avoid having the last line of text in the element have just one word. You might have faked this in the past by replacing the last space in the element’s content with an  . Now, the CSS will just do it for you, at least in Chromium browsers; support has yet to land in WebKit and Gecko.

Be careful, though: just calling the wrapping pretty does not guarantee pretty results, nor does it guarantee that you’ll never leave a lone word hanging at the end of an element. Long words near the end of the content are a quick way to make things weird, as shown in Figure 4.

Figure 4. Some limits of pretty wrapping.

I would say the first example is better than the second, but either way, these are what pretty yielded. It’s no worse than plain old wrap behavior, but it’s not really any better either.

It should also be noted that pretty could do a lot more in the future. The current-as-of-this-writing draft of the specification says that beyond just avoiding runts:

The precise set of improvements is user agent dependent, and may include things such as: reducing the variation in length between lines; avoiding typographic rivers; prioritizing different classes of soft wrap opportunities, hyphenation opportunities, or justification opportunities; avoiding hyphenation on too many consecutive lines…

That’s the entire sentence — the ellipsis at the end there is part of it. So this is a value that could lead to rendering changes over time, should browser engines choose to do more.

As I said up top, text-wrap is actually a shorthand property that encompasses the properties text-wrap-mode and text-wrap-style. The values wrap and nowrap come from text-wrap-mode, whereas balance and pretty come from text-wrap-style. The latter also has a value called stable, which is defined to keep lines before the input cursor from re-flowing when the content is editable and being edited, but I couldn’t find any difference between stable and wrap behavior when I tested it.

So there you have it: text wrapping, all wrapped up for the holidays! Whether you use it to prevent line-wrapping or make line lengths more consistent in headlines, text-wrap and its longhands give us some welcome new options in text layout.

Eric selected Rebecca’s Gift for an honorary donation of $50

The money raised by Rebecca’s Fund will be added to the St. Baldrick’s efforts to fund promising research in the prevention of tumor reemergence.

HTML inert Attribute

2024-12-15T00:00:00.000Z

While an element and its descendants with inert are removed from the DOM, they will still be visible! Inert is meant to be applied to obscured elements that should not receive interaction events.

This is especially helpful if you want to "trap" focus to a particular part of your website.

Be aware that it is not the same as display: none and visibility: hidden, though, which makes elements disappear visually.

Explanation

According to the HTML specs, this is what inert does:

The inert attribute is a boolean attribute that indicates, by its presence, that the element and all its flat tree descendants which don’t otherwise escape inertness (such as modal dialogs) are to be made inert by the user agent.

Translated into human language: An HTML element with the inert attribute becomes inactive, including all the (interactive) elements inside that element. They also go a bit more into detail how it should (and shouldn’t) be used:

An inert subtree should not contain any content or controls which are critical to understanding or using aspects of the page which are not in the inert state.

Don’t use this attribute on a parent element containing information or things like buttons, inputs or links that are important to understand or operate your website when there is no element visually blocking their use.

Content in an inert subtree will not be perceivable by all users, or interactive.

Anything inside an element with the inert cannot be perceived or operated, which is the whole point of it.

Authors should not specify elements as inert unless the content they represent are also visually obscured in some way.

If something is blocked by something or not visible at all, consider using inert. If it cannot be perceived, maybe it should not be operable at all.

In most cases, authors should not specify the inert attribute on individual form controls. In these instances, the disabled attribute is probably more appropriate.

Use inert on elements containing other elements to make larger sections inactive. If you want to disable something like a button, text field, checkbox, or radio button, use the disabled attribute instead (this is a whole topic by itself; see Making Disabled Buttons More Inclusive by Sandrina Pereira).

Use cases

For me, the most obvious use case would be when moving attention or focus to a dialog that just opened. As long as it is open, information and interactive elements outside of it are not available to the user. Of note, this is the default behaviour of the <dialog> element when using the showModal() method.

Another example: Say you provide a guided tour through your website to learn about different sections and UI elements. To ensure that keyboard users move from A to B to C and so on, you only enable the elements explaining something and the element(s) in question. The rest becomes inert!

Accessibility considerations

inert is not:

Meant to disable interactive elements, this is what the disabled attribute is for.
The same as visibility: hidden, which only removes it visually but keeps it inside of the DOM.
Used for removing elements visually and from the DOM, like display: none. Although if referenced from visible elements’ aria-describedby or aria-labelledby attribute they should still be exposed to assistive technologies.

inert is meant for making an HTML element (and all HTML elements inside of it) inactive, not focusable and ignored in the accessibility tree because the respective element is either partially or fully obscured.

Conclusion

Use inert on elements that are obscured and not entirely visibly hidden (like with display: none), such as by some type of overlay that is intended to keep keyboard focus while open. This way you can provide a consistent experience for mouse, keyboard and assistive technology users.

Be aware that it is not the same as the disabled attribute or visibility: hidden.

Additional resources

Steve selected The Asher House for an honorary donation of $50

A registered non-profit sanctuary in Salem, Oregon. They rescue animals that have been discarded or unwanted, providing them with a life of comfort, love and adventure.

Animating Entry Effects

2024-12-14T00:00:00.000Z

Animation is a critical component of interactive storytelling. An animation creates a journey, no matter how small, from point A to point B.

In classical animation, an artist draws one frame at a time, and a camera snaps a snapshot of each progression. For just one second of animation, 24 frames need to be drawn, captured, and sequenced.

For interactive content such as video games, web apps, and operating systems, players, visitors, and customers expect a stable 60 frames per second. Anything less than 60 individual images per second is perceptible to people with an eye tuned for it.

CSS Animations

With CSS, there are two primary properties used for animation: transition and animation. Both properties allow customization based on how long the animation should last (duration), when it should start (delay), and how the in-between frames should be "tweened" (easing).

Today, we will focus on a couple of aspects that can be utilized with the transition property in CSS: allow-discrete and @starting-style.

In the demo we'll build, we will gracefully fade-in all content as it appears in our web document.

Before we go further, we need to take a step back and zoom out.

We know animation is a journey from point A to point B, but what are the technical terms for point A and point B?

Keyframes

A keyframe is the state of affairs at any moment in time. Given two states, we can calculate the difference between them and animate. This works great for things like numbers, but it doesn't work great for non-number, discrete CSS values.

For example, there are a myriad of ways to not show a piece of content with CSS. Two of the more popular CSS properties are using opacity (continuous) and display (discrete).

Opacity

Opacity is continuous and takes a value between 0 and 1, inclusively. An opacity of .5 will be 50% transparent—you'll be able to see the content behind the content. An opacity of 0 is hidden, and 1 is entirely visible.

If the opacity of point A is 0 and the opacity of point B is 1, with an animation duration of 1000ms, the following statements are true.

At 0ms, opacity: 0
At 250ms, opacity: .25
At 500ms, opacity: .5
At 900ms, opacity: .9
At 1000ms, opacity: 1

Writing each intermediate step out in code would be tedious, which is why the CSS engine tweens values on our behalf.

Display

Display values are discrete and may be defined as: inline, inline-block, flex, grid, inline-flex, inline-grid. All those properties will result in visible content.

Display may also be set to none, hiding the content entirely.

Historically, CSS has not had a way to animate from a point A of display: block to a point B of display: none or of a point A of display: none to a point B of any visible display type, such as display: grid.

Animating between non-number discrete values, is hard. How can we do it?

Code and Demo

The following explanations will refer to this demo.

See the CodePen.

Using allow-discrete

The transition property allows for a constituent property transition-behavior, which may be set to allow-discrete, which will allow CSS to animate between discrete values.

In this example, we apply the transition-behavior of allow-discrete to all elements. The transition-properties we're using are visibility, transform, and opacity. Opacity and transform are both continuous properties that have been able to transition since transition was implemented in CSS. Visibility is a discrete property and needs allow-discrete to transition properly.

Using @starting-style

In the example, notice the use of @starting-style. This block is where we can define the initial keyframe we want to transition from. This is an opportunity for a new default value we, as web authors, define for our applications.

In the @starting-style block, we select all elements with the wildcard selector and set the initial visibility to hidden with an opacity of 0.

When the page loads, these will revert to their browser defaults of visibility: visible and opacity: 1, creating a smooth transition.

Exploring Opportunities

@starting-style and transition-behavior: allow-discrete unlock the potential for animated storytelling that previously required JavaScript to achieve similar effects. With these tools now baked into CSS directly, how will you use them?

While the example in this demo is intentionally light to stay focused on the basics of these properties, a great first project might be to build a modal that can gracefully fade in and fade out. A common pitfall when implementing modals is for the hide animation to immediately hide with no animation, which generally happens when visibility: hidden triggers, when the modal should instead hide at the end of the animation sequence.

By using transition-behavior: allow-discrete when hiding the modal, other CSS or JavaScript workarounds that have historically been used for a smooth effect when hiding are no longer necessary.

Tyler selected Internet Archive for an honorary donation of $50

The Internet Archive's mission is universal access to all knowledge, where they are most know for their keyframes across web space time in the Wayback Machine.

calc-size() and interpolate size

2024-12-13T00:00:00.000Z

Animating to or from height: auto has been something front-end developers have had on their wishlist for a very long time, and now, not only can we do that very easily, but there are new possibilities that have opened up on top of that as well, all thanks to two new CSS features:

The interpolate-size property
The calc-size() value function

All you need is one line of CSS

The new interpolate-size property enables animating to intrinsic sizes, such as auto.

Here’s a simple example of it in action: We go from block-size: 1lh to block-size: auto.

See the CodePen.

Enabling it site-wide with a single declaration

The value of interpolate-size is inherited, so we can enable it across our entire site with a single declaration.

html {
  interpolate-size: allow-keywords;
}

That means with a single declaration, you’ve basically opted in to allow transitions and animations using keyword values site-wide!

This is perfect to include this as part of your CSS reset for new projects.

I’ve already started using this in a few places where I need to go from block-size: 0 to block-size: auto, such as with navigations and menus.

See the CodePen.

We can also use this to animate details/summarys, though that also involves using ::details-content, which at the time of writing, has very limited support. Just like calc-size() and interpolate-size, it does make for a great progressive enhancement!

It’s not just for height auto

While animating to and from height: auto might be the most common pain point interpolate-size solves, it also allows us to animate to any of these keyword values:

auto
min-content
fit-content
max-content
content

See the CodePen.

However, you cannot use this to go between two different keyword values, as you can see in this example where it doesn’t work.

See the CodePen.

While that would be cool, I still see this as such a big win that I really don’t mind this one constraint.

You can use animations as well

All of the examples so far have used transitions, but this also opens up using keyword values in animations as well.

For example, instead of simply transitioning open to closed, we can add a nice little bounce effect.

See the CodePen.

Why isn’t this the new default?

There were talks of having this be the default value, but there would be potential conflicts in older sites, such as situations where JavaScript was being used for these types of animations or where assumptions were made knowing transitions wouldn’t work in specific situations.

Because of this, I’d caution against blindly inserting this into older projects. From now on, throw it in that reset and make animations super easy, but I wouldn’t retrofit it into an old project without some testing first.

When you need more fine-grained control

interpolate-size is such a quick win, but you might find yourself running into situations where you want something a little bit bigger or smaller than one of the intrinsic sizes.

calc() doesn’t allow for calculations based on keyword values, but another new addition is calc-size(), which does!

The syntax of calc-size() is a little trickier than that of calc(), but once you get used to it, it’s not so bad.

The reason I say that it’s trickier is that you must pass two values:

the intrinsic value that you want to use
the calculation you want to do to that size

Here are some examples:

.height-example {
  block-size: calc-size(auto, size + 24px)
}

.width-example {
  inline-size: calc-size(max-content, size * .5);
}

In the first example above, I pass the keyword value that I want to do the calculation on (auto), and then after the comma, I say to take whatever size value is computed and add 24px to it.

In the second example, I want the calculation to be based on the max-content of my element and then multiplied by 0.5 so that it becomes half that size.

Here is another simple example.

.max-content {
  inline-size: max-content;
}

.bit-bigger-than-max-context {
  inline-size: calc-size(max-content, size + 3rem);
}

For a bit more of a practical use case, in the example below, I use position absolute to move an SVG icon out of the flow and offset it to overflow to the right of the button that it is inside of. Then, using calc-size() for the hover and focus states, I can add the distance I’ve offset the icon to the auto size of my button.

See the CodePen.

Animations and transitions with calc-size()

While you might want to use calc-size() for making something slightly bigger or smaller than one of the keyword values, just like interpolate-size, it also opens up animations and transitions on these values as well.

Below, I’ve updated the previous example to add a transition to the inline-size of my button. Because I’m using a calc size(), it works!

See the CodePen.

calc-size() doesn’t require interpolate-size

When you use calc-size(), transitions to and from intrinsic sizes will be allowed regardless of whether you’ve declared interpolate-size: allow-keywords.

You can see that in action in the previous example, where I didn’t declare interpolate-size, and the transition still works.

That means that you could do something like this all on its own, and it’ll work as well:

.transition-height {
  height: 1.5lh;
  overflow: clip;
  transition: height 1s;
}

.transition-height:hover {
  height: calc-size(auto, size);
}

However, it is recommended to use interpolate-size for this instead.

It’s easier to simply “turn on” site-wide keyword animations and transitions and then rely on calc-size() when you need to do actual calculations based on keyword values.

Also, it’s worth noting that, just like interpoloate-size: allow-keywords doesn’t work for transtions or animations between keyword values, the same holds true with calc-size().

Using interpolate-size as a progressive enhancement

If interpolate-size is not supported by a browser and you go from block-size: 0 to block-size: auto, the browser will still switch between those two sizes, just without the transition between them. And to me, that makes it a perfect progressive enhancement.

People who are using browsers that support it get a nicer experience, but it won’t cause any issues for anyone using a browser that lacks support.

On the other hand, calc-size() might be something you have to be more careful with, though.

For my buttons above, where I expanded them to show an icon, I wouldn’t really mind if a user didn’t see the icon because it doesn’t give extra value or context to the purpose of the button, but there are times when the extra size you are adding could be important or impact the layout in an important way.

In either case, it probably is a bit of a case-by-case basis, but I do think most cases of interpolate-size would be fine. You might either have to think about it or provide alternatives with a @supports feature query for calc-size().

Kevin selected CHU Sainte-Justine Foundation for an honorary donation of $50

Support CHU Sainte-Justine in its pursuit of excellence and its commitment to providing children and mothers with one of the highest levels of health care in the world, now and in the future.

Container Style Queries

2023-12-24T00:00:00.000Z

One of the most requested features in CSS was container queries, the ability to query the size of a parent container. Before container queries, you could only query the size of the viewport. That worked well and still does, allowing you to create responsive websites, but it's really just a compromise because, in most cases, we're interested in the size of our parent container, not the size of the viewport.

That’s why container queries are such a critical addition to CSS.

In this example, when the .cards container reaches a minimum width of 60rem, set the flex-grow value of each .card within the container to 1.

.cards {
  container-type: inline-size;
  display: flex;
}

@container (inline-size > 60rem) {
  .card {
    flex-grow: 1;
  }
}

I find container style queries even more interesting than container size queries because they could significantly change the way we think about and write CSS. Join me as we explore the reasons why.

The Theory

The difference between size and style queries is that with style queries, you don't query a predefined list of features but use the style() function to query the value of a CSS property.

If you wanted to apply styles to an element only when one of its parent elements has a display property with the value flex, you could do that by querying style(display: flex).

Here, when the .cards container's display property is set to flex, add a border to all but the .card that is the :last-child.

.cards {
  display: flex;
  container-name: cards;
}

@container cards style(display: flex) {
  .card:not(:last-child) {
    border-inline-end: 2px solid;
  }
}

Unfortunately, I can't provide you an interactive demo because style queries with normal properties aren't supported in any browser and might never be because there are still concerns about its feasibility.

The practice

What you can do today, at least in supporting browsers, is query custom properties.

Let's take the following example: We have a red button, a regular section with a transparent background, and a highlighted section with the same red background as the button.

See the CodePen.

The button works well in the regular section but almost vanishes in the highlighted section.

You could select all buttons in that section (.section--highlight button) or create a class with alternative styling for buttons to work around the issue.

See the CodePen.

That works, but it's a local solution to a global problem. It fixes the bug, but it doesn't solve your general issues:

If there are other buttons, you must also add the class.
Other elements, like links, will have the same or similar conflicts.
You'll likely want to nest buttons in other containers with the same background color.

If you've built larger, themeable systems, these problems are not news to you, and you know how to solve them.

One solution is to define custom properties on the highlighted section that descendants can inherit.

See the CodePen.

That frees you from applying classes to your buttons and automates the process but also ties your button styles to the highlighted section, which doesn't scale well, and you can’t reuse the button styles.

Container style queries offer a more global and systematic solution: You can add a container query that checks whether any parent element has a red background color (--container-bgc: var(--red)). If that's the case, its descendant buttons get custom styles.

Please note, I've renamed the --section and —-body prefix to --container to make it globally applicable.

See the CodePen.

That's already pretty great because the button styles change depending on the value of the --container-bgc property and not on the kind of parent element.

The only problem with this solution is that you can't reuse those alternative button styles elsewhere. You could try to make them reusable, similar to a mixin in Sass, by creating another query to apply them whenever a container has the --button-style: secondary property and value.

/* Sets the buttons styles when a parent element has the custom property */
@container style(--button-style: secondary) {
  button {
    --button-bgc: var(--white);
    --button-color: var(--red);
  }
}

/* Uses the button styles defined earlier when the background is red. */
@container style(--container-bgc: var(--red)) {
  button {
    --button-style: secondary;
  }
}

That doesn't work, though, because the properties in the first query apply if a parent element of the button has --button-style: secondary set. Still, the second query sets the property on the button itself, not a parent element.

The absence of containers is a problem you'll often face when working with container queries. Miriam Suzanne, co-author of the containment specification, suggests Turtle Components™️ - elements that come with a shell (an extra container).

<body> <!-- shell -->
	<main class="container-inner"> <!-- new! 🐢 -->
		<section> <!-- shell -->
		  <div class="container-inner"> <!-- new! 🐢 -->
		    <h2>Default section</h2>
		    <button type="button">Let it snow!</button>
		  </div>
		</section>
		
		<section class="section--highlight"> <!-- shell -->
		  <div class="container-inner"> <!-- new! 🐢 -->
		    <h2>Highlighted section</h2>
		
		    <button type="button">Let it snow!</button>
		  </div>
		</section>
	</main>
</body>

The content of each section is wrapped in an extra div.container-inner, as well as the whole main content.

When the parent container has the right background color, styles apply to the inner container element.

In this update, we query the parent section, apply properties/settings to the .container-inner div to which other queries can react.

See the CodePen.

I know what you’re thinking: "That’s over-engineering par excellence! Why would you want to add so much complexity?"

For one, it scales well! If you add a completely different element with the same background color, its text and the button adapt accordingly. You don’t need any extra steps.

Here's an entirely new component with the same concept of default and highlighted background color.

<div class="card">
  <div class="container-inner">
    <h3>I'm a card</h3>
    <p>Lorem ipsum dolor sit.</p>
    <button type="button">Let it snow!</button>
  </div>
</div>

<div class="card card--highlight">
  <div class="container-inner">
    <h3>I'm a card</h3>
    <p>Lorem ipsum dolor sit.</p>
    <button type="button">Let it snow!</button>
  </div>
</div>

Just set the background color and the button will adapt accordingly.

.card {
  background-color: var(--container-bgc);
}

.card--highlight {
  --container-bgc: var(--red);  
}

Admittedly, you could achieve a similar result by creating a helper class that does the same thing by setting all the necessary properties.

<div class="card h-theme--highlight">
  <div class="container-inner">
	  …
  </div>
</div>

.h-theme--highlight {
  --container-bgc: var(--red);  
  --container-color: var(--white);
  --button-bgc: var(--white);
  --button-color: var(--red);
}

You can do that, and you might find it more intuitive, but like I said in the introduction, container style queries can change how you approach CSS. They enable you to reduce the dependency of the class as a middleman between your markup and your styles. Not that classes are bad in any way, but it's worth exploring how you can automate the process of adding conditional styling to your components using classes in HTML by writing conditions in CSS.

You can even take it further and eliminate the modifier classes, and it would still work because your container queries look for custom properties on the element.

<section style="--container-bgc: var(--red);">
  <div class="container-inner">
    <h2>Highlighted section</h2>

    <button type="button">Let it snow!</button>
  </div>
</section>

See the CodePen.

If you want to support more colors, all you need to do is extend the query. This will apply custom styles if the background color is red or gray.

See the CodePen.

If you want to add dark mode to your site, all you do is change the --container-bgc property on the body.

@media (prefers-color-scheme: dark) {
  body {
    --container-bgc: var(--gray);
  }
}

See the CodePen.

The level of abstraction you pick depends on the size of your design system and who's using it. Suppose you're not the only one working with the components you build, but different teams and third parties. In that case, investing some extra work to create a resilient and flexible architecture that automates certain rules while improving the developer experience makes sense.

Container Style Queries may increase complexity for you, but they can decrease it for people using your components.

Use cases

There are also other use cases that work for projects of any size. Here are some examples.

Page-level settings

Especially in large systems, but also on smaller sites you have different variations of page themes, layouts, and styles. With container queries, you can give authors a simple and human-readable way to tweak page styles.

For example, using custom properties on the root element to make decisions about the page’s theme and styles.

:root {
  --theme: light;
  --style: rich;
}

You can edit the CSS in this Pen directly in the light grey area.

See the CodePen.

Component-level settings

You can provide a theming API for components.

.card {
  --card-size: m; /* s, m, l */
  --card-theme: light; /* light, dark, colorful */
}

See the CodePen.

Inheritance

The great thing about custom properties is that they're inheritable. If you want to change the size of all cards in a container, you apply the settings to the container instead of each card separately.

<div class="cards" style="--card-size: s;">
  <div class="card"></div>
  <div class="card"></div>
  <div class="card"></div>
</div>

Or in CSS, where the --card-size setting will apply to all nested cards.

.cards {
  --card-size: s;
}

See the CodePen.

Relational styles

Using the :has() pseudo-class, you can apply styles to an element if it has a specific child element.

.card:has(img) h1 {
  background: var(--gray);
  color: var(--white);
}

With container style queries, you can do a similar thing in CSS. In the following example, styles only apply if the element has a background image. You're checking the existence of a particular property.

In this style query, the .content gets a background color and a different text color when its parent element has a background image.

.card-inner {
  --card-background-image: url('background.jpg');

  background: oklch(100% 0 0) var(--card-background-image);
  background-size: cover;
}

@container style(--card-background-image) {
  .content {
    background-color: oklch(30% 0 0);
    color: oklch(100% 0 0);
    padding: 0.2em 0.6em;
  }
}

See the CodePen.

Mixins

There is a proposal for mixins, but it still needs to be completed. With container style queries, you already have some of the functionality mixins would offer: reusability.

Let's take this simple media query. A small button becomes larger at a minimum width of 30em.

button {
  font-size: var(--font-size, 1.2rem);
  border: var(--border-width, 2px) solid var(--border-color, transparent);
  
  /* other button styles */
}

@media (min-width: 30em) {
  button {
    --font-size: 1.6rem;
    --border-width: 4px;
    --border-color: oklch(from var(--red) calc(l - 10) c h);
  }
}

If you wanted to reuse those styles somewhere else, you'd have to repeat them.

.btn--large {
  --font-size: 1.6rem;
  --border-width: 4px;
  --border-color: oklch(from var(--red) calc(l - 10) c h);
}

Instead, you can create a custom property that takes those styles and puts them wherever you want.

<div class="btn">
  <button type="button">
    Let it snow!
  </button>
</div>
  
<div style="--btn-style: large">
  <button type="button">
    Let it snow!
  </button>
</div>

<div class="btn--large">
  <button type="button">
    Let it snow!
  </button>
</div>

button {
  font-size: var(--font-size, 1.2rem);
  border: var(--border-width, 2px) solid var(--border-color, transparent);
}

@media (min-width: 30em) {
  .btn {
    --btn-style: large;
  }
}

.btn--large {
  --btn-style: large;
}

@container style(--btn-style: large) {
  button {
    --font-size: 1.6rem;
    --border-width: 4px;
    --border-color: oklch(from var(--red) calc(l - 10) c h);
  }
}

See the CodePen.

It's not really a mixin because you can't pass parameters, but you can reuse styles without duplicating them.

Summary of technicalities

Before we wrap this post, let me quickly summarize some technicalities that are worth knowing.

Type and Name

Every element is a style container; you don't have to set the type explicitly.

A query always queries the closest parent container unless you provide a container name in the query.

<main> <!-- container "page" -->
  <div class="wrapper"> <!-- container "wrapper" -->
    <h1>Ho! Ho! ho!</h1>
  </div>
</main>

:root {
  --gray: oklch(30% 0 0);
  --white: oklch(100% 0 0);
  --green: oklch(0.56 0.16 134.58);
  --red: oklch(0.56 0.26 28.58);
}

main {
  container-name: page;
  --style: var(--red);
}

.wrapper {
  container-name: wrapper;
  --style: var(--green);
}

/* Evalutes to `true` because it is looking at
the --style property on `main` */
@container page style(--style: var(--red)) {
  h1 {
    border: 2px dotted;
  }
}

See the CodePen.

Name and value

You can query custom properties without providing a value.

@container style(--card-background-image) {
  .content {
    background-color: oklch(30% 0 0);
  }
}

/* This would be possible if style queries would work with normal properties, too  */
@container style(background-image) {
  h1 {
    background-color: oklch(0% 0 0);
  }
}

Comparison

When you're comparing two unregistered custom properties, you are comparing tokens.

The following query is true because you’re checking whether “red” is “red”.

html {
  --color: red;
}

.child {
  --bg: red;
}

/* Condition is true because `red === red`, styles applied */
@container style(--bg: var(--color)) {
  h1 {
    border: 10px dotted fuchsia;
  }
}

The following query, however, is false because the string token "red" doesn't equal the hash token "#F00", although they represent the same color.

html {
  --color: #F00;
}

.child {
  --bg: red;
}

/* Condition is false, styles not applied */
@container style(--bg: var(--color)) {
  h1 {
    border: 10px dotted fuchsia;
  }
}

To compare colors, you must register the property you’re querying as a <color>.

@property --bg {
  syntax: "<color>";
  inherits: true;
  initial-value: transparent;
}

html {
  --color: red;
}

.child {
  --bg: red;
}

/* Condition is true, styles applied */
@container style(--bg: var(--color)) {
  h1 {
    border: 10px dotted fuchsia;
  }
}

See the CodePen.

Due to property substitution, you don't have to register the second property, as well.

Conclusion

One of the most significant downsides to some of the concepts I showed in this post is that you can't query an element itself; you must query a container. That’s not so much a problem because of the extra divs you may have to add (you probably already have enough divs in your markup that you could use as containers anyway). It's that in some situations, applying styles to a container isn't intuitive. Sometimes, you'd want to apply them directly to an element.

button {
  --btn-style: funky;
}

(You can actually do that already by making use of Roma Komarov’s mind-boggling Cyclic Dependency Space Toggles.)

Nevertheless, container style queries are exciting and can make your lives or the lives of those using your components easier. At the moment, Chromium-based browsers are the only browsers that implement them. Safari is willing to implement, but we have yet to learn about Mozilla's position.

So, please play around with container style queries, and if you like them, make some noise to convince other browser vendors of their usefulness.

Manuel selected SOSBalkanroute for an honorary donation of $50

SOSBalkanroute is a humanitarian initiative for a dignified life for refugees in south-east Europe.

Responsive SVGs

2023-12-23T00:00:00.000Z

SVG can be a tricky subject. If you're a developer, you might need to have an interest in design to really dive into SVGs. And if you're a designer, you'll need to know a bit about coding to do more than just export files from design tools like Figma. This might be why we rarely see custom-made responsive SVGs, even though they are incredibly useful and versatile. In this post, I’ll guide you through the basics of creating a responsive SVG.

I was reminded of the potential of responsive SVGs when I looked at the Threads App. In the app, there's an interesting design element where a little swirl line connects the avatar of a reply to the original message's avatar.

This design is achieved using three separate SVGs, with the length of the longest part calculated by JavaScript that is triggered on page load and every time the window is resized. While this is an effective approach, it relies heavily on JavaScript. In contrast, I want to show you how you can achieve a similar result using a responsive SVG and no JS at all.

To build the desired image, there are three basic things we need to understand: the viewBox attribute, the preserveAspectRatio attribute, and SVG symbols.

ViewBox Basics

<svg viewBox="0 0 300 400" xmlns="http://www.w3.org/2000/svg">
...
</svg>

Think of the viewBox in SVGs like an artboard in a design tool. For example, when you see viewBox="0 0 300 400", it's similar to saying, "Create an artboard that is 300 units wide and 400 units tall."

Remember, we're working with vector graphics, so it's best not to think in terms of pixels, as these graphics can be scaled to any size.

SVGs also have width and height attributes, just like any other image. However, there's a key difference: by default, SVGs behave as if object-fit: contain is applied. This means if the aspect ratio set by width and height is different from the one defined by viewBox, your "artboard" will always remain fully visible and maintain its proportions without distortion.

To add a bit more complexity, you can actually choose not to define a viewBox at all. When this happens, the actual width and height of the SVG itself become the dimensions of our "artboard." This might sound a bit confusing now, but don't worry; we'll explore this in more detail later on.

PreserveAspectRatio ↔ Object-fit

<svg viewBox="0 0 300 400" preserveAspectRatio="xMaxYMin" xmlns="http://www.w3.org/2000/svg">
...
</svg>

As I mentioned earlier, SVGs naturally act like they have object-fit: contain. There's also an attribute that functions similarly to object-position: the preserveAspectRatio property.

By default, it's set to preserveAspectRatio="xMidYMid", which centers the artboard. But you can change this setting to mimic other object-fit behaviors. For example, to replicate 'object-fit: right top', you would use preserveAspectRatio="xMaxYMin". Remember, only one of these positioning rules will be applied due to the 'contain' behavior.

SVG Symbols

When we think of the viewBox in SVGs as an artboard, SVG symbols are quite similar to components in design tools like Figma. Essentially, a symbol is like a small artboard within itself, which can be inserted (multiple times) within another SVG. Each symbol comes with its own viewBox and preserveAspectRatio attributes, defining the space and boundaries of this mini artboard.

To use an SVG symbol, you first define it with a <symbol> element, giving it a unique id. This symbol acts as a template. You can then place this template anywhere in your SVG with the <use> element, which references the symbol's id.

<svg viewBox="0 0 300 400" xmlns="http://www.w3.org/2000/svg">
	<defs>
		<symbol id="symbol" width="20" height="30" viewBox="0 0 20 30" >
		...
		</symbol>
	</defs>
        <!-- `href` equivalent to the `id` on the symbol -->
	<use href="#symbol" x="0" y="0" width="20" height="30" />
</svg>

Building a Responsive SVG

Before we put together our final SVG, let's start with the swirl element, which we'll later use as a symbol.

I began by creating an artboard with a width of 21 and a height of 25, where I drew the swirl as a path. I set the path width to 2 and chose to have round start and end points for a smooth appearance. To ensure symmetry, I positioned the start and end points of the curve such that their x-coordinates are both at 16.

The SVG code you get after exporting your design can vary depending on the graphic tool you use. Here's what the code looked like when I exported my swirl design from Figma:

<svg width="21" height="25" viewBox="0 0 21 25" fill="none" xmlns="http://www.w3.org/2000/svg">
	<g clip-path="url(#clip0_34_935)">
		<path d="M16 21.5C16 19.25 16 18.6 16 15C16 7 11.75 3 7.5 3C3.2503 3 2 6.5 2 8C2 9.5 3.2503 13 7.5 13C10.5 13 16 12 16 2V0" stroke="#FF0099" stroke-width="2" stroke-linecap="round"/>
	</g>
	<defs>
		<clipPath id="clip0_34_935">
			<rect width="21" height="25" fill="white"/>
		</clipPath>
	</defs>
</svg>

There’s a lot of unnecessary stuff in there. Ultimately, we only need the path that defines the swirl.

I frequently rely on SVG OMG by Jake Archibald to optimize my SVGs. However, Figma often includes a clipPath, which, for our little demo at least, is not needed. Unfortunately, SVG OMG doesn't remove it, so in the end, I manually removed everything except the path tag.

<svg width="21" height="25" viewBox="0 0 21 25" fill="none" xmlns="http://www.w3.org/2000/svg">
	<path d="..." stroke="#FF0099" stroke-width="2" stroke-linecap="round"/>
</svg>

<svg width="21" height="25" viewBox="0 0 21 25" fill="none" xmlns="http://www.w3.org/2000/svg">
	<path d="M16 21.5C16 19.25 16 18.6 16 15C16 7 11.75 3 7.5 3C3.2503 3 2 6.5 2 8C2 9.5 3.2503 13 7.5 13C10.5 13 16 12 16 2V0" stroke="#FF0099" stroke-width="2" stroke-linecap="round"/>
</svg>

With our swirl asset prepared, we're ready to construct the actual SVG. Let's set a width of 21 (the same width that is used for the swirl) and initially a height of 80 for this SVG. As we discussed earlier, we'll omit the viewBox attribute.

In our SVG, we'll define the swirl as a symbol within a <defs> tag. To create this symbol, we can use most of the code from the swirl SVG we created.

The main changes involve replacing the <svg> tag with a <symbol> tag and removing the xmlns attribute, as it's not necessary for symbols. What we do need is an id so it can be referenced within a use tag.

Moving it into <defs> as a <symbol> will prevent the path from being visible in the content.

<svg width="21" height="80" fill="none" xmlns="http://www.w3.org/2000/svg">
	<defs>
		<symbol id="swirl" width="21" height="25" viewBox="0 0 21 25" fill="none">
			<path d="..." stroke="#FF0099" stroke-width="2" stroke-linecap="round"/>
		</symbol>
	</defs>
</svg>

To make the swirl path visible, we must insert a <use> tag that references this symbol. This is where the preserveAspectRatio attribute comes into play. We want our swirl to always align at the bottom of the SVG, so we'll apply preserveAspectRatio="xMidYMax" to the symbol. This ensures that the swirl is anchored to the middle bottom of the SVG.

Additionally, by setting the symbol's height to 100% via the reference within <use>, we ensure that it always matches the height of the SVG, adapting fluidly to any changes in the SVG's size.

<svg width="21" height="80" fill="none" xmlns="http://www.w3.org/2000/svg">
	<defs>
		<symbol id="swirl-1" width="21" height="25" viewBox="0 0 21 25" preserveAspectRatio="xMidYMax" fill="none">
			<path d="M16 21.5C16 19.25 16 18.6 16 15C16 7 11.75 3 7.5 3C3.2503 3 2 6.5 2 8C2 9.5 3.2503 13 7.5 13C10.5 13 16 12 16 2V0" stroke="#FF0099" stroke-width="2" stroke-linecap="round"/>
		</symbol>
	</defs>
	<use href="#swirl-1" x="0" y="0" width="21" height="100%" />
</svg>

Now we have an SVG where the swirl is always positioned at the bottom, regardless of any height changes made through CSS.

Next, let's add the long vertical line, which in the Threads App is the part with a dynamically calculated height. To do this, we'll insert a rectangle that extends from the top to the bottom of the SVG. This is easily achieved by setting the rectangle's height to 100%.

<svg width="21" height="80" fill="none" xmlns="http://www.w3.org/2000/svg">
	<defs>
		<symbol id="swirl-2" width="21" height="25" viewBox="0 0 21 25" preserveAspectRatio="xMidYMax" fill="none">
			<path d="M16 21.5C16 19.25 16 18.6 16 15C16 7 11.75 3 7.5 3C3.2503 3 2 6.5 2 8C2 9.5 3.2503 13 7.5 13C10.5 13 16 12 16 2V0" stroke="#FF0099" stroke-width="2" stroke-linecap="round"/>
		</symbol>
	</defs>
	<use href="#swirl-2" x="0" y="0" width="21" height="100%" />
	<rect x="15" y="0" width="2" height="100%" rx="1" fill="#f09" />
</svg>

However, we don't actually want our rectangle to extend the full 100% height of the SVG. Ideally, it should stop just where the swirl begins.

In SVG, you cannot define coordinates starting from the bottom, but we can cleverly use CSS to achieve the desired effect. By setting the rectangle's height to 100% - 24px, we ensure that it reaches just above the swirl. This adjustment can be made directly within the SVG's code.

<svg width="21" height="80" fill="none" xmlns="http://www.w3.org/2000/svg">
	<style>
		#swirl-4-rect {
			height: calc(100% - 24px);
		}
	</style>
	<defs>
		<symbol id="swirl-4" width="21" height="25" viewBox="0 0 21 25" preserveAspectRatio="xMidYMax" fill="none">
			<path d="M16 21.5C16 19.25 16 18.6 16 15C16 7 11.75 3 7.5 3C3.2503 3 2 6.5 2 8C2 9.5 3.2503 13 7.5 13C10.5 13 16 12 16 2V0" stroke="#FF0099" stroke-width="2" stroke-linecap="round"/>
		</symbol>
	</defs>
	<use href="#swirl-4" x="0" y="0" width="21" height="100%" />
	<rect id="swirl-4-rect" x="15" y="0" width="2" height="100%" rx="1" fill="#f09" />
</svg>

And there you have it! We've successfully created a responsive SVG that adjusts its size while always keeping the swirl loop at the bottom, ensuring it doesn't get distorted.

Using responsive SVGs

Now, you might wonder, how do we actually use the swirl-line in our code? You have a few options.

Inline SVG

One of the simplest methods is to use it as an inline SVG. This approach allows you to define the symbol just once at the beginning of your document, rather than repeating it multiple times. Additionally, the style definition for the SVG can be included in your regular CSS stylesheet. It's probably best to apply these styles using a specific class, to avoid affecting all rectangle elements globally.

Using an image tag

You can also save the code as an SVG file and then use an image tag. Please note that for this approach, you have to delete the width and height attributes from the SVG and instead apply them to the <img> Tag.

CSS in SVG in CSS 🤯

Perhaps the most thrilling option available is embedding the SVG directly in our CSS as a data URI background-image.

For this, I recommend a fantastic tool by @yoksel, which you can find at https://yoksel.github.io/url-encoder/. This tool allows you to simply copy and paste any SVG and generates a ready-to-use code snippet for your stylesheet. You can then, for example, use a pseudo-element and apply the background image.

This process essentially embeds CSS within an SVG, which is then itself embedded within your CSS file. Isn't that mind-blowing?

Putting it all together

Check out this CodePen, where you'll find all three examples demonstrated. While I don't have a strong preference for any particular solution, I'm somewhat partial to the last option. The reason is, that it allows for the creation of the swirl without the need for an additional DOM element, which I find quite efficient and elegant.

See the CodePen.

Understanding SVG Coordinate Systems and Transformations by Sara Soueidan
Understand the SVG Viewbox by Paul Ryan
viewBox on mdn web docs
<symbol> on mdn web docs

Nils selected Queermentor for an honorary donation of $50

Queermentor is committed to promoting equity by providing free mentoring, training, and networking opportunities for queer individuals. They also serve as a resource for companies looking to make a positive impact on the LGBTQIA+ community through their work.

FileReader API

2023-12-22T00:00:00.000Z

Ever wonder how websites claim to interpret an uploaded file without storing any of your data? Admittedly, I used to be a bit skeptical myself. Enter the FileReader API! It allows a client-side application to asynchronously read and interpret an uploaded file.

In order to do this in your own client-side application, you'll also want to learn about the File API and/or the Blob API. These are the objects that you'll read with the FileReader API. You can also use the FileReader API to analyze files from a drag-and-drop operation.

Although this API has been around for a while (Chrome started supporting it in version 6), parts of the modern usage haven't been supported as long, such as the File API (shipped in Chrome 13) and the File() constructor (shipped in Chrome 38).

In an almost ironic move, to test this API locally, you must serve the JavaScript from a secure domain (HTTPS), which can be done with several local tools or something like Codepen.

The Basics

The FileReader API, in basic usage, can be used in conjunction with <input type="file" />. Once a file is either selected through the file browser or dragged and dropped onto the file field, a new File object is created on the input element.

FileReader can be used with any File object, but we’ll explore a basic usage scenario.

Let's try to pass the File object to the FileReader API like so:

function readFile(file) {
    const fileReader = new FileReader();
    fileReader.readAsText(file);
}

The above sample is not quite complete, however. The FileReader API is asynchronous by default and does not use promises. Instead, there are several events you can listen to.

For now, let's focus on the following:

load, which is fired when the file is loaded successfully
error, which is fired when the file failed to be read

function readFile() {
    const fileReader = new FileReader();
    const resultContainer = document.getElementById('result');
    const file = document.getElementById(‘uploaded-file’).files[0];

    if (file) {
        fileReader.readAsText(file);
    }
    
    fileReader.addEventListener('load', () => {
        resultContainer.innerText = fileReader.result
    }, { once: true })
}

Notice in the above example that we’re setting the text of the resultContainer to the result that the FileReader got once it fired the load event.

result on the fileReader object is exactly what you'd expect: whatever the FileReader read from the file is contained in the result property.

While it's not able to read every type of file's contents, the following methods are available for FileReader:

readAsText()
readAsDataURL()
readAsArrayBuffer()

I'll go through the first two in this article but know that this is a powerful API for a wide variety of applications.

Method: readAsText()

First up is the very basic text method FileReader API allows us to use. You'll want only to use this method for smaller files, as it reads the entire file into memory. For larger files, you'll want to use readAsArrayBuffer(), as it returns a promise and is more predictable with larger files.

In the example above, we take the file we give readFile() and log the result of the readAsText method. This can be very useful if we want to interpret any kind of text-based file, such as .txt, .csv, etc.

See the CodePen.

Method: readAsDataURL()

This method can be used for reading images, similar to how you'd interact with images if they were data-url strings. That is exactly what this method does: returns the image as a base64 encoded data-url.

Note: It is readAsDataURL - with URL all uppercase - not readAsDataUrl. Using the latter will cause an error - it is case-sensitive.

Let's take the example below:

<!-- Don't forget to write HTML semantically! -->
<label>
    <input type="file" id="uploaded-file" onchange="readImage()" name="uploaded-file" accept="image/*">
    Upload an image.
</label>
<div id="result"></div>

Notice I am using the accept attribute to limit the uploaded file to a MIME-type that is a type of image. Review how to specify file types to be accepted on MDN.

function readImage() {
    const fileReader = new FileReader();
    const file = document.getElementById("uploaded-file").files[0];
    
    if (file) {
        fileReader.readAsDataUrl(file);
    }

    fileReader.addEventListener('load', () => {
        const result = fileReader.result;
        const resultContainer = document.getElementById("result");
        const img = document.createElement("img");
        img.src = result;
        resultContainer.append(img);
    }, { once: true })
}

In the above example, we're:

creating a FileReader
then listening for when the load event happens (meaning the file reading session was successful)
then creating an <img> element and putting the image into the src attribute as a data-url
finally, appending the created img to the <div> container we created for the images

See the CodePen.

This API is great for simplistic things like in-browser manipulation or even real-time status updates while uploading the image / text / whatever the file might be to the backend server. Updating your profile picture on a major social network? You could replicate that with the FileReader API.

FileReader Events

There are several other events on the FileReader that are good to know.

abort - a file read has been aborted (canceled)
progress - fired periodically during a read
loadstart / loadend - can be used to trigger something at the beginning or the end of the loading of the file

The events are extended from the ProgressEvent interface. By listening to the progress event on FileReader, you can calculate file read progress by dividing the loaded by the total properties on the ProgressEvent.

fileReader.addEventListener("progress", (event) => {
  const progress = (event.loaded / event.total) * 100;
  console.log(`Read progress: ${progress}%`);
});

Scroll-driven Animations

2023-12-21T00:00:00.000Z

One thing many fancy, award-winning websites have in common is they contain animations triggered by scrolling. Whether it’s a parallax effect, a progress bar animation, elements animating into view, or a full scrollytelling experience, on-scroll effects celebrate the medium of the web, clearly differentiating it from print. Indicating the progress of scroll can also be helpful to users.

Up until now, JavaScript has been a requirement for building scroll-driven animations. But the new Scroll-driven Animations specification enables us to link the progress of an animation to the progress of scroll, all with just CSS. It’s a Christmas miracle!

Simple use: Animated progress indicator

At its simplest, the animation-timeline property lets us link any keyframe animation to the progress of scroll. For the first demo, let’s create a festive progress indicator by sliding Santa on his sleigh from the left to the right of the screen.

First, we’ll create the keyframe animation. We’ll use a calc function so that Santa moves to the end of the viewport but not beyond:

@keyframes slide {
    from { transform: translateX(0); }
    to { transform: translateX(calc(100vw - 100%)); }
}

Let’s write some CSS to position an <img> element with a class of santa at the bottom of the page.

.santa {
  position: fixed;
  bottom: calc(100vh - 100%);
  left: 0;
}

We can apply the animation to our element using animation-timeline, with the scroll() function:

.santa {
  /* ... */
  animation-name: slide;
  animation-timeline: scroll();
}

By default, the scroll() function will link the animation to the nearest scroll container. For a progress indicator, we’d probably want to make sure our animation is linked to the root scroll container so that the progress bar reflects the user’s progress through the article. We can specify this in the scroll() function.

.santa {
  animation-name: slide;
  /* Update: link to `root` scroll container */
  animation-timeline: scroll(root);
}

In addition, we can specify the block or inline access for our scroll animation to respond to. The default is block, but if we wanted it to respond to the inline axis this is how we’d do it:

.santa {
  animation-name: slide;
  /* Optional: switch to `inline` axis */
  animation-timeline: scroll(root inline);
}

If we scroll the page, we should see Santa slide from left to right as we go.

But right now, the animation doesn’t exactly match the rate of scrolling: at some points, it’s faster than others.

The default value for animation-timing-function is ease, meaning animations will start slowly, speed up in the middle, and slow down towards the end.

We can set a value of linear to ensure the progress of our animation matches the progress of scroll.

.santa {
  animation-name: slide;
  /* Added timing function */
  animation-timing-function: linear;
  animation-timeline: scroll(root);
}

We can simplify this with the animation shorthand.

.santa {
  /* Update to use `animation` shorthand */
  animation: slide linear;
  animation-timeline: scroll(root);
}

See the CodePen.

Parallax images

How about something a little more exciting than a progress bar?

We can use exactly the same technique to add a parallax effect to a web page. This keyframe animation translates an element on the y-axis. We can use a custom property (--translate) to make it easy to adjust the amount our image moves.

:root {
  --translate: 200px;
}

@keyframes parallax {
  from { transform: translateY(calc(var(--translate) * -1)); }
  to { transform: translateY(var(--translate)); }
}

Here we will use the prefers-reduced-motion media query to ensure that users who have indicated a preference for reduced motion at the system level will see the regular static images.

:root {
  --translate: 200px;
}

/* Position <img> element */
.recessed-image {
  position: absolute;
  width: 100%;
  height: 100%;
  inset: 0;
  object-fit: cover;
}

/* Animation styles only applied for users with no preference for reduced motion */
@media (prefers-reduced-motion: no-preference) {
  .recessed-image {
    height: calc(100% + var(--translate));
    animation: parallax linear;
    animation-timeline: scroll(root);
  }
}

You can see the parallax effect in action in the demo. As we scroll the page, the hero image appears to move at a slower rate than the text content, giving it a three-dimensional feel. As a bonus, we’re also applying a parallax effect to the other images in the article, by translating them in the opposite direction.

See the CodePen.

Multi-layer parallax

We can extend this parallax effect further and create multi-layered backgrounds that respond to scroll!

Let's position three elements on top of each other at the top of our page.

/* Setting a minimum height ensures our page is scrollable! */
body {
  min-height: 300vh;
}

/* Position the three backgrounds */
.background,
.mid,
.foreground {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100vh;
}

We’ll set a custom property for each one. We want the elements in the foreground to move the most and the ones in the background to move the least, so we’ll give the foreground element the highest value and the background the lowest:

.background {
  --translate: 100px;
}

.mid {
  --translate: 250px;
}

.foreground {
  --translate: 500px;
}

Now, we can apply the animation to our elements like in the previous example.

@media (prefers-reduced-motion: no-preference) {
  .background,
  .mid,
  .foreground {
    height: calc(100% + var(--translate));
    animation: parallax linear;
    animation-timeline: scroll(root);
  }
}

@keyframes parallax {
  from { transform: translateY(calc(var(--translate) * -1)); }
  to { transform: 0; }
}

The custom properties ensure each layer moves at a different rate, giving our page the illusion of depth.

See the CodePen.

Non-ancestor scroll containers

If we want to link an animation to the scroll progress of a non-ancestor element, we’ll need a couple of new properties:

scroll-timeline (shorthand for scroll-timeline-name and scroll-timeline-axis) is defined on the scroll container. Here, we specify a timeline name using custom property syntax and the inline or block axis (the default is block).

.scroll-container {
  overflow-y: scroll;
  scroll-timeline: --progress block;
}

Let’s adjust the example in the previous demo so that the parallax background animation is tied to the progress of a fixed scroll container, which is not an ancestor of the elements we’re animating. Instead of using the scroll() function for animation-timeline, we need to use the name of our timeline:

.background,
.mid,
.foreground {
  animation: parallax linear;
  animation-timeline: --progress;
}

Finally, we must set the timeline-scope property on a common ancestor of our scroll container and the elements we’re animating. In this case, we can use the <body>:

body {
  timeline-scope: --progress;
}

Now, scrolling the fixed scroll container triggers the animation.

See the CodePen.

Browser support

Scroll-driven animations are currently only supported in Chromium, so you’ll need to ensure you provide fallbacks for users whose browsers don’t yet support them. Consider using feature queries to only deliver animation-dependent styles to supporting browsers:

@media (prefers-reduced-motion: no-preference) {
  @supports (animation-timeline: scroll()) {
    .recessed-image {
      height: calc(100% + var(--translate));
      animation: parallax linear;
      animation-timeline: scroll();
    }
  }
}

View progress timelines

Also, as part of the Scroll-driven Animations specification, view progress timelines enable us to link an animation to the progress of an element through the scrollport. This means we can trigger animations when elements enter and exit the viewport.

In the case of our second demo, where we’re animating images throughout the page, it might be more desirable to link the animations to the progress through the viewport rather than the scroll position of the entire page.

To create an anonymous view progress timeline, we can simply use the view() function in place of the scroll() function:

.some-element {
  animation: appear linear;
  animation-timeline: view();
}

@keyframes appear {
  0% { 
    opacity: 0;
    transform: translateY(100px);
  }
  100% { 
    opacity: 1;
    transform: translateY(0);
  }
}

See the CodePen.

We can also specify an animation-range to control when the animation should start and end in relation to its position in the scrollport.

For example, if we want to specify that an element should begin its animation as soon as it begins to enter the viewport and complete the animation once the entire element is in view, we can declare the animation range like this:

.content {
  animation: appear linear;
  animation-range: entry 0% entry 100%;
  animation-timeline: view();
}

As with scroll progress timelines, it’s also possible to create a named view progress timeline using the view-timeline property.

Resources

Discover more about scroll-driven animations!

Scroll-driven Animations specification
Bramus CSS Day talk (video) by Bramus Van Damme
Introduction to scroll-driven animations by Bramus Van Damme
Scroll progress animations in CSS by Michelle Barker

Michelle selected Unicef UK for an honorary donation of $50

The UK Committee for UNICEF (UNICEF UK) raises funds for UNICEF’s emergency and development work for children. We also promote and protect children’s rights in the UK and internationally. We are a UK charity, entirely funded by supporters.

CSS Nesting

2023-12-20T00:00:00.000Z

CSS Nesting is a new syntax for CSS that lets you nest selectors inside of other selectors, where every nested selector is relative to their parent.

In its simplest form, it looks like this:

.card {
  border: 2px solid red;
  padding: 1rem;
   
  .card-title {  
    font-family: Jolly;
    font-size: 3rem;
  }
}

A browser will take the style for an element with the class card-title and apply it only if that element is nested inside an element with the class card. In other words, a browser will interpret it like this:

.card {
  border: 2px solid red;
  padding: 1rem;
}

.card .card-title {  
  font-family: Jolly;
  font-size: 3rem;
}

Benefits of Native CSS Nesting

Now some relevant implementation details complicate things that we'll get to later (this is the web, after all!), but this example is enough to go over the benefits that CSS nesting brings:

Less typing

In the "interpreted" version above, you can see that the browser duplicated .card for us, but in our source, we only had to write it once. By nesting selectors, you no longer have to repeat a part of your selector if you want to prevent your styles from applying too broadly. In addition, less typing also means your files end up being smaller, and, therefore faster to download.

Easier scoping

That also means that it's easier to scope. If you're working on a card, you only have to write that .card selector once and nest all the relevant CSS inside it. That means you'll need to write less specific selectors since they're already scoped to their parent. This also makes your code much more portable, as you don't have to go through your CSS to find all the styles that apply to the card but can take .card and everything in it instead.

Your CSS follows the DOM

A benefit of this is that your CSS starts to mimic your DOM. In the above example, card-title is nested both in the CSS as well as in the DOM. When your CSS mimics your DOM, it's much easier to reason about, and easier to understand what effects your changes will have. If you've ever worked on a large CSS codebase, you know how dangerous deleting CSS can be even if you think you no longer use it.

When your CSS follows your HTML structure, you're able to delete things with much more confidence. For example, when you remove the card-footer from your card HTML, you know that your .card-footer CSS can only apply to that part of your site, so you can remove it from the CSS as well.

Nesting Complexities

Now that you know what makes CSS Nesting so useful, let's explore some of the complexities.

Versions

At this point, we need to point out that there are currently two versions of CSS nesting: the strict version, which is what Chromium up to 119 and Safari up to 17.1 implement, and the "relaxed" version, which is what Firefox shipped with and is now available in Safari 17.2 and Chromium 120.

The difference between them lies in how they deal with nesting element selectors (like p, div). The strict version allows for any selector that begins with a non-letter to be nested without the "nesting selector", the &. That means that instead of this:

.card {
  border: 2px solid red;
  padding: 1rem;
   
  h3 {  
    font-family: Jolly;
    font-size: 3rem;
  }
}

You have to write this:

.card {
  border: 2px solid red;
  padding: 1rem;
   
  & h3 {  
   font-family: Jolly;
   font-size: 3rem;
  }
}

Or your h3 style won't be applied. The reason for this is that properties (like margin) also start with a letter so the browser's CSS engine wouldn't know if you were adding a new property or a new nesting selector.

Browsers found a way around that, so the relaxed version allows you to nest element selectors without the &, making everything a lot simpler. By the time you read this article, Chromium 120 and Safari 17.2 will have been released, so all browsers now support the relaxed version.

I would suggest you keep using the strict version, though, since that will keep working across all browsers.

The nesting selector and how nesting gets resolved by the browser

So, does that mean you don't need the nesting selector anymore? For simple nesting no. But the nesting selector lets you control how nesting should happen. To understand how it does that, you need to know three things:

If a nested selector doesn't have an &, it gets one added to the front of it (with a space) implicitly
The "&" is replaced with "is(<parent selector>)" in the CSS engine.
You can add an & anywhere in the selector (including multiple times)

Let's go over these in order.

Implicit Nesting selector

Going back to our first example, the nested .card-title doesn't have a nesting selector, so the browser will add one implicitly:

.card {
  border: 2px solid red;
  padding: 1rem;
   
  (implicit '&') .card-title {  
    font-family: Jolly;
    font-size: 3rem;
  }
}

On its own, this doesn't matter a lot, but it's important to keep in mind when you know that the & gets replaced.

Resolved selector

The & gets replaced with "is(<parent selector>)" so the nested selector in the code above ends up not being .card .card-title as we said at the beginning of this article, but as :is(.card) .card-title.

In this example, that doesn't matter a lot because both of them have the same specificity (0,2,0), but if you have comma separated selector as a parent, you could accidentally be making a rule with a very high specificity:

.card,
#xmas-card {
  .card-title { ... }
}

This gets resolved to this: :is(.card, #xmas-card) .card-title which has a specificity of (1,1,0), because the :is() pseudo selector will get the specificity of the most specific item, in this case, the id. And that's also the case if your .card-title isn't in the #xmas-card at all but in a regular .card.

This can get even trickier if you realize that the :is() selectors also get nested. Let's go over how this works with the following three-levels-deep nesting:

.card {
  .card-body {  
    p { ... }
  }
}

First, the "p" is implicit & p.
That gets replaced with the parent, which for convenience, we'll also add the & to, creating :is(& .card-body) p.
Then lastly, we also fill in the "&" there, replacing it with :is(.card) resulting in :is(:is(.card) .card-body) p which is what your browser ends up using.

Adding an & selector

You can be explicit in how you nest by adding the & selector. I personally think this is more readable, but beyond that, it can also affect how your nesting works. That's because the space is also a type of selector: the descendant selector. And so, whether or not you add a space after your & can make a difference.

The following code will apply when you hover the card:

.card {
  &:hover { ... }
}

That is because it resolves to :is(.card):hover.

The following code will do something different:

.card {
  & :hover { ... }
}

Because of the space, the :hover part is now targeting descendants of cards and so acts like :is(.card) *:hover. Pseudo-classes like :hover get an implicit * (universal element selector) before them. So keep that space in mind.

By adding an explicit & selector somewhere else in the selector, you can target different parts of your nesting. For example, to style cards but only if they're in a list, you could do this:

.list {
   .card { ... }
}

The downside is that all the styling of your card components would also have .list as a parent selector, making it more specific and less modular.

Instead, you could write this:

.card {
   .list & { ... }
}

This way, all your other card styling could be scoped to the card, and the extra styling when your card is in a list would be included with it, keeping everything nice and modular.

Adding multiple selectors is useful if you want to style elements in a sequence. For example, to add margin to each card except the first when they're in a list:

.card {
  .list & + & {  
    margin-top: 1rem;
  }
}

This resolves to .list :is(.card) + :is(.card), or written more simply, .list .card + .card.

Nesting At-rules

A very useful part of CSS Nesting is that you can also nest at-rules like @media, @supports, and friends.

Instead of writing this:

.card {
  max-width:100%;
}

@media (min-width: 50rem) {
  .card {
    max-width: 40rem
  }
}

You can nest that media query:

.card {
   max-width:100%;

  @media (min-width: 50rem) {
    max-width: 40rem
  }
}

Notice how we don’t have to repeat .card and that we can use the CSS declarations directly in the media query because the browser implicitly reads it as this:

.card {
  @media (min-width: 50rem) {
    & {
      max-width: 40rem
    }
  }
}

And as we learned previously, that & is then replaced with :is(.card).

Things to watch out for when nesting

Back when I first used Sass, I went wild with nesting, sometimes nesting 20 levels deep. It’s very tempting just to keep going as you build out your styling. But each nesting level also increases the specificity of your selector, making it harder to edit later (not to mention the indenting!).

A simple rule of thumb is to see if you can break out into a new set of nesting when you reach 3 or 4 levels deep. This makes your selectors easy to reason about, and there is probably a logical break for your component and its sub-components. There are multiple other strategies to deal with this, such as keeping empty parent selectors and splitting between layout and style. I explore these strategies in CSS Nesting, specificity and you.

Another tricky part is that because nesting gets resolved to un-nested code, the order you write CSS in might not be the order your CSS gets applied. I wrote about this in “The gotchas of CSS Nesting”. The short of it is: You can nest at-rules before applying regular properties, like so:

body { 
  @media all {
    background: red;
  }
    
  background: blue;
}

If you follow your CSS order, the background would be blue, because at-rules add no specificity and background: blue comes last.

Once the browser finishes computing CSS values, it ends up applying the rules like this and moving the media query last:

body {
  background: blue;
}

@media all {	
  :is(body) {
    background: red;
  }
}

Now background: red is last, which ends up being the applied background color.

The best way to deal with this, and to keep your code easy to reason about is to only nest after all the regular properties and not to mingle them even though it's allowed by the nesting syntax.

That’s CSS Nesting

Nesting is available in all browsers, though you’ll want to keep using the strict notation to keep the widest compatibility.

Nesting helps you keep your CSS smaller, easier to reason about, and more closely follow the DOM that you’re styling. When using Nesting, try not to nest too deeply, and keep in mind that your CSS needs to be resolved, which can change both the order and the selectors your browser ends up using.

If you want to learn more about nesting, here are some additional resources:

Kilian selected Giving Green Fund for an honorary donation of $50

View Transitions

2023-12-19T00:00:00.000Z

Web applications these days are becoming more complex thus, having smooth transitions between view states as a form of functional animation has the practical benefit of reducing cognitive load, preventing change blindness, and establishing better recall in spatial relationships.

Trying to animate between different DOM states used to involve a serious amount of Javascript and CSS because of the number of factors we had to take care of. In addition to the animations themselves, we also had to worry about handling the loading and rendering of content within the different states and potential accessibility issues.

The View Transitions API was proposed in the CSS working group back in 2021 to allow transition animations when navigating between different application views. A lot of work has gone into this, and the specification is now at Candidate Recommendation status.

How does it work?

Generally, if we want to animate something smoothly, it must have a start state and an end state, then we have to figure out how to fill in the gap between the two states in a gradual manner. As an oversimplification, CSS transitions and animations today generally work because the browser can compute the values of the in-between states of an element.

If we want multiple DOM nodes to participate in the same animation, things become very tricky because the computation required increases significantly. The proposed solution is to handle the complicated in-between state in a separate layer altogether with the help of pseudo-elements.

The visual transition is done using a static visual capture of the original state and a live capture of the new state, represented as a tree of pseudo-elements.

::view-transition
├─ ::view-transition-group(name)
│  └─ ::view-transition-image-pair(name)
│     ├─ ::view-transition-old(name)
│     └─ ::view-transition-new(name)
└─ …other groups…

It all starts with the startViewTransition() method, which returns a ViewTransition object when called. The state at this point is captured as the “old” state, and rendering is paused.

The startViewTransition() takes a callback function as an argument, called asynchronously once the old state has been captured. Once the promise is fulfilled, the new state of the document is captured as the “new” state, and now we have the two states necessary for a smooth transition to happen.

What’s particularly interesting about how this feature is implemented is that “a failure to create a visual transition, which can happen due to misconfiguration or device constraints, will not prevent the developer’s UpdateCallback being called.”

As previously mentioned, the startViewTransition() method takes a callback function as an argument, and this function will always be called even if the animation does not happen due to reasons. I think the idea is pretty smart, and I highly suggest reading the specification because it’s a very readable explanation of the details.

View Transition API in action

These days, a common pattern we see on the web is data that gets populated after the page has loaded. It could be a user interaction that triggers a change in the content with new content that hadn’t existed in the DOM previously. We can animate such a content change using the View Transitions API.

For our example, we'll build an image gallery and have a scenario where clicking on a thumbnail will populate the main display with a larger version of the image.

The basic markup for the display looks something like this:

<figure>
  <img class="main-image" src="https://i.imgur.com/j6tUehw.jpg" alt="Mamamoo World Tour MYCON">
  <figcaption class="image-heading"></figcaption>
</figure>

Our list of thumbnails looks like this:

<ul class="thumbnails">
  <li>
    <a href="#">
      <img class="thumbnail" src="..." alt="Solar">
    </a>
  </li>
  <!-- additional list items -->
</ul>

Let’s start off with our callback function (to be passed to the startViewTransition() method):

const mainImage = document.querySelector("figure img");

const displayNewImage = () => {
  mainImage.src = clickTarget.src;
};

Because this is just a demo, this function sets the main image source to the thumbnail that was clicked. In an ideal situation, we would have wanted to have optimized different images because of performance but let’s live with this for now.

As not every browser currently supports the View Transitions API, we need to include a check for support. The code for the checking View Transition support looks like this:

if (!document.startViewTransition) {
  displayNewImage();
  return;
}

const transition = document.startViewTransition(() => displayNewImage());

The default ViewTransition is a cross-fade effect, where the old view animates from opacity: 1 to opacity: 0, and the new view animates from opacity: 0 to opacity: 1. The browser does this out-of-the-box as the default animation. If this effect is sufficient, no additional CSS is necessary.

See the CodePen.

The entire page is involved in the transition for this most basic implementation. But we can also target specific elements to be animated separately from the rest of the page by assigning a view-transition-name to the element.

We can try something more than a simple cross-fade. Let’s make it seem like the image is growing out from each respective thumbnail when the thumbnail is clicked on with the help of some additional CSS on the view transition pseudo-elements.

::view-transition-old(main-image),
::view-transition-new(main-image) {
  transform-origin: 100% var(--originY, 50%);
}

::view-transition-new(main-image) {
  animation: 400ms ease-out both grow;
}

figure {
  view-transition-name: main-image;
}

@keyframes grow {
  from {
    transform: scale(0);
  }
  to {
    transform: scale(1);
  }
}

We need to update the markup and Javascript a little update the transform-origin property value when the thumbnails are clicked. Let’s add a data-index attribute to each thumbnail, which can be used to calculate the updated value so the main display image starts animating from the position of each thumbnail.

<ul class="thumbnails">
  <li>
    <a href="#">
      <img class="thumbnail" src="..." alt="Solar" data-index="0">
    </a>
  </li>
  <!-- additional list items -->
</ul>

And update the Javascript to modify the --originY custom property value that controls the transform-origin of the scale transformation along the y-axis.

const displayNewImage = () => {
  mainImage.src = clickTarget.src;
  document.documentElement.style.setProperty(
    "--originY",
    clickTarget.dataset.index * 25 + 12.5 + "%"
  );
};

The end result of all that looks like this:

See the CodePen.

We can target other elements to be animated separately by giving them their own view-transition-name value. The view-transition-name can be anything at all, but it needs to be unique and cannot be none, as that would result in no transition at all.

Maybe we want an image header to go with the main display. Again, for demo purposes, I’m just going to use the alt text from the thumbnail, but the content could come from somewhere else. The point is the content is changing. Let’s update the displayNewImage callback:

const displayNewImage = () => {
  mainImage.src = clickTarget.src;
  imageHeading.innerHTML = clickTarget.alt;
  document.documentElement.style.setProperty(
    "--originY",
    clickTarget.dataset.index * 25 + 12.5 + "%"
  );
};

The animation is currently on the <figure> element, which contains the <figcaption> element where the text is displayed, so the scale effect will include the <figcaption>. But the View Transitions API allows us to separate the <figcaption> animation from the <figure>, and to me, that’s a huge plus.

Once a view-transition-name is assigned to the <figcaption>, it will now cross-fade when the <figure> scales. You can also customize the animation for the <figcaption> with CSS. There are so many possibilities!

See the CodePen.

Can we use it today?

As it was put forth by the folks at Google, Chromium has had a working implementation of the View Transitions API since version 111. Both Firefox and Webkit are currently working on their implementation of this feature, tracked in Bug 1823896 on Firefox Bugzilla and Bug 259055 on Webkit Bugzilla, respectively.

Wrapping up

Hopefully, this post manages to highlight the potential of View Transitions and inspires you to explore more and give it a try yourself.

References

Chen selected Red Panda Network for an honorary donation of $50

Red Panda Network is committed to the conservation of wild red pandas and their habitat through the education and empowerment of local communities.

New JS Array Methods

2023-12-18T00:00:00.000Z

Let’s learn what these Array methods do and how they work!

Creating a reversed copy with the Array.prototype.toReversed() method

Let's say you have an array of wizards.

let wizards = ['Merlin', 'Ursula', 'Gandalf'];

The Array.prototype.reverse() method modifies the original array.

wizards.reverse();

// logs ["Gandalf", "Ursula", "Merlin"]
console.log(wizards);

Historically, if you wanted to create a reversed copy of the array instead of modifying the original, you would have to clone it first, then reverse it.

let reverseWizards = Array.from(wizards).reverse();

// logs ["Gandalf", "Ursula", "Merlin"]
console.log(reverseWizards);

// logs ["Merlin", "Ursula", "Gandalf"]
console.log(wizards);

The new Array.prototype.toReversed() method simplifies that into a single step.

let reverseWizards = wizards.toReversed();

// logs ["Gandalf", "Ursula", "Merlin"]
console.log(reverseWizards);

// logs ["Merlin", "Ursula", "Gandalf"]
console.log(wizards);

Here's a demo of the Array.prototype.toReversed() method.

Creating a spliced copy of an array with the Array.prototype.toSpliced() method

The Array.prototype.splice() method is used to add, remove, and replace items in an array.

When using the method, the original array is modified.

The first argument is the index of the item you want to modify in the array and is the only required argument. The second argument is the number of items to delete from the array. It can be a number from 0 through the length of the array.

If you omit the second argument, the Array.prototype.splice() method will delete every item in the array from the start index on.

let wizards = ['Merlin', 'Ursula', 'Gandalf', 'Radagast'];

// This removes 1 item at index 2: "Gandalf"
// wizards is now ["Merlin", "Ursula", "Radagast"]
wizards.splice(2, 1);

Historically, if you want to keep the original array intact, you would clone it first, then splice() it.

let fewerWizards = Array.from(wizards).splice(2, 1);

The new Array.prototype.toSpliced() does the same thing as Array.prototype.splice() but creates a copy instead of modifying the original array.

let wizards = ['Merlin', 'Ursula', 'Gandalf', 'Radagast'];

let lessWizards = wizards.toSpliced(2, 1);

// logs ['Merlin', 'Ursula', 'Gandalf', 'Radagast']
console.log(wizards);

// logs ['Merlin', 'Ursula', 'Radagast']
console.log(lessWizards);

Here's a demo of the Array.prototype.toSpliced() method.

Creating a sorted copy of an array with the Array.prototype.toSorted() method

The Array.prototype.sort() method reorders the items in an array.

It modifies the original array and by default, will order the items alphanumerically.

let wizards = ['Merlin', 'Ursula of the Sea', 'Gandalf the Gray'];

wizards.sort();

// logs ['Gandalf the Gray', 'Merlin', 'Ursula of the Sea']
console.log(wizards);

You can optionally pass in a callback function that will modify the default sorting behavior.

The Array.prototype.sort() method loops through each item and passes two items at a time as arguments into the callback function. You can compare those two items and return an integer telling Array.sort() what to do with them.

If you return -1, it will place the first item before the second one. If you return 1, it will move the second item before the current one. If you return 0 (or nothing at all), it will leave them unchanged.

For example, let’s say we want to sort our wizards array by the length of the wizard’s name, with the longest names first. We could do this:

wizards.sort(function (wizard1, wizard2) {
  // If wizard1 is longer, put it before wizard2
  if (wizard1.length > wizard2.length) {
    return -1;
  }

  // Otherwise, put wizard2 before wizard1
  return 1;
});

// logs ['Ursula of the Sea', 'Gandalf the Gray', 'Merlin']
console.log(wizards);

The Array.prototype.toSorted() method works exactly the same way but creates a copy of the array before sorting it.

let sortedWizards = wizards.toSorted();

// logs ['Merlin', 'Ursula', 'Gandalf', 'Radagast']
console.log(wizards);

// logs ['Gandalf the Gray', 'Merlin', 'Ursula of the Sea']
console.log(sortedWizards);

Here’s a demo of the Array.prototype.toSorted() method.

Creating a copy of an array with a single value updated using the Array.prototype.with() method

To update a value in an array, you can use bracket notation ([]), passing in the index of the value to update.

Remember, array indexes start at 0.

let wizards = ['Merlin', 'Ursula', 'Gandalf'];

// Replaces "Gandalf" with "Radagast"
wizards[2] = 'Radagast';

// logs ['Merlin', 'Ursula', 'Radagast']
console.log(wizards);

The Array.prototype.with() method provides a simple way to copy an array and update one of its values in a single step.

You pass in the index to update and the value to assign to that index as arguments.

let differentWizards = wizards.with(2, 'Radagast');

// logs ['Merlin', 'Ursula', 'Gandalf']
console.log(wizards);

// logs ['Merlin', 'Ursula', 'Radagast']
console.log(differentWizards);

Here’s a demo of the Array.prototype.with() method.

Browser support and polyfills

The new Array methods we looked at today are now supported in all major browsers.

But… they’re relatively new, and not everyone updates their browsers regularly. In particular, browser updates on mobile devices are often tied to updating the entire OS. Someone running an older version of iOS, for example, won’t have support for these methods.

For now, I recommend using a polyfill that you can remove later when browser support gets better.

Polyfills are functions that check if a browser supports a method or API and recreate that method using older approaches if not. Unlike a helper function, they follow the spec for the new method and are designed to be deleted as browser support improves.

Here are polyfills you can use for the methods we discussed in this article.

// Polyfill: Array.prototype.toReversed()
if (!Array.prototype.toReversed) {
  Array.prototype.toReversed = function () {
    return Array.from(this).reverse();
  };
}

// Polyfill: Array.prototype.toSpliced()
if (!Array.prototype.toSpliced) {
  Array.prototype.toSpliced = function (...args) {
    return Array.from(this).splice(...args);
  };
}

// Polyfill: Array.prototype.toSorted()
if (!Array.prototype.toSorted) {
  Array.prototype.toSorted = function (...args) {
    return Array.from(this).sort(...args);
  }
}

// Polyfill: Array.prototype.with()
if (!Array.prototype.with) {
  Array.prototype.with = function (index, value) {
    let clone = Array.from(this);
    clone[index] = value;
    return clone;
  }
}

Wrapping up

We covered a lot in this article, so let’s quickly wrap up what we learned.

toReversed() - creates a reversed copy of an array.
toSpliced() - creates a copy of an array and adds, removes, or replaces one or more items.
toSorted() - creates a copy of an array and sorts the items in.
with() - creates a copy of an array and updates a single value in the array.

Chris selected Feeding America for an honorary donation of $50

Feeding America is the largest charity working to end hunger in the United States. We partner with food banks, food pantries, and local food programs to bring food to people facing hunger. We advocate for policies that create long-term solutions to hunger.

CSS animation-composition

2023-12-17T00:00:00.000Z

MDN describes animation-composition as:

The animation-composition CSS property specifies the composite operation to use when multiple animations affect the same property simultaneously.

Put another way, it gives us the ability to instruct animations to apply property values in ways other than the default behavior. It’s not limited to multiple animations. Animation composition affects all animated properties regardless of whether an element has one or multiple animations applied to it.

There are three possible values for animation-composition: replace, add, and accumulate, where replace is the default.

replace: The effect value overrides the underlying value of the property
add: The effect value builds on the underlying value of the property
accumulate: The effect and underlying values are combined

You apply animation-composition to the same element that has an animation.

.single-animation {
  animation: move 2s infinite;
  animation-composition: accumulate;
}

If you have multiple animations, you can set animation-composition for each using comma-separated values in the same order as the animations.

.multiple-animations {
  animation: move 1s infinite, shake 3s infinite, roll 2s infinite;
  animation-composition: add, accumulate, replace;
}

How it works

Since replace is the default, its behavior is likely what you expect from animations. It’s how animations have always worked up until now.

For example, let’s say we have an element that we’ve moved towards the right with transform: translateX(50px). Then we apply a keyframe animation to it that translates it another 200px on the x-axis, translateX(200px). The element was at 50px and is now at 200px.

If we change the element’s animation-composition to add or accumulate, we change the result of the animation. The element still starts at 50px, but now ends up at 250px on the x-axis because the 200px is added to the initial 50px.

See the CodePen.

What we’re seeing here with add and accumulate is basic math: 50 + 200 = 250. This is a simple example; we’ll see later that this basic math doesn’t apply to all combinations of composition and properties.

Effect on color

We’re not limited to positional properties. animation-composition impacts all animatable properties. And color properties produce interesting results.

Consider another example where we have an element with a background color of rgb(159, 0, 10). Then we apply an animation that animates the background color to rgb(129, 255, 30). The replace composition does as its name says; it interpolates from the start value to the end value just as it’s declared. With add and accumulate, the value of each channel – in this case, r, g, b – in the starting color is added to the corresponding channel of the ending color. Because this is rgb, each channel is capped at 255. We end up with the following:

r: 159 + 129 = 288, so we’re capped at 255
g: 0 + 255 = 255
b: 10 + 30 = 40

The ending background-color for add and accumulate is rgb(255, 255, 40).

See the CodePen.

This example uses rgb, but a similar operation happens with hsl, hex, or a mix of color formats.

add vs accumulate, and the curious scale

In the examples so far, add and accumulate look the same. They do behave differently, but depending on the animated properties, there may not be a visible effect, or it may just be subtle. Let’s look at another example that shows a clear difference between the two and also shows that not all properties behave the same way.

In this example, we’ll animate a scale transform. Our elements start at scale(0.5) and animate to scale(2). We know the final scale value for replace will be 2 or 200%. Looking at our previous examples, you would think we’d do the same basic math for add and accumulate where both would do 0.5 + 2 and end up with a scale of 2.5 or 250%.

But that’s not how scale behaves. Take a look at the example and keep an eye on the scale values in the table.

See the CodePen.

We end up with scale of 1 for add and a scale of 1.5 for accumulate. Hrm, strange. But, it's good that we’re finally seeing the two operations produce different results.

What’s the math here, though? 0.5 + 2 should be 2.5, right? Why isn’t that happening, and what is the math behind this? Unfortunately, I couldn’t find an answer before the publish deadline for this post. This does work the same in all browsers, so it doesn’t seem like a bug. Some underlying logic for scale must make these the intended results. If you know the reason, please write about it!

Even with this, you still get more control over scale – and any other properties that work the same way – it just takes some trial and error to get to the exact values you need.

Browser support

Support for animation-composition is good. According to MDN, recent versions of all major desktop and mobile browsers support the property.

Chrome 112
Firefox 115
Safari 16
Edge 112

The standard caveat does apply here, though. While this property is implemented in browsers, it is still a W3C editor’s draft in CSS Animations Level 2. That means the spec could change, and/or browsers may implement it differently. Always test in multiple browsers.

Using it

This is an interesting property. It’s likely not something you’ll use every day or even very often. It feels like something you’ll reach for when you’re trying to accomplish something very specific. That’s what makes it cool. It’s a low-level control for when you know exactly what you’re going after. And, if not that, it’s also helpful to toss on different values to play with random effects. Both are great reasons to use it. This property needs a healthy amount of trial and error to figure out how to make it work for you.

All the demos in this post and a couple more are available at https://codepen.io/tylergaw/pen/VwgmrMY.

Reference

Tyler selected The Lower Eastside Girls Club for an honorary donation of $50

The Lower Eastside Girls Club amplifies the inner power of young women and gender-expansive youth in New York City through our free, year-round innovative programs in STEM, Arts, Digital Media and Sound, Wellness, Civic Engagement, and Leadership.

Web Components

2023-12-16T00:00:00.000Z

"Web components" is an umbrella term for a set of modern web APIs that make it easier to work with the DOM. Broadly speaking, it includes three main features:

Custom elements
Shadow DOM
Slots and templates

In this post, we'll use web components to build a theme toggle that will allow us to switch between regular and festive themes. When the festive theme is active, it will start snowing, which is quite similar to this very site.

We'll go through the important bits of HTML, CSS, and JavaScript in order. A complete CodePen demo can be found at the end.

Custom elements

This is a custom element:

<theme-toggle>…</theme-toggle>

Really, that's it. Any element whose name contains a hyphen (-) is a custom element. The naming restriction helps prevent conflicts with "built-in" elements.

So far, this is not that different from a <span>, but it has some useful capabilities, as we'll see later.

Start with the markup

Let's add all our important markup inside this custom element. For our theme toggle, we just need a button with some text. We can wrap the text in a <span> to make it easier to style later.

<theme-toggle> 
  <button type="button"> 
  <span>Festive theme</span> 
  </button> 
</theme-toggle>

To make our toggle more accessible, we'll implement the switch pattern, which requires the role="switch" and aria-checked attributes. When a screen-reader user accesses our button, they'll hear something like "Festive theme, switch, off (or on)".

These attributes could be added here in the initial markup, but since these don't affect initial paint, and this pattern requires JavaScript to work anyway, let's save them for later.

Style like you normally would

We can reference custom elements in CSS selectors, just like we'd do for built-in HTML elements. Nothing new here (except the use of native CSS nesting).

theme-toggle {
  /*...*/
  button {
    /*...*/
    span {
      /*...*/
    }
  }
}

One important thing to mention, though, is display. By default, custom elements are inline elements, but we usually want something like inline-block or block , so that it can be sized predictably. This is also a particularly good use case for display: contents, since we care more about the button inside it.

theme-toggle { 
  display: contents; 
}

Draw the rest of the owl

theme-toggle CSS

/* "-base" is temporary for this step */
theme-toggle-base {
	display: contents;

	& button {
		all: unset;
		display: grid;
		grid-template-areas: "label" "toggle";
		place-items: center;
		gap: 4px;
		cursor: pointer;

		&:hover,
		&:focus-visible {
			&::before {
				background-color: hsl(0 0% 50% / 0.2);
			}
		}

		&:focus-visible {
			outline: 3px solid CanvasText;
			outline-offset: 2px;
		}

		& span {
			grid-area: label;
			font-size: 1.5rem;
		}

		&::before,
		&::after {
			grid-area: toggle;
			content: "";
			display: inline-block;
			border-radius: 9e9px;
			border: 3px solid;
		}

		&::before {
			block-size: 70px;
			inline-size: 120px;
			transform: background-color 0.2s;
		}

		&:after {
			block-size: 50px;
			aspect-ratio: 1;
			background: CanvasText;
			transform: translate(-50%);
			transition: transform 0.2s;
		}

		&[aria-checked="true"] {
			&::after {
				content: "";
				transform: translate(50%);
			}
			& span::after {
				content: "!!";
				position: absolute;
			}
		}
	}
}

@layer {
	.theme-toggle *,
	.theme-toggle ::before,
	.theme-toggle ::after {
		margin: 0;
		box-sizing: border-box;
	}
	.theme-toggle  {
		color-scheme: dark;
		background-color: Canvas;
		color: CanvasText;
		font-family: system-ui;
		display: grid;
		place-items: center;
		min-height: 30dvh;
	}
}

The CSS is quite simple. Here are some of the interesting points:

The button implements a two-row grid to place the toggle below the label.
The toggle is created using the ::before (for the "outer" border) and ::after (for the "inner" switch) pseudo-elements.
[aria-checked='true'] is reused as a stateful semantic selector, avoiding the need for an additional class/attribute.

Let's enhance

We are now ready to "enhance" our custom element with JavaScript behavior.

A custom element must be written as a JavaScript class which extends the HTMLElement interface.

class ThemeToggle extends HTMLElement {}

And then, it can be associated with a tag name using the customElements.define() method (available globally under window ).

customElements.define('theme-toggle', ThemeToggle);

This makes sense! Do you know how when we create or query for a built-in element like <button>, we return an instance of HTMLButtonElement? Similarly, when we query for <theme-toggle>, we'll get back an instance of ThemeToggle.

What is this?

Inside a JavaScript class, we expect the this keyword to refer to an instance of the class. this is how we're able to access the instance fields and methods defined in our class. And since we're extending the HTMLElement interface, this also gives us access to all the regular DOM methods, like querySelector and innerHTML .

There are many ways this can go wrong, especially when dealing with event listeners. Instead of doing a deep dive on this, I will suggest a simple rule that helps avoid most of the confusion: only pass around arrow functions. The arrow function can contain the entire logic or simply call an instance method.

// ❌
something.addEventListener('click', this.handleClick);
// ✅
something.addEventListener('click', () => this.handleClick());

connectedCallback all the things

When defining our class, we can use a bunch of handy lifecycle methods that will always be called in a predictable fashion. The most important one is connectedCallback, which gets called when the custom element is added to the document. We can set up most of our component logic here.

First, grab our button and add the required attributes for the switch pattern we discussed earlier.

class ThemeToggle extends HTMLElement {
  connectedCallback() {
    const button = this.querySelector('button');
    button.setAttribute('role', 'switch');
    button.setAttribute('aria-checked', 'false');
  }
}

Now, let's add a "click" event handler to the button. The main thing we'll do is toggle the aria-checked attribute's value. Our CSS already knows how to react to this attribute, so we don't need to do anything else to make the toggle work. We'll also add a snowfall effect shortly, but for now, let's just store its state in an instance field this.snowing.

class ThemeToggle extends HTMLElement {
  connectedCallback() {
    // ...
    button.addEventListener('click', () => {
    this.snowing = !this.snowing;
    button.setAttribute('aria-checked', this.snowing);
  });
}

And just like that, our toggle switch works!

Our deliberate choice to use a <button> element as the base means that it will be automatically keyboard-focusable and the click handler will also be automatically called when pressing the Enter or Spacebar keys.

theme-toggle connectedCallback

theme-toggle {
	display: contents;

	& button {
		all: unset;
		display: grid;
		grid-template-areas: "label" "toggle";
		place-items: center;
		gap: 4px;
		cursor: pointer;

		&:hover,
		&:focus-visible {
			&::before {
				background-color: hsl(0 0% 50% / 0.2);
			}
		}

		&:focus-visible {
			outline: 3px solid CanvasText;
			outline-offset: 2px;
		}

		& span {
			grid-area: label;
			font-size: 1.5rem;
		}

		&::before,
		&::after {
			grid-area: toggle;
			content: "";
			display: inline-block;
			border-radius: 9e9px;
			border: 3px solid;
		}

		&::before {
			block-size: 70px;
			inline-size: 120px;
			transform: background-color 0.2s;
		}

		&:after {
			block-size: 50px;
			aspect-ratio: 1;
			background: CanvasText;
			transform: translate(-50%);
			transition: transform 0.2s;
		}

		&[aria-checked="true"] {
			&::after {
				content: "";
				transform: translate(50%);
			}
			& span::after {
				content: "!!";
				position: absolute;
			}
		}
	}
}

@layer {
	.theme-toggle *,
	.theme-toggle ::before,
	.theme-toggle ::after {
		margin: 0;
		box-sizing: border-box;
	}
	.theme-toggle  {
		color-scheme: dark;
		background-color: Canvas;
		color: CanvasText;
		font-family: system-ui;
		display: grid;
		place-items: center;
		min-height: 30dvh;
	}
}

class ThemeToggle extends HTMLElement {
  connectedCallback() {
    const button = this.querySelector("button");
    button.setAttribute("role", "switch");
    button.setAttribute("aria-checked", "false");

    button.addEventListener(
      "click",
      () => {
        this.snowing = !this.snowing;
        button.setAttribute("aria-checked", this.snowing);
      }
    );
  }
}

customElements.define("theme-toggle", ThemeToggle);

How cool is that?! Our custom element can manage its own lifecycle independently. No need to mess with DOM ready events (which are unreliable) or mutation observers (which are tedious).

Cleanup

The disconnectedCallback lifecycle method gets called when the custom element is removed from the document. It is good practice to remove event listeners (and do other "cleanup") inside this method, especially when building for highly dynamic websites.

The best way to remove event listeners is using an AbortController. This is done in three steps:

Store the controller in an instance field.
Pass its abort signal when adding event listeners. The same signal can be reused for multiple event listeners.
In disconnectedCallback, call abort() to remove all event listeners together. There is no need to hold on to references to every individual event listener.

class ThemeToggle extends HTMLElement {
  connectedCallback() {
   // …
   const { signal } = this.controller = new AbortController();
     button.addEventListener(
       'click',
       () => { /*…*/ },
       { signal }
     );
  }
  disconnectedCallback() {
    this.controller.abort();
  }
}

Shadow DOM

Shadow DOM is another web component API that is used for attaching a "hidden" DOM tree to an element. This tree is encapsulated from the rest of the document, which means its styles and IDs won't "leak" out and vice-versa.

One interesting thing to note: a shadow DOM tree does not always need to be attached to custom elements; it can also be attached to many built-in elements (see full list).

With that in mind, let's build our snowfall effect. Since this effect will likely require a bunch of otherwise meaningless elements, we can use shadow DOM to avoid cluttering our main HTML. Shadow DOM is particularly good at hiding such purely presentational elements.

Let's attach a shadow tree to the <body> element using the attachShadow method.

class ThemeToggle extends HTMLElement {
  // …
  connectedCallback() {
    // …
    this.setupSnowfall();
  }
  setupSnowfall() {
    if (!document.body.shadowRoot) {
      document.body.attachShadow({ mode: "open" });
    }
  }
}

Some interesting notes:

We usually want to set the mode to "open" unless there is a good reason to prevent other JavaScript code from accessing this shadow tree.
Since <body> is a shared element, it may already have a shadow tree attached to it. We can check for it using the .shadowRoot property.
For more robustness, it may be better to attach a shadow tree to another element and append that element to <body>. However, I'm using <body> here for simplicity and to demonstrate slots in the next section.

Slots

By default, shadow trees will "replace" all the content of the element that it's attached to. We definitely want to keep our <body> content around. We can do that using a "slot".

Slots are an important tool that provides a way to mix and match parts of shadow DOM and "light" DOM. As a general pattern, we can use slots to keep our semantically important parts in the light DOM and hide implementation details in shadow DOM.

Let's add a <slot> element into our shadow tree. All the <body> content will be automatically filled into this slot.

class ThemeToggle extends HTMLElement { 
  // … 
  setupSnowfall() { 
    // … 
    const slot = document.createElement('slot'); 
    document.body.shadowRoot.appendChild(slot);
  } 
}

Make it snow

Now for the fun part: the snowfall effect! There are probably better ways to do this, but I will show off a simple SVG.

This SVG will cover up the entire viewport, so its viewBox is based on window.innerHeight and window.innerWidth.
Since it should not occupy any space, we can use position: fixed. Any CSS written inside shadow DOM is automatically scoped to the elements within this tree, so we'll just use svg as the selector.
Inside the SVG, we'll place a bunch of <circle>s at random spots and use <animate> to make them move across the screen.

I won't show the full code because, as far as our web component is concerned, all we're doing is inserting HTML into the shadow tree. You'll find the full CodePen below.

class ThemeToggle extends HTMLElement {
  // …
   setupSnowfall() {
     // …
     const { innerWidth: w, innerHeight: h } = window;
     slot.insertAdjacentHTML('beforebegin', `\
       <style>
        svg { position: fixed; inset: 0; }
       </style>
       <svg viewBox="0 0 ${w} ${h}" aria-hidden="true">
         <circle>…</circle>
         <circle>…</circle>
         <circle>…</circle>
         …
       </svg>
    `);
  }
}

Lastly, all we need to do is toggle the snow when the button is clicked. I like to use a combination of setters and private properties for this sort of logic. Our click handler already toggles this.snowing so let's just convert that into a setter. We'll execute the logic of starting/stopping the animation whenever the setter function is called.

class ThemeToggle extends HTMLElement { 
  // … 
  #snowing; 
  get snowing() { 
    return !!this.#snowing; 
  } 
  set snowing(snowing) {
    this.#snowing = snowing;
    const svg = document.body.shadowRoot.querySelector('svg');
    [ ... svg.querySelectorAll('animate')].forEach(a => {
      if (snowing) {
        a.beginElement();
      } else {
        a.endElement();
      }
    })
  }
}

And we're done!

See the CodePen.

Go further

While we've covered most of the important bits of web components, there's a lot more to it!

Custom elements can "react" to attribute changes using observedAttributes and attributeChangedCallback.
:defined and :whenDefined are great for improving the progressively enhanced experience of custom elements.
The <template> element can be used to store "inert" HTML and avoid having to create elements inside JS.
Named slots can be used to control which content fills which part of the template.
Custom events can be dispatched from a custom element to communicate with other parts of the document.
Declarative shadow DOM (once available cross-browser) will let us attach shadow trees without any JS!
Shadow parts can be used to selectively allow external styling of nodes within a shadow tree.
Constructable stylesheets provide a performant way to write CSS-in-JS.
Server-first frameworks can be used to make shadowless web components portable.
Most UI frameworks have good support for consuming web components. Some frameworks can also compile to web components, while others only allow writing web components.

Mayank selected Trans Lifeline for an honorary donation of $50

Trans Lifeline provides direct emotional and financial support to trans people in crisis, in the United States and Canada.

CSS @scope

2023-12-15T00:00:00.000Z

Scoped styles have always been the primary goal of CSS. Selectors scope declarations to matched elements. Those selectors can be combined to create more specific scopes – each modified by its relation to others. But the @scope feature, already available in Chromium browsers, will make that functionality even more powerful.

Historically, relational selectors were limited in what scopes they could express, and the results can feel fragile if we’re not careful. Narrow relations like the > ‘child’ combinator break if we add a wrapping element around the child. Broader relations like the ‘descendant’ combinator can easily bleed into nested content. That’s fine when we really mean ‘direct children’ or ‘all descendants’ – but often, we’re trying to express a more abstract idea of belonging.

Some styles are global, but many styles belong to a component. When we select the article .title we don’t necessarily want all the .title elements inside the article, but specifically the .title that belongs to the article. This is what people mean when they ask for scope in CSS. Selectors that convey not just nesting, but belonging.

Nicole Sullivan pointed to these issues back in 2009, and since then authors have developed a number of elaborate workarounds. The BEM (e.g. block-element--modifier) naming convention has been dominant for over a decade, with more and more third-party tools providing ‘scoped styles’ as a build step.

Fifteen years of scope hacks

To express belonging in CSS, we need two parts – what BEM would call the ‘block’ and the ‘element.’ Elements belong to blocks. To make that relation clearer than simply nesting, BEM requires adding the block name to every element and selector in the scope:

/* nesting: all matching elements in the block */
.block .element { … }

/* BEM: just the elements belonging to the block */
.block-element { … }

Most front-end frameworks now provide scoped styles, generating unique block names and appending them to elements automatically:

/* Frameworks (the details vary) */
.element[data-scope=block] { … }

But naming conventions require strict adherence across an organization, and automation requires full control of both the HTML and CSS output in a single build step. It’s an invasive process that applies unique attributes throughout the DOM and appends them to every relevant selector.

These are not reliable solutions to the problem; they’re hacks we’ve grown used to over the last fifteen years.

(Re-) Introducing CSS @scope

The new CSS @scope rule allows us to define a scoped relationship in two parts. First, we define the block itself by selecting the ‘root’ of a given scope. Those selectors go in the ‘prelude’ to the rule:

@scope (.block) { … }

Then, we can define ‘scoped’ selectors that belong in the scope of that block:

@scope (.block) {
  .element { … }
}

This might be familiar if you’ve used CSS nesting. It will select the same elements as either of the following:

.block {
  .element { … }
}

.block .element { … }

With nesting, there’s an implicit & before each nested selector, but you can also place the & explicitly if you want. The & selector is a stand-in for the nesting parent:

.block {
  .element { /* implied starting & */ }
  & .element { /* explicit starting & */ }
  .context & { /* repositioned & */ }
}

Scope works the same way, but using the :scope selector by default:

@scope (.block) {
  .element { /* implied starting :scope */ }
  :scope .element { /* explicit starting :scope */ }
  .context :scope { /* repositioned :scope */ }
}

They look similar, but don’t let that fool you. CSS nesting is a shorthand for writing multi-part (complex) selectors. But despite being written in multiple steps, the resulting selectors only match a single element: the final ‘subject’ of the combined selector. Nested relationships can be referenced along the way to narrow down our subjects, but those relationships don’t ‘stick around’ after selection is complete.

To make the scope more meaningful in the cascade, we need to know both the element that we’re styling and also the blocks that it belongs to. The scope rule achieves that by explicitly breaking selection into two distinct parts with two distinct targets: a scope-root selector and a subject-element selector. That subtle change makes all the difference.

Scope Proximity

Because we know the relationship between the subject and the scope it belongs to, we can do things like measure their proximity – the number of DOM steps between them:

<article class=’block’>
  <p class=’element’>
    Only 1 step 
    from .element to .block.
  </p>
  <footer>
    <div>
      <p class=’element’>
        3 steps from .element
        (through div and footer) 
        to .block.
      </p>
    </div>
  </footer>
</article>

Scope proximity has been added to the cascade after selector specificity but before order of appearance. When two selectors with equal specificity apply to the same element, the selector with a ‘closer’ scope-root will win.

See the CodePen.

This is especially helpful in situations where the two selectors serve the same purpose, and we might want broadly overlapping scopes – like setting link colors from different themes. But other ways exist to achieve a similar result, like custom properties (which inherit based on proximity). Things get more exciting when we add a third selector to the syntax.

Scope Boundaries

The real power of a component-based approach is the ability to compose new patterns by combining blocks in various ways. The ‘tabs’ component is only useful when we put other content inside each tab panel. However, the tab element doesn’t know what that content will be, so the scope of our ‘tab’ component styles should stop where the content begins. Nicole calls that ‘donut scope’ – when components have a hole in the middle (or a slot) for other content to go inside.

That causes a problem for nested selectors, which apply to all descendants equally. So we rely instead on third-party tools and BEM syntax to generate unique identifiers and apply them to each element in the donut. The @scope rule makes that possible without any conventions or tools. We can provide a second selector in the prelude:

@scope (.block) to (.slot) {
  .element { … }
}

You can see this work in any up-to-date Chromium browser:

See the CodePen.

Scoped Rules Keep Specificity Low

Another big difference between nesting and @scope is the specificity of the selectors. Nested selectors are combined into one, with a combined specificity to match:

#banner {
  /* specificity: [1, 0, 1] */
  h1 { color: hotpink; }
}

But with scope, we use two or three distinct selectors. They are never joined together, and so they don’t result in a combined specificity:

@scope (#banner) {
  /* specificity: [0, 0, 1] */
  h1 { color: hotpink; }
}

Many authors like that BEM syntax ‘flattens’ specificity by using a single class for everything. But selection is half of what CSS does! If we can only use classes, we’re giving up some of the most powerful and expressive features in the language. By using scope instead of nesting when it makes sense, we can get the best of both worlds!

Using an explicit :scope selector will add some specificity – a pseudo-class has the same specificity as a normal class. It refers to the scope root element but without directly referencing the scope-root selector. If we do want to combine the two selectors and get their combined specificity, we can use the & instead:

@scope (#banner) {
  /* specificity: [0, 1, 1] */
  :scope h1 { color: hotpink; }

  /* specificity: [1, 0, 1] */
  & h1 { color: hotpink; }
}

Implicit Scopes and Embedded Styles

Sometimes, it can be useful to embed styles directly in the page along with the component that they style. We can use scopes there, too! An @scope rule without a defined root selector will use the parent element as an implicit scope root:

See the CodePen.

Bringing it all together

I don’t want to make it sound like scope and nesting are in competition here:

Use @scope to define specific patterns or components and their block-element relationships. Those can be broad (entire themes) or narrow (single buttons) and might overlap sometimes. It’s fine for elements to belong in multiple scopes, but each scope is specific to some fragment of the DOM.
Nesting exists to make complex selectors more readable. It can handle a wider variety of selectors than @scope because it is not designed for one specific use-case. While @scope is excellent at expressing the block-element relationship, nesting is still the clear choice for the element--modifier relationships, like pseudo-classes.

Some other recent features overlap with scope in interesting ways:

Use @layer to group and prioritize different styling concerns. They tend to be more broad and architectural – resets, frameworks, design systems, and utilities – and apply to any number of components. A button component and a theme component might both start with ‘default’ layers.
Scope roots will often be good container elements for @container queries. I expect it will be common to see :scope { container: my-scope-name / inline-size; } at the top of many @scope rules.

Happy scoping!

Miriam selected The Trevor Project for an honorary donation of $50

The Trevor Project’s mission is to end suicide among LGBTQ young people.

Anchor Positioning

2023-12-14T00:00:00.000Z

Imagine CSS Flexbox without the ability to use the flex property. Imagine CSS Grid without an ability to use repeat() for its templates, or an ability to configure grid-column and grid-row for specific elements. Without these essential features, these layout methods will not make much sense.

Illustration source

In a few years, after anchor positioning will become available in all browsers, we will look back at it and think: “How could we use it without anchors?” — that’s what I can say now, after experimenting with today’s anchor positioning prototypes and thinking about its specs.

The Disclaimer

The first thing that needs to be said before discussing anchor positioning is — its current status.

Today, we cannot use anchor positioning in any regard. It is not ready.

The specification is evolving and improving; it is not done yet. While the first Working Draft was published in June, since then, there have been developments (see the Area-based Positioning section), which resulted in many additions to the current Editor’s Draft. Furthermore, there are close to 50 open issues, and it is uncertain what the specification will include when it will be ready.

That said, even today, there is a lot to play with!

You might want to open the examples you will see in the latest Chrome Canary with the “experimental web platform features” feature flag turned on so you can play with them yourself!

In this post, I won’t provide a “tutorial” on how to use anchor positioning. It is a large specification, and as it is not finalized, any tutorial will soon be outdated. If you’d want to read something besides the specification, I recommend the introductory article by Jhey Tompson. However, many of its details are outdated, like the change from anchor-scroll to anchor-default and several other aspects.

My goal today is to talk about what anchor positioning brings to the table, not to get lost in the particularities of the current implementation. I will not include many demos and examples of code in this post but will link to a list of experiments for you to explore in the end.

The Concepts

In a general sense, anchor positioning is an addition to the existing absolute and fixed positioning (I’ll use “absolute” for both in the future to simplify things). It augments them by providing the superpower of knowing the positions and dimensions of other elements.

By itself, absolute positioning is absolute: you give it coordinates that are based on its positioning context (closest positioned ancestor or its initial containing block). That’s one of the two things our element knows about. The other is a “hypothetical box” — the initial position of the element if an inset property was not set, which might be a powerful way to handle absolute positioning but a fragile one.

And that’s it. Every so often, this is enough, but for many cases where we want an element to be visually attached to something, these limitations result in either us adding “magic” numbers or a lot of JavaScript.

Anchor positioning helps us by providing the information we need — and sometimes more.

Connecting Elements

Anchor positioning does this by allowing us to explicitly connect an absolutely-positioned element to another element.

We do this in two steps in CSS:

We give our anchor element the anchor-name property, which can contain one or more dashed identifiers, for example, anchor-name: --tooltip-context.
At the same time, we use this name on our absolutely-positioned element, mentioning it in the anchor-default property, or inside the anchor() or anchor-size() functions.

When we do this, we connect our anchored element with its anchor, providing the coordinates and dimensions to be used as the base for positioning. That means our elements now do not live in isolation — they are connected, and a change in the size or position of one would result in the corresponding change in another.

In the below example, we can see how when we click on the button, the popover appears attached to it.

See the CodePen.

We’re not limited by connecting one element to one another. We can have a many-to-many relationship: multiple elements can connect to one anchor, and one element can use the information from multiple anchors, including inside calculations!

The demo above, for example, uses multiple anchors to position the arrow of a popover. You might notice that the popover itself is centered relative to the button, but the arrow has two attachment points: the popover itself and a snowflake inside the button.

Speaking of centering behavior, this is the most complex part of this demo. The code for it might look unappealing:

[popover] {
    inset-inline: calc(
      anchor(50%) -
      min(
        abs(0% - anchor(50%)),
        abs(100% - anchor(50%))
      )
    );
    margin-inline: auto;
}

Try wrapping your head around how this is calculated! This code is an adapted version of what was in the specs initially, but thankfully, we will have better ways of handling this in the works.

Area-based Positioning

This summer, Elika J. Etemad and Jen Simmons from Apple, with the help of Miriam Suzanne, provided their alternative exploration of anchor positioning. You can read their original exploration and go through the slides they showed at the CSSWG face-to-face meeting.

Many things were proposed in the exploration, but the first thing that found its place in the revised specifications is the inset-area property — the idea of positioning things using a grid-like syntax.

As I demonstrated in the above example, we had to use overcomplicated calculations to center things properly. In the future, we will have an anchor-center value for self-alignment properties, but even then, we will have to rely on specifying the inset properties, which might be cumbersome.

The way inset-area would help with this is by allowing us to tell the anchored element to be positioned in a specific area of a 3×3 grid, which is formed around its positioning context and its anchor.

An example of inset-area: start center / top positioning. This illustration first appeared in the slides, now present in the specs.

This is intended to provide a simple way to handle the most common cases for popovers and tooltips and will come with several built-in mechanisms for how the alignment will be handled.

I did file a CSSWG issue suggesting that we could use another anchor as a way to define our “containing block” that is used for inset-area.

While I was writing this article, the Chromium team started working on the inset-area prototype, and right now, we can play with it in Chrome Canary.

However, not all the moving pieces are in place that could help us see how useful this method will be. One of inset-area’s prominent features is how it will work with self-alignment properties, and this interaction is not yet in the prototype.

A few months back, after Apple presented their ideas, I created a prototype using existing anchor positioning in Chrome Canary. It used overly complicated CSS based on cyclic toggles as an attempt to test this syntax alongside the self-alignment and the potential ::tether pseudo-element.

See the CodePen.

It does not do everything right and might differ from what we have in Chrome Canary for inset-area. Nevertheless, I got enough insights from it, and I invite you to play with it and make your own observations! (Don’t look into the source — it is messy. I warned you!)

Position Fallbacks

Another big aspect of anchor positioning is how it will handle how our anchored elements behave when they go beyond their scrollports.

There are multiple ways to achieve this in the current Canary implementation, but the specification is in motion, and it is certain that things will change, so I won’t describe the way it works now.

The idea that will stay: we will have a way to define how things will look when there is no space for an element, like flipping the popover to a different place.

In this screen recording of the demo in action, the popover changes its position when there is not enough space. The way the inline inset is set up also allows it to shrink to remain centered when located at the edge of the screen.

This is a video from a demo I did show before, where I used the current implementation and some hacks to achieve the desired behavior. Hopefully, the final specification allows us to do things without hacks!

Accessibility Considerations

Apart from the anchor positioning not being ready for production in any way, one thing is worth mentioning: anchor positioning is used for connecting things with each other.

When using the popover attribute, the connection would be established, however, with an anchor attribute by itself, and when done in CSS via anchor-name, this connection is purely visual.

That means that while it is possible to connect elements that are located in different places on the page, anchor positioning could lead to the content not being accessible: visually, the content would be located together, but for keyboard navigation or any assistive technologies the pieces will be disjointed.

Again, the specs and its prototype implementation are in motion, and nothing is certain yet. We need to explore what anchor positioning could mean for accessibility in the future and participate in the discussions about that.

For example, I created an issue in CSSWG, where I proposed to automatically adjust the elements' logical (tab and reading) order when they’re connected via anchor positioning. It would be great if this could be handled from the get-go, and if you have anything to add — add your voice!

Additional Links and Experiments

There were many aspects of anchor positioning that I did not cover in this post: anchor-size() (which I wish could be used for non-sizing properties), how to take the scroll into account, and other aspects of the features I covered or mentioned (for example, the nuances of how fixed positioning works when anchored). This is a complex spec!

In closing, I will list several articles and demos I recommend you check out if you are keen to learn more and see various use cases where anchor positioning can help. There are plenty of things we could do with it!

“Tether elements to each other with CSS anchor positioning” — the already mentioned article by Jhey Tompson (many demos in this one!)
My first article about anchor positioning: “Future CSS: Anchor Positioning” — contains many use cases outside the more common tooltips and popovers.
My second, recent article: “The Shrinkwrap Problem: Possible Future Solutions” — about how one aspect of anchor positioning can help partially solve one of the oldest CSS problems.
“Positioning anchored popovers” by Hidde de Vries — an article exploring different ways we can anchor things when using the Popover API, including anchor positioning.
“Building a no-JS radial menu with CSS trigonometry, popover, and anchor positioning” — an article by Una Kravets in which she builds a radial menu by using Popover API and anchor positioning.
“Nuclear Anchored Sidenotes” by Eric Meyer — an article exploring one of the more interesting use cases for anchor positioning.

If you’re curious how things evolved, you can look at all the explainers that were done:

The most recent CSS Anchor Positioning Explainer by Xiaocheng Hu.
An outdated CSS Anchored Positioning explainer by the Microsoft Edge team.
“Call for web dev feedback: anchored positioning use cases + requirements” by Melanie Richards, in which she asks for dev feedback regarding the above proposal. A linked issue with the gathered feedback and use cases is also a very nice collection of things to think about in the context of anchor positioning.
The initial exploration by Ian Kilpatrick and Tab Atkins-Bittner.

Roman selected QueerJS for an honorary donation of $50

QueerJS is a meetup series where everyone is encouraged to attend and support the speakers and the idea. If you're queer and want to speak, this meetup is for you! It exists to give you a voice and to make a safe space where everyone is welcome.

Popover API

2023-12-13T00:00:00.000Z

What are Popovers?

The Popover API is a new feature of browsers to help create overlapping user interface elements and avoid common issues related to z-index stacking, dismissals, poorly implemented accessibility, and more.

Brought to us by Open UI

The Popovers API is a browser addition proposed by Open UI, a W3C community group that has set out to define and extend the capabilities of built-in web components.

Open UI has a clear set of goals for Popovers, including:

Accessible by default
Easily styled and animated
Built-in light dismissals, such as pressing the Esc key
An easy way to move any element to the #top-layer
Most common usage will not require JavaScript

How to use Popovers

Popovers were designed for easy implementation and can be used without needing to reach for JavaScript. To create a popover element, all that is needed is to add the popover attribute to the element that will be overlapping other elements within the UI.

<div id="my-popover" popover>
    <p>This is a popover!</p>
</div>

The element will be hidden automatically, only becoming visible once toggled open.

Now, let’s create a button to toggle the popover. On the button, add the popovertarget attribute and supply the id of the popover element. Another necessary attribute is the popovertargetaction attribute, which will tell the browser what to do with the popover.

<button popovertarget="my-popover" popovertargetaction="toggle">
  Toggle Popover
</button>
<div id="my-popover" popover>
    <p>This is a popover!</p>
</div>

popovertargetaction action has three possible actions that can be performed:

toggle - toggles the popover between an open and closed state.
show - sets the popover to an open state.
hide - sets the popover to a closed state.

JavaScript Implementation

Popovers can also be controlled through JavaScript with the addition of new methods that can be used on popover elements.

showPopover() - sets the popover to an open state.
hidePopover() - sets the popover to a closed state.

Actions related to the popover state can be run by listening for the onpopovershow and onpopoverhide events.

Styling Popovers

Popovers can be styled with CSS like any other element by targeting the popover’s class or id, however, popovers can also be targetted by utilizing the bracketed attribute selector [popover].

[popover] {
  background: dodgerblue;
}

Two new pseudoselectors can be helpful in styling popovers:

:popover-open - applies styling only when a popover is in an open state (great for animations!)
::backdrop - enables styling of the popover’s backdrop.

Accessible by default

Popovers were created with accessibility in mind, with a few accessibility features included out-of-box:

Any element can become a popover, which carries over element semantics to the #top-layer as well.
When popover elements are open, they become the next focusable element in the tabindex.
Users can close popovers by pressing the Esc key on the keyboard, as well as clicking outside the popover to dismiss.

Here is a demo using Popovers to create a drawer component

See the CodePen.

This demo is taking advantage of all the main features of the Popover API, including:

No JavaScript is utilized to create the drawer toggle action.
The drawer is placed in the #top-layer which prevents any issues with z-index stacking.
The Popover drawer is styled using [popover] attribute selector, and utilizing the ::backdrop pseudo element and :popover-open pseudo selector for animations.
The drawer can be closed by clicking the "Close" button within the drawer, by pressing the Esc key on the keyboard, or by clicking outside the drawer.

Browser Support

Popovers are a fairly new concept that is being adopted by browsers. Chrome 114 was the first browser to introduce Popovers and recently was added to Safari in version 17. Firefox has yet to implement Popovers fully, however, they can be enabled via a feature flag.

More resources on Popovers

For further reading on the Popover API, check out the following links:

Open UI Explainer
Hidde de Vries post on differences between `<dialog>` and Popovers
Adrian Roselli wrote a brief note on using Popovers and Dialogs
MDN page on Popovers
HTML Spec on Popovers

Ryan selected The Trevor Project for an honorary donation of $50

The Trevor Project’s mission is to end suicide among LGBTQ young people.

CSS Subgrid

2022-12-24T00:00:00.000Z

The subgrid value for grid-template-rows and grid-template-columns is now supported in Firefox and Safari 16+, and coming soon to Chrome. In this article, you’ll learn the ways that this feature makes grid layout even more powerful.

All of the examples in this article can be viewed with subgrid working in Firefox or Safari 16+, except for the final example.

It doesn’t add a whole lot more complexity

Using subgrid means that instead of creating a track listing as a value for grid-template-columns and grid-template-rows, you use the keyword subgrid.

There are no new properties or values to learn, just a decision to make—do you want your nested grid to have its own row and/or column definition, or to use the one from the parent?

In the first example, I have a nested grid that is creating its own tracks for rows and columns. These tracks are independent, and so will not line up with the tracks on the parent grid.

See the CodePen.

The second example replaces the track listing for grid-template-columns with the keyword subgrid. The column tracks of the nested grid now line up with those on the parent.

See the CodePen.

You can have subgrids in your subgrids

As long as each parent is a grid itself, you can keep inheriting subgrids down into children.

The following example shows three grids, each nested inside the other, and inheriting the tracks of their parent. The child items indicate which grid is their parent. Using Firefox DevTools to highlight each grid, highlighting the outer grid shows how the children grids and grid items all align to that grid.

See the CodePen.

You don’t need to have a subgrid in both dimensions

When subgrid was discussed in the CSS Working Group, there was a suggestion that it should be locked to both rows and columns. This would have meant there was no implicit grid in either dimension, and subgrid would only be useful if you knew exactly how many grid cells you needed in the subgrid.

In the next example, I have created a subgrid on columns to ensure items in the nested grid can align with items directly inside the parent grid. However, I am using the implicit grid for rows, as I may have any number of items.

See the CodePen.

Subgrid can help with situations where you need to target the end line of the implicit grid

The previous example demonstrates another useful pattern enabled by subgrid. It’s possible to target the end line of the explicit grid using line -1. Unfortunately, this doesn’t work to target the end line of an implicit grid.

By nesting repeating items in a container, they all go into one row on the parent. This means you can have the full height column shown in the previous example without needing to know how many lines of items are created implicitly.

If you inspect the previous example using DevTools, you can see how the subgridded items create implicit rows. As the item on the left is in the parent grid, it is in the same row as all of the items and therefore can become as tall as is needed to align with the implicit rows.

You can align things using the line names of the parent grid

If your parent grid has named lines, these are accessible from the child. In the following example, lines on the parent grid are named a through e. The subgrid and a child of that subgrid are then placed using these named lines. This technique is useful, as it saves keeping track of what line number things are. You can set up names on the parent and know that by placing an item starting at that line it will always align with other things starting on that line.

See the CodePen.

You can add line names to the subgrid

Can’t get enough line names? You can add names to the lines within the subgrid. Granted, the syntax is a bit unusual, because we don’t have a track listing to put the line names into. Instead, you add the names after the subgrid keyword.

.subgrid {
  display: grid;
  grid-template-columns: subgrid [line1] [line2] [line3];
}

These names will be added to any other names the line has, as a line can have multiple names. You can then reference it using any of the names assigned.

See the CodePen.

You can use implicitly named areas from inherited lines in your main grid and subgrid

When you name lines with the suffix -start and -end, you get a named area of the main name used. As lines are inherited so are these named areas. In the following example, I have named lines main-start and main-end and col-start and col-end. This gives me a wide column named main, and a narrow column named col.

I place the article into grid-column: main, and then make it a subgrid. I can then place the contents of the article into the narrow column with grid-column: col.

See the CodePen.

The subgrid can have different-sized gaps to its parent

The gap property will inherit into the subgrid so, by default, a subgridded element will have the same size gaps as its parent. If you don’t want that, use the gap property (or column-gap or row-gap) to change it.

In the following example, the parent grid has 20px gaps for rows and columns. In the subgrid, I want just 1 pixel of the background to show through as a gap, so I have changed the gap on the subgridded card to 1px.

See the CodePen.

You can line up items that are in different subgrids

Using subgrid for rows means that items nested in separate subgrids, such as the cards in the previous example, are in the same row meaning items inside can align with each other. If I add more content to one of the headings, you can see how all headings in that row get extra space below and remain aligned.

See the CodePen.

Subgrid can be usefully combined with container queries

A common pattern is to have a 12-column grid at all breakpoints, and as the viewport becomes smaller, items span more of the columns. At a very narrow viewport width an item might span all 12, on the desktop 3.

Using container queries, you can test to see if the container has enough space, then switch on subgrid so the component can use the tracks it spans across. In the following example, the card spans two column tracks of the parent grid. At narrow widths, the card is not a subgrid, and the image and content display one after the other.

Once there is enough room, the card becomes a subgrid and the image and content display side by side.

See the CodePen.

Additional resources on subgrid

With subgrid coming to all engines very soon, it’s a great time to start to play with it and see what other reasons to love subgrid you can come up with. See the following resources for more ideas and help.

Rachel selected Holly Hedge for an honorary donation of $50 which has been matched by

Holly Hedge is an organization in Rachel's home town of Bristol. They rescue and rehome unwanted and often poorly treated animals, and do an amazing job finding homes for over 800 animals a year.

CSS :has()

2022-12-23T00:00:00.000Z

Developers have been requesting a parent selector since jQuery introduced .has() in 2007, and it is finally here. At the time of this writing, it is behind a flag in Firefox and supported in Chrome, Edge, and Safari.

The newly supported `:has()` is more than just a parent selector; it’s a relational selector. Yes, it can match an ancestor element based on containing a specific descendant, but it can also match antecedent elements based on subsequent content.

The long-supported :nth-last-of-type() selects an element based on having sibling selectors of the same type. In the following pseudo-code, you can select any h2 that has a later sibling h2. For example, h2:nth-last-of-type(n+2) selects the first two <h2> elements (the first byline and first subheader).

<main>
  <h1 data-function=”mainheader”>
  <h2 data-function=”byline”>
  <p>
  <h2 data-function=”subheader”>
  <p>
  <h3 data-function=”subheader”>
  <p>
  <h2 data-function=”subheader”>
  <h3 data-function=”byline”>
  <p>
 </main>

While it has been possible to select previous siblings of the same type with `:nth-last-of-type()`, :has() enables selecting previous siblings of any type.

Given the pseudo-HTML above, how can we target subheaders immediately followed by a byline? h2 + h3 matches the byline, but how do we target only the subheaders that have an adjacent byline? With h2:has( + h3)!

Let’s break that down.

The :has() functional pseudo-class takes a relative selector list as an argument. Let’s parse those words: functional selector, selector list, and relative selector. We will also cover forgiving selector lists which come into play until :has() has full browser support.

Functional pseudo-class

While there are several selectors with parenthesis, including the linguistic pseudo-classes (:dir() and :lang()) and structural pseudo-classes (like :nth-last-of-type()), there are four selectors considered to be “functional selectors”.

The negation (:not()), a relational selector (:has()), the matches-any (:is()) , and the specificity adjustment (:where()) pseudo-classes each take a selector list as their argument.

Selector List

A selector list is a comma-separated list of selectors.

It is important to note that if any element in a selector list is invalid, the entire list and associate style block are ignored.

/* These are valid */
body, *, #unusedId {color: yellow;}
body, *, .unused-class {color: blue;}
body, *, undefined-element {color: black;}

/* These are all invalid */
body, *, #00invalidIdName {color: green;}
body, *, :fake-pseudo-class {color:red;}
body, *, ::invalid-pseudo-element {color: purple;}

Given the above code, everything on the page will be black. If an id is a valid id, a class is a valid class, or a custom element is not defined, and there are no matching elements in the HTML, the CSS doesn’t know or care as there are no matching elements. But pseudo-classes and pseudo-elements can be invalid; :foo and ::-typo-thumb will make a selector list fail. They, and weird `id` selectors that aren’t correctly escaped, will invalidate the entire selector list.

Because the entire selector list and associate code block are ignored if a selector list contains an invalid selector, old code bases have style blocks that are repeated multiple times.

For example, the pseudo-element selector targeting scrollbar and range thumbs are unique to each browser engine; with no browser supporting all of the following:

body,
::-moz-range-thumb,
::-ms-thumb,
::-webkit-scrollbar-thumb { 
  border: 5px solid red !important;
}

With the above code, neither the <body> nor any scrollbar or range thumb will have a red border in any browser. Because at least one of the prefixed pseudo-elements will be invalid in every browser, the entire block is ignored, and the style block is not applied to anything, not even the <body>. Because of this, developers have been separating out each prefixed pseudo-element, leading to code similar to the following because normal selector lists are not forgiving.

body { border: 5px solid red !important; }

::-moz-range-thumb{ border: 5px solid red !important; }

::-ms-thumb{ border: 5px solid red !important; }

::-webkit-scrollbar-thumb { border: 5px solid red !important; }

Forgiving selector list

In a forgiving selector list, each selector is parsed individually. Invalid selectors within the list are simply ignored. The selector lists for :is(), and :where() are forgiving.

The above could be written as:

body,
:is( 
  ::-moz-range-thumb,
  ::-ms-thumb,
  ::-webkit-scrollbar-thumb
) { 
  border: 5px solid red !important;
}

This is less verbose while having the same specificity.

Until :has() is supported in all browsers, when including :has() with other selectors in a selector list, enclose the selector within an :is() or :where().

h3,
:is(h2:has( + h3)) {
  margin-bottom: 3rem;
}

Specificity

The :has() selector and the other functional pseudo-classes themselves don’t add any specificity weight to the selector. Rather, except in the case of the specificity-adjustment :where() pseudo-class, the argument adds the weight. The specificity weights of the`:not()`, `:has()`, and `:is()` pseudo-classes are the weights of the selector in the selector list with the greatest specificity.

Specificity of :is()

Given :is(#fakeId#fakeId#fakeId, body), even though body is a type selector, which has low specificity, the specificity weights of the associate property values is the weight of three id selectors. It matches <body> with a specificity of 3-0-0. The specificity that :not(), :has(), and :is() contribute to the specificity algorithm is the specificity of the selector in the parameter that has the greatest weight.

Specificity of :where()

The `:where()` pseudo-class is different; it adds no weight to the specificity equation. :where(#fakeId#fakeId#fakeId, body) matches <body> with a specificity of 0-0-0.

Relative selector

Each selector within the :has() pseudo-class selector list is relational. Relational selectors are selectors that represent elements relative to one another.

In the case of the :has() relational selector, the relative selector is in relation to the anchor element, which is the element on which the :has() is applied. In the case of h2:has(+h3), the anchor is the h2.

A relative selector is one that starts with a combinator, whether explicit or implied. If there is no explicit combinator, like >, ~, or +, the descendant combinator (a space) is implied.

Compare the following selectors:

Given h2:has(+h3), or, more legibly, h2:has( + h3), the anchor is the h2 and the relational selector is + h3. Combined, the selector reads “every h2 that has an adjacent sibling which is an h3”.
Given h2:has(h3), the descendant space combinator would be implied as h2:has( h3). This selector reads “every h2 that has at least one h3 as a descendant”.
Given h2:has(> h3) it reads “every h2 which has at least one h3 that is a direct child.”

Back to our code example:

<main>
  <h1 data-function=”mainheader”>
  <h2 data-function=”byline”>
  <p>
  <h2 data-function=”subheader”>
  <p>
  <h3 data-function=”subheader”>
  <p>
  <h2 data-function=”subheader”>
  <h3 data-function=”byline”>
  <p>
 </main>

The selector main:has(h2 + h3), reads “every main that has a descendant h2 which has an h3 as an adjacent sibling”. Associated styles will apply to main, the anchor, if there is a descendant <h2> immediately followed by an <h3>. This is an ancestor match. In our code example, the last <h2> has an <h3> as an adjacent sibling, so this selector selects the ancestor <main>.

For an actual parent selector, (not just an ancestor selector) we use the child combinator (>). main:has(> h2 + h3) will match as well, as long as the <h2> is a direct child of <main>, which it is.

The parent and ancestor examples had main as the anchor. If we allow the relationship to be implied, we may not get what we expect. If we include h2:has(h3) nothing is matched in this scenario, as h3 is not a descendant of the h2.

The reason :has() is called a relational selector rather than a parent or ancestor selector is because it can be used for more than just ancestral reasons. To select the h1 only if it is immediately followed by an h2, we write h1:has(+ h2). The + is the adjacent sibling combinator. * + h2 is a relational selector.

There is also a general sibling combinator (~). [data-function="byline"]:has(~ [data-function="byline"]), which reads “match any element with the byline function which has a sibling with the byline function”. This will match all the sibling elements with the byline function except the last, regardless of the element type. The last one isn’t matched because it doesn’t have a sibling of that class that comes after it.

Before :has() was available, while we could select a previous sibling of the same type, selecting a previous sibling element of a different type was not possible.

Logical operations

The :has() relational selector can be used to check if one of the multiple features is true or if all the features are true.

When we include multiple selectors in the relative selector list, we can match the anchor element if any of the relational selectors are true. The following matches main if there are any bylines (a header immediately followed by a next-level header):

main:has( > h1 + h2, > h2 + h3, > h3 + h4) p {}

This reads “style all paragraphs in main if the main has a child h1 immediately followed by an h2, a child h2 immediately followed by an h3, or a child h3 immediately followed by an h4. Including multiple selectors in the list against an anchor is an OR statement.

You can also string multiple relational selectors together to create an AND statement.

main:has( > h1 + h2):has( > h2 + h3) p {}

This reads “style all paragraphs in main if the main has a child h1 immediately followed by an h2 AND a child h2 immediately followed by an h3."

This codepen includes styles for all these examples

See the CodePen.

Usefulness

The :has() selector is more useful than you likely ever imagined.

[type=”checkbox”]:required:not(:checked) + label {
  /* styles to applied to the label of all required checkboxes
  that aren’t checked yet */
}

With the adjacent sibling combinator, we have been able to style checkbox and radio button labels which generally come after the form control. Now, with :has(), we can style labels that come before their associated form control.

p:has(:required:invalid) label,
*:has( > label + :required:invalid) > label {
  color: red;
}

The above provides two selectors that will turn a label red if the form control is required but not valid, either because the value is invalid or if there is no value entered. The first selector selects the <label> inside a <p> if the paragraph contains a form control that is required but not currently valid. When the form control becomes valid, the selector will no longer match, and the label will no longer be red (unless some other CSS made it red).

The second line is more robust. You may not know exactly how the list of form controls is constructed, but that’s OK. You don’t need JavaScript to toggle class names! The second selector styles the label child of any element when a required but invalid form control is the adjacent sibling of that label.

See the CodePen.

The next time you think “let me just add a class to that" or if you ever consider needing to add an inline style, consider whether the element can be targeted with :has().

For example, how do you style all the cells in a <table> column without adding a class to each <td>? While <col>, the table column element, supports a few styles, there’s no way to style the contents of a cell based on it, or is there? With :has(), you can style something in a <tbody> or <tfoot> based on whether a table has a specific attribute or attribute value in the <caption>, <colgroup>, or <thead>. (And really learning HTML helps.)

table:has(col.right:last-child) tbody tr > :last-child {
  text-align: right;
}

If the last <col> in a table has the right class, then the last child of each row in the table body should be aligned right. In this case, we are styling something in one section of a table based on the presence of a class in a different section of the table. This was not possible before.

See the CodePen.

This example enabled adding the class of right or center to the last six col elements in a colgroup, styling the last td or th in each row in the tbody based on the class set of the associated but not ancestral col. For years, developers have been complaining about the limited styles that can be set on col elements; :has() helps alleviate table styling headaches.

Avoiding failure

For the time being, if you are using :has() within a selector list, stick the :has() within a :where() or :is() to enable Firefox to ignore the :has() until it is supported by default (it is currently behind a flag).

Note that nesting a :has() inside another :has() is not permitted. The :has() pseudo-class is not supported on pseudo-elements either. For example, ::first-line:has(a[href]) will not target a first line containing a link; it is invalid. Similarly, pseudo-elements are not supported within the relative selector list. The specification has allowed for supporting pseudo-elements in the future but has not defined the support of any pseudo-elements as of yet

Estelle selected Open Web Docs for an honorary donation of $50 which has been matched by

Open Web Docs supports web platform documentation for the benefit of web developers & designers worldwide.

2022 CSS Updates

2022-12-22T00:00:00.000Z

It has been an extra jolly year for the advancement of CSS! Multiple long-awaited features were integrated into our evergreen browsers (Chrome, Edge, Firefox, and Safari) with a momentum that will stretch into 2023.

Let's take a quick look under the CSS tree and unwrap the gifts we received this year!

But first, here are three 2022 CSS features already covered in this series:

Cascade layers landed after an impressive cross-browser effort in February/March this year, and spec author Miriam Suzanne contributed an in-depth guide to cascade layers on day 5
:has() is considered the "parent" selector, but learn why that's not the whole story from Estelle Weyl on day 11
New viewport units arrived in November for Chromium to round out the evergreen support, and on day 1, Eric A. Meyer reviewed the new dynamic viewport units

Finesse element layout changes with container queries

CSS container size queries are a way to move beyond media queries that are tied to the viewport and instead will enable us to modify an element's behavior based on the container it's within. Anticipate them becoming cross-browser when they are shipped in January in the upcoming Firefox 109. With the container queries polyfill, you can absolutely begin using them today!

I provided a preview of container queries in the 2021 series, but at that time they were still an experimental spec. However, I did update that article when the syntax stabilized later in the year, so go learn how to get started with container queries!

An upcoming feature often coupled with container queries is for the range syntax for media queries. At this time, it is supported in Chrome, Edge, and Firefox, and Safari Technical Preview 160. It's also supported via the container queries polyfill and by build processing tools like LightningCSS.

In 2023, look out for container style queries to stabilize, as well. Ahmad Shadeed has an excellent preview of ways we'll be able to use style queries.

Better control of effects with individual transform properties

In August, Chromium 104 completed the availability of the individual transform properties of rotate, scale, and translate. This means that when you define a transform and need to update one of those transform types, you can do so one-off instead of duplicating the rest of the transform definition, too.

This brings more control for creating transitions and animations, such as to scale an element with a keyframe animation. Previously you may have used custom properties to alleviate this pain point and achieve similar control, but having separate properties is definitely preferred!

More intentional focus styles with `:focus-visible`

In March, Safari 15.4 released the :focus-visible psuedo-class and shortly after, it became the default element focus behavior used in evergreen browsers. When using :focus-visible, based on heuristics, the browser will determine whether to show a "focus ring" - if you don't supply your own :focus styles as an override. In practice this means keyboard (tab) interaction on focusable elements like buttons will show a focus ring, but not mouse clicks.

You can review more about how this works and my favorite method to define focus styles with custom properties.

Custom form control colors with `accent-color`

Also arriving in Safari 15.4 in March was the accent-color property. As the writer of a 4-part series on customizing form fields, I can tell you folks are really interested in this topic!

Using accent-color allows you to partially colorize four controls: progress, range, checkbox, and radio. Try changing the value of the accent-color in the following CodePen.

See the CodePen.

Adapt to OS dark/light modes with `color-scheme`

January brought color-scheme to Firefox to round out support. This property allows you to define which OS color modes your site elements support. It can be set on :root to affect a page, or on individual elements. It accepts one or two values for the definition, where setting only "light" means you only support a light theme. Using two values, such as setting "light dark", means your site prefers light mode but will also work with dark mode. This property does not require the use of the prefers-color-scheme media query to work.

When set on the :root (and without site overrides to related properties) it will opt-in your entire layout to automatic dark mode when that is the OS option. This includes changing the page background to black and text and form control colors to a lighter color for appropriate contrast. The CodePen demonstrates a page with some text and a few form fields and only the color-scheme property in use to adapt to light and dark modes.

See the CodePen.

Even if you want to create custom light and dark themes, this property is still beneficial and can be coupled with accent-color to adapt form controls and achieve a custom feel.

Sara Joy shares more about how `color-scheme` works including the related meta tag and altering it with JavaScript.

Prevent background page scroll with `overscroll-behavior`

Have you ever been annoyed at a page of documentation beginning to scroll after you reached the end of scrolling the sidebar navigation? Controlling this "scroll chain" is the purpose of the overscroll-behavior property which became cross-browser with Safari 16 in September. The property accepts three values, where contain is what you'll want to use to prevent the scroll-chaining effect when the scroll boundary within a subpage element (like the sidebar nav example) is reached.

In the CodePen demo, the "Table of Contents" list area is scrollable and overscroll-behavior: contain will prevent scrolling of the background article until your mouse leaves the list container.

See the CodePen.

Almost stable: `subgrid` for grid layout inheritance and reusability

Subgrid is nearly cross-browser, with Chromium lagging just a tiny bit, but with a prototype in progress which shows their intent to stabilize the feature. Definitely, one to start becoming familiar with for use later in 2023!

Learn 10 ways subgrid makes grid layout even more powerful on day 12 from Rachel Andrew.

What's next for CSS in 2023?

I'll leave you with two places to bookmark to keep on top of changes in CSS:

Interop 2023 will be collective browser benchmarks with areas including CSS where they plan to improve implementations and support. Review Interop 2022, and look out for the release of the 2023 dashboard.
The CSSWG works in public on GitHub and you can look up issues and discussions and even provide feedback

CSS Color Spaces and Relative Color Syntax

2022-12-21T00:00:00.000Z

There are two new specs in the works for CSS that will change how we work with color on the web: CSS Color Module Level 4 (candidate recommendation) and CSS Color Module Level 5 (working draft). Both are still experimental and, as of December 2022, only Safari has an implementation.

We’re going to focus on three things found in these specs: the new syntax for color functions, one of the (many) new color spaces introduced by level 4, and the new relative color syntax from level 5. Combined, these three things are powerful tools for building accessible color palettes with CSS.

New Color Function Syntax

CSS Color Module Level 4 introduces a new syntax for color functions like rgb() and hsl(). The new syntax omits commas, relying on spaces to separate each of the channels for the color space. It also supports an optional alpha parameter, eliminating the need for additional color functions like rgba() and hsla(). The comma-separated forms are now referred to as “legacy syntax” by the spec.

/* Legacy syntax */
background-color: hsl(270, 50%, 40%);
color: hsla(0, 0%, 100%, 50%);

/* CSS Color Module Level 4 equivalent */
background-color: hsl(270 50% 40%);
color: hsl(0 0% 100% / 50%);

True to the web, existing functions like rgb() and hsl() will continue to support both the new syntax and the legacy, comma-separated syntax. Newer color functions — some of which we’ll look at below — only support the new, space-separated syntax.

New Color Spaces

The new color spec adds a whole host of new color spaces to the web: Hue, Whiteness, Blackness (HWB); CIE L*a*b*; Lightness, Chroma, Hue (LCH); Oklab; Oklch; and Display P3, just to name a few. Some of these color spaces — like Display P3 — offer a wider color gamut than the sRGB space we’ve been restricted to on the web since… well, forever. This means that we’ll have access to more colors and that those colors will be more vibrant than the colors we’ve been using, colors that have been available to native app developers for a while.

We’re not going to focus on the wider gamut spaces, though. If you’re interested in learning more about these wide gamut color spaces (or simply what even is a color gamut), I suggest watching Chris Lilley’s CSS Day 2022 talk, Escaping the sRGB Prison (YouTube).

We’re going to focus on Oklch.

Oklch

Oklch is a polar color space, similar to HSL. It has three channels: lightness (l), chroma (c), and hue (h). Lightness can be either a number between 0 and 1, or a percentage. Hue can be either a number (without units, this corresponds to degrees) or an angle (using units deg, grad, rad, or turn). Chroma takes either a number (unbounded, but in practice doesn’t exceed 0.5) or a percentage (100% is equivalent to 0.4). Chroma is similar to saturation, but it is independent of the perceived lightness for a given hue.

Perceptual Uniformity

We’re focusing on Oklch because, unlike sRGB, Oklch is perceptually uniform. This means that uniform changes to the lightness channel of a color are evenly spaced visually and that two colors with the same lightness value will have the same perceived lightness — which is not true in a color space like HSL.

Two color swatches with the same HSL lightness, have very different perceived lightness, as evident when converted to Oklch.

The above example — from the level 4 spec — shows a blue and yellow swatch in sRGB color space, specified by #00F and #FF0, respectively. In HSL, both colors have the same lightness value (50%), but yellow is clearly much lighter than blue. The difference in lightness is reflected in the Oklch color space where the lightness of the blue swatch (0.452) is much lower than the lightness of the yellow (0.968).

The above example makes clear that we can’t rely on the lightness channel in HSL to help us create color palettes with enough contrast to be accessible. But by using a perceptually uniform color space like Oklch, we will have a much easier time creating accessible palettes.

If we look at a gradient going from black to white, we can see the difference in lightness between HSL and Oklch. When interpolated through Oklch, each step creates a uniform increase in perceived lightness. When interpolated through HSL, the perceived lightness changes more quickly in darker values than it does in lighter values.

The same gradient interpolated through two different color spaces — HSL and Oklch — with the mid-gray value marked on each.

In the above gradients, notice how the darker shades are clustered closer to the left edge of the gradient for HSL than they are for Oklch. The point closest to a mid-gray is marked on each of the gradients. For Oklch, it is approximately in the middle of the gradient, but for HSL, it is slightly to the left of center.

Relative Color Syntax

CSS Color Module Level 5 further augments color functions by introducing relative color syntax. This syntax allows you to define a new color based on another color. You use it by first defining an origin color using the from keyword and then specifying the channels for the new color as usual in the color function.

Relative color syntax only works in the modern, space-separated color formats, not the legacy, comma-separated formats.

When you provide an origin color, you get access to “channel keywords” that allow you to reference each of the channels in the color space. The keywords change depending on the color function you use. For rgb(), you’d have the r, g, and b channel keywords; for oklch(), you’d have the l, c, and h keywords. For every color function, you also have an alpha channel keyword, that refers to the origin color’s alpha channel.

You can use these channel keywords in calc() expressions to modify the original color.

/* Desaturate the named color tomato in sRGB */
rgb(from tomato calc(r - 20) calc(g - 20) calc(b - 20));

/* Create a semi-transparent version of tomato */
rgb(from tomato r g b / 50%)

/* Darken tomato in oklch */
oklch(from tomato calc(l - 0.1) c h);

You can define relative colors across color spaces as well. When you take a color originally defined in one space and define a new color using a different color space, the browser will first convert the origin color to the new color space.

Here we use Oklch to define a secondary color based on a primary color defined in sRGB by rotating the hue 120° (⅓ of a turn):

--primary: #005f73;
--secondary: oklch(from var(--primary) l c calc(h + 120));

Relative Colors for Design Systems

Sometimes you’ll see people define colors in CSS using one custom property for each color channel — Josh Comeau recently wrote about this in his section on super-charged design tokens in his article about color formats. For example, let’s redefine our primary color — #005f73 — in separate l, c, and h channels so we can create shades in Oklch:

/* Define the channels for primary color in oklch */
--primary-l: 0.4485;
--primary-c: 0.081;
--primary-h: 218.73;

/* Base primary color */
--primary: oklch(var(--primary-l) var(--primary-c) var(--primary-h));

/* Create a darker shade of the primary color by subtracting 0.1 from the lightness channel */
--primary-darker: oklch(calc(var(--primary-l) - 0.1) var(--primary-c) var(--primary-h));

You can probably see where this is going…

The new relative color syntax removes the need to break each of your colors up into separate channels when you define them. It also allows you to use the most convenient color format for your origin colors regardless of the color space you want to use to modify the origin color.

If you’re working from a design tool that makes it easy to copy sRGB hex values, you can just paste those into your CSS and still use Oklch or Oklab to define perceptually uniform shades.

--primary: #005f73;
--primary-darker: oklch(from var(--primary) calc(l - 0.1) c h);

See how much more convenient that is?

And More…

There’s a lot more coming to colors in CSS. The level 5 spec also introduces a color-mix() function that allows you to mix colors in different color spaces — another potentially useful tool in the design system arsenal. And the editor’s draft for the CSS Images Module Level 4 introduces syntax to gradients for defining the interpolation space of the gradient, allowing you to create more vibrant gradients or achieve different artistic effects with your gradients. We glossed over color gamuts, but the new, wider gamut color spaces like Display P3 will give us access to brighter, more vibrant colors than we’ve had access to up until now.

Additional Resources

CSS Color Module Level 4
CSS Color Module Level 5
CSS Images Module Level 4 Editor’s Draft
Escaping the sRGB Prison (YouTube) by Chris Lilley, CSS Day 2022
OKLCH in CSS: why we moved from RGB and HSL
Color Formats in CSS by Josh W. Comeau

Evan selected The Trevor Project for an honorary donation of $50 which has been matched by

The Trevor Project’s mission is to end suicide among LGBTQ young people.

Pointer Events

2022-12-20T00:00:00.000Z

While we've long had the ability to detect mouse events with JavaScript, the web was missing a singular interface to detect interaction regardless of input type. As of the release of Safari 13 in September 2019, the pointer events API became the cross-browser, unifying solution.

As MDN docs describe, a pointer "is a hardware-agnostic device that can target a specific set of screen coordinates." Generally, you can consider pointers to include mouse, pen/stylus, or touch interactions.

Pointer events inherit from the mouse events interface, so you receive corresponding events, such as:

mousedown / pointerdown
mouseup / pointerup
mousemove / pointermove

For backwards compatibility, the browser may opt to map these generic events to mouse events, with some exceptions.

Additional specific pointer event properties include those that tell about the dimensions of the pointer (width and height), the pressure being applied, the pointer's tilt, its type, a unique pointer id, and whether it's the primary pointer of the type.

Using pointer events to resize UI

To explore how these properties work together and learn two additional pointer methods, we'll be building "Santa's Workshop Handbook" - an online reference for elves and other workshop workers!

The handbook shares a need found in many documentation sites or multi-column application windows: the ability to resize one or more panels to reveal the content or hide it away for more reading or work space.

Fundamentally, the expected interaction is "click and drag," but pointer events will let us write this to be touch-friendly, too! We'll also ensure the feature is accessible for keyboard users.

First, we'll add the basic HTML and CSS for the handbook.

Handbook HTML and CSS

.demo {
  padding: 0 !important;
}

.workshop-handbook {
  --panel-width: 200px;

  font-family: system-ui;
  font-size: 1.25rem;
  display: grid;
  align-content: start;
  grid-template-columns: var(--panel-width) 1fr;
  position: relative;
  background-color: firebrick;
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'%3E%3Cdefs%3E%3Cfilter id='paper' x='0%25' y='0%25' width='100%25' height='100%25'%3E%3CfeTurbulence type='fractalNoise' baseFrequency='0.11' result='noise' numOctaves='5' /%3E%3CfeDiffuseLighting in='noise' lighting-color='firebrick' surfaceScale='1.5'%3E%3CfeDistantLight azimuth='85' elevation='70' /%3E%3C/feDiffuseLighting%3E%3C/filter%3E%3C/defs%3E%3Crect x='0' y='0' width='100%25' height='100%25' filter='url(%23paper)'/%3E%3C/svg%3E");
  overflow: hidden;
}

.workshop-handbook * {
  margin: 0;
}

.workshop-handbook :is(nav, article) {
  all: unset;
  max-height: 60vh;
  max-height: 60dvh;
  overflow-y: auto;
  overscroll-behavior: contain;
}

.workshop-handbook nav {
  padding: 1rem;
}

.workshop-handbook nav ol {
  padding-left: 0;
  display: grid;
  gap: 1em;
}

.workshop-handbook nav li {
  color: white;
  /* force the overflow and add ellipsis */
  overflow: hidden;
  white-space: nowrap;
  text-overflow: ellipsis;
}

.workshop-handbook nav a {
  font-family: Papyrus;
  text-decoration: none;
  color: white;
  position: relative;
  padding-left: 1em;
}

.workshop-handbook nav a:hover {
  text-decoration: underline;
  text-underline-offset: 0.15em;
}

.workshop-handbook nav a:focus-visible {
  outline: none;
}

.workshop-handbook nav a:focus-visible::before {
  content: "";
  position: absolute;
  top: calc(50% - 0.5em);
  left: 0;
  border: 0.5em solid transparent;
  border-left-color: currentColor;
}

.workshop-handbook article {
  padding: clamp(1.25rem, 5%, 3rem);
  background-color: #edf9f6;
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'%3E%3Cdefs%3E%3Cfilter id='paper' x='0%25' y='0%25' width='100%25' height='100%25'%3E%3CfeTurbulence type='fractalNoise' baseFrequency='0.11' result='noise' numOctaves='5' /%3E%3CfeDiffuseLighting in='noise' lighting-color='%23edf9f6' surfaceScale='1.5'%3E%3CfeDistantLight azimuth='85' elevation='70' /%3E%3C/feDiffuseLighting%3E%3C/filter%3E%3C/defs%3E%3Crect x='0' y='0' width='100%25' height='100%25' filter='url(%23paper)'/%3E%3C/svg%3E");
  line-height: 1.5;
  font-family: Chalkboard, Comic Sans MS;
}

.workshop-handbook article :not(h2) {
  color: #222;
}

.workshop-handbook article * + * {
  margin-top: 1em;
}

.workshop-handbook article h2 {
  color: firebrick;
  font-family: Papyrus;
  font-weight: normal;
}

.workshop-handbook .visually-hidden {
  clip-path: inset(50%);
  height: 1px;
  width: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
}

@media (forced-colors: active) {
  .workshop-handbook :is(nav, article) {
    background-image: none;
  }
}

🎅 Welcome to the Workshop! 🛠

Lorem ipsum dolor sit amet consectetur adipisicing elit. Quod fugiat autem ab? Veritatis?

Quisquam omnis mollitia assumenda enim? Eum dolorum unde quasi doloremque perferendis velit in.

Cumque qui dolore voluptatibus, reiciendis ipsam optio. Ad nihil repudiandae sunt ratione officiis.

Necessitatibus modi blanditiis earum suscipit reiciendis deserunt, placeat, quis perspiciatis, ullam natus magnam?

Soluta aspernatur exercitationem iste deserunt? Exercitationem debitis modi maxime nulla officiis facilis eius.

We've included the --panel-width custom property for the handbook, which we'll be manipulating based on the pointer's position relative to the amount the panel has been moved.

Pointer target element

What's missing in the markup so far is a target element to attach pointer events. In this case, a <button> is appropriate since it can receive focus and is expected to handle custom events.

Receiving focus is an important aspect since we want our resize trigger to be keyboard accessible, and that's the first step. That also means we need to consider where it makes sense in the focus order. I've decided to place it as the first focus target in the nav so that it's immediately discoverable for keyboard users.

<nav>
  <button type="button" class="resize-trigger" aria-describedby="resize-description"><span class="visually-hidden">Resize table of contents</span></button>
  <p hidden id="resize-description">Drag or use left and right arrow keys.</p>

Additionally, this is a custom control, and it doesn't quite map to any ARIA attributes. It's not a "drag and drop" since there is no drop target, so we've added two important features to clarify the function.

The first is the button label itself which we've made "visually hidden" meaning users of assistive technology like screen readers will have the label announced even though it's not visible. Second, we've included a bit more instructions in the [hidden] paragraph which has a unique id that's been referenced within the button's aria-describedby attribute. Assistive tech will announce something like "Resize table of contents, button, navigation (short pause) Drag or use left and right arrow keys." The "navigation" noted in the announcement is due to being the first focus target in the landmark <nav> element.

The following demo has been updated to include the .resize-trigger elements and styles and is visible on :hover and :focus. We've also included the related CSS media query to detect a coarse pointer. This will be often (but not always) be true for touch devices, or when a mouse is not present or not the primary pointing device. This style makes it always visible so it is easier to find and manipulate without a mouse.

Resize trigger element and CSS

.workshop-handbook {
  --resize-width: 0.75rem;
}

.workshop-handbook .resize-trigger {
  --resize-bg: linear-gradient(to right, #e4b81e, #9f8837);

  all: unset;
  outline: none;
  position: absolute;
  top: 0;
  left: var(--panel-width);
  width: var(--resize-width);
  height: 100%;
  cursor: ew-resize;
  z-index: 1;
}

.workshop-handbook .resize-trigger:is(:hover, :focus) {
  /* Ensure visibility in forced-colors mode which removes the gradient */
  background-color: Highlight;
  background-image: var(--resize-bg);
  box-shadow: 0 0 5px 1px #f5e096;
  outline: 1px solid transparent;
}

@media (pointer: coarse) {
  .workshop-handbook .resize-trigger {
    background-image: var(--resize-bg);
  }
}

🎅 Welcome to the Workshop! 🛠

Lorem ipsum dolor sit amet consectetur adipisicing elit. Quod fugiat autem ab? Veritatis?

Quisquam omnis mollitia assumenda enim? Eum dolorum unde quasi doloremque perferendis velit in.

Cumque qui dolore voluptatibus, reiciendis ipsam optio. Ad nihil repudiandae sunt ratione officiis.

Necessitatibus modi blanditiis earum suscipit reiciendis deserunt, placeat, quis perspiciatis, ullam natus magnam?

Soluta aspernatur exercitationem iste deserunt? Exercitationem debitis modi maxime nulla officiis facilis eius.

Using the pointer events API

Now that the HTML is in place, it's time to make the resize trigger work with pointer events!

The basic flow is as follows:

On pointerdown, start tracking the clientX position during onpointermove. Additionally, use setPointerCapture() to continue tracking only this pointer while pointerdown is active.
On pointerup, remove the onpointermove event to end the drag functionality and stop tracking the pointer with releasePointerCapture().

The resizePanel() script receives the clientX position or other provided integer and compares it to the boundary of the handbook and a minimum and maximum size we'll allow for the panel. If the number is an allowed size, it updates the --panel-width CSS custom property which ultimately is responsible for the resizing since it sets the grid column width for the navigation.

Finally, for purposes of our application, we listen for keydown so that we can detect the ArrowLeft and ArrowRight keys to allow keyboard users to resize the panel, too.

Resizing pointer events

const handbook = document.getElementById("handbook");
const panelResize = handbook.querySelector(".resize-trigger");
const handbookBoundaries = handbook.getBoundingClientRect();
const rightBoundary = handbookBoundaries.right;
const leftBoundary = handbookBoundaries.left;
const contentMin = 150;

const resizePanel = (size) => {
  if (size >= contentMin && size <= rightBoundary - leftBoundary - contentMin) {
    handbook.style.setProperty("--panel-width", `${size}px`);
  }
};

// Create drag and move interaction
panelResize.addEventListener("pointerdown", ({ pointerId }) => {
  panelResize.onpointermove = ({ clientX }) => {
    // Adjust position since demo is not a fullwidth window application
    const panelPos = clientX - leftBoundary;
    resizePanel(panelPos);
  };
  panelResize.setPointerCapture(pointerId);
});

// Release resizer when drag ends / mouse is disengaged
panelResize.addEventListener("pointerup", ({ pointerId }) => {
  panelResize.onpointermove = null;
  panelResize.releasePointerCapture(pointerId);
});

// Allow keyboard resizing
panelResize.addEventListener("keydown", ({ key }) => {
  if (["ArrowLeft", "ArrowRight"].includes(key)) {
    // get current value and add or remove 10px
    let posX = parseInt(
      getComputedStyle(handbook).getPropertyValue("--panel-width")
    );

    if (key === "ArrowLeft") {
      posX -= 10;
    } else {
      posX += 10;
    }

    resizePanel(posX);
  }
});

🎅 Welcome to the Workshop! 🛠

Lorem ipsum dolor sit amet consectetur adipisicing elit. Quod fugiat autem ab? Veritatis?

Quisquam omnis mollitia assumenda enim? Eum dolorum unde quasi doloremque perferendis velit in.

Cumque qui dolore voluptatibus, reiciendis ipsam optio. Ad nihil repudiandae sunt ratione officiis.

Necessitatibus modi blanditiis earum suscipit reiciendis deserunt, placeat, quis perspiciatis, ullam natus magnam?

Soluta aspernatur exercitationem iste deserunt? Exercitationem debitis modi maxime nulla officiis facilis eius.

Additional resources

Learn more about pointer events from the following resources:

Pointer events API docs on MDN
Also see the pointer events docs as related to canvas and a drawing app demo
Docs for `setPointerCapture()` show an additional example of changing an element's position

CSS Scroll Snap

2022-12-19T00:00:00.000Z

With scrolling on the web, there's a feature called Scroll Snap which allows authors to articulate mandatory or optional resting places for scroll. A common initial use case is for carousel-like scrolling.

See the CodePen.

Each of those rows of items uses scroll snapping but tells each row of items to snap to a different spot in the scrollable area. The top one snaps items to the beginning with scroll-snap-align: start. The middle example snaps items to the center of the scroll area with scroll-snap-align: center. The last example snaps items to the end of the scroll area with scroll-snap-align: end.

The basics

The achieve a scroll-snapping scroll experience, there are 2 essential parts to establish:

A scrollable container with overflow that adds `scroll-snap-type` which says the scrollable viewport can be snapped to, which axis to do the snapping, and whether or not it's a requirement to snap (mandatory) or optional (proximity).
One or many children of a scroll-snap container that specifies where to snap with `scroll-snap-align` which says, on an item-by-item basis, where it should snap within that container

You're not limited to a single axis either. A horizontal scrolling snap experience may be the first place your design mind goes to with the feature, but consider this example where snapping can occur on both the x and y-axis.

See the CodePen.

The scroll container specifies it can be scrolled horizontally and vertically, that it's a snap area, and each child should snap to the center.

This demo is also a good time to introduce the scroll-snap devtools in Chromium browsers. Open the codepen in a new tab and inspect the grid. Look for the scroll-snap badge in the elements panel and click it to enable the debugging overlay:

The scroll-snap overlay puts a purple border around the scroll area and a dot on each item that has scroll-snap-align on it. These items all want to snap to the center, so they all have a dot in the center. It also will show overflowing items which is really handy. Here I've constrained the height and width of the scroll area so we can see the overflow and snap alignment.

For a practical application of scroll snapping, I made a media scrolling experience on GUI Challenges that emulates the browsing experience for many media networks. It also features great keyboard navigation and use of `scroll-padding` to create an edge-to-edge scroll experience that rests in perfect alignment with its section header.

Check out the media scroller demo.

Advanced

So far we've put snap alignment on every direct child of the scroll container like .scroll-container > *, but things get interesting when there's only one or a couple of snap targets.

See the CodePen.

In the above demo, the edge most elements are not snap targets, and when that is combined with mandatory snapping specified on the scroll container, it gives a nice bouncy effect to the edges of scrolling (often called an overscroll effect).

You can also have scroll areas inside of scroll areas, each with its own snapping:

See the CodePen.

In the following demo, only 1 element is a snap target (the most recent/last message) which keeps the scroll container at the bottom, even as new messages are added:

See the CodePen.

Conclusion

There's a lot more you can do with scroll snap on the web. I've created a collection on Codepen to make them easy to discover and take code from. That's the grab-n-go aspect of this article!

Hopefully, this gave you an overview of the design opportunities with scroll snap. There's a lot of potential to enhance a scroll experience with healthy scrolling resting places.

Adam selected Black Girls Code for an honorary donation of $50 which has been matched by

We build pathways for young women of color to embrace the current tech marketplace as builders and creators by introducing them to skills in computer programming and technology.

HTML Dialog

2022-12-18T00:00:00.000Z

The HTML element <dialog> has had a long history, first landing in Chrome in 2014! While iterations have had issues largely pertaining to accessibility, it has gained cross-browser stability in 2022.

Before we get into a demo and review implementation features, it's important to understand the difference between the two types: modal and non-modal.

Modal dialogs are user interface elements that become the "top layer" above the rest of the DOM and require interaction that interrupts a user's flow. They have a fixed (non-moveable) position and cover the underlying page with a typically semi-transparent overlay which is the pseudo-element ::backdrop.

When a modal dialog is open, the content behind the page should be rendered inert - in other words, it should have interactivity removed, appearing static. The inert behavior creates a "focus trap" in the modal, meaning a keyboard user can enter the modal and not be able to have focus exit to the page behind until the modal is closed. While an attribute for inert is gaining browser support, a benefit of modal usage of the dialog element is automatic inert behavior. This again is tied to use of the showModal() method.

Another expectation of modal dialogs by keyboard users is the ability to close them using the Esc key, which the <dialog> element provides when launched using the showModal() method.

Non-modal dialogs refer to typically anchored overlays that do not block the page. When open, a user still has access to interact with the page content. They should not be used if the action requires user input or interaction.

Examples include the "Compose" window for an email application, a newsletter sign-up nudge on a blog, a find and replace handler, an onboarding tutorial pointer, or any other sort of sub-window interface. You may choose to enable the non-modal dialog to be repositioned by the user.

The <dialog> element can be used as a non-modal dialog when launched with the show() method. A close action must be provided and non-modal dialogs require user interaction to close them.

Dialog demo

Let's create a modal dialog for confirming whether a user would like to eat a penguin cookie off of a virtual cookie tray!

First, let's start off by designing the markup and styles for our tray of penguin cookies.

We'll use a list that contains our cookie image within buttons. The list semantics will help indicate to users of assistive technology like screen readers how many cookies are left on the tray. And <button> is the appropriate interactive element to trigger the dialog.

<h2>Select a cookie to eat!</h2>

<ul role="list" class="cookie-tray">
  <li><button type="button" class="cookie"><img src="cookie.png" alt="penguin cookie #1" /></button></li>
  <li><button type="button" class="cookie"><img src="cookie.png" alt="penguin cookie #2" /></button></li>
  <!-- ...additional cookie list items -->
</ul>

Cookie tray HTML and CSS

.dialog-demo {
  padding: 5vmin;
  background-color: #ec4913;
  color: #444;
}

.dialog-demo h2 {
  text-align: center;
  margin-bottom: 3vh;
  color: white;
  font-size: clamp(2rem, 5vw + 1rem, 3.5rem);
}

.dialog-demo h3 {
  margin-bottom: 1rem;
}

.dialog-demo button {
  all: unset;
}

.dialog-demo button * {
  pointer-events: none;
}

.dialog-demo button:focus-visible {
  outline: 2px solid var(--button-focus, red);
}

.cookie-tray {
  --cookie-size: max(12vh, 80px);

  list-style: none;
  padding: 5vmin;
  margin: 0 auto;
  position: relative;
  max-width: 80ch;
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, var(--cookie-size)), 1fr));
  gap: 1vmax;
  background-color: silver;
  box-shadow: inset 0 0 6vmin 1vmin rgba(0, 0, 0, 0.65);
  border-radius: 3vmin;
}

.cookie-tray:focus-visible {
  outline: 2px solid black;
  outline-offset: -4px;
}

.cookie-tray li {
  display: grid;
  place-content: center;
  height: var(--cookie-size);
  margin: 0;
}

.cookie-tray .cookie {
  border-radius: 2rem;
  padding: 3%;
  cursor: grab;
}

.cookie-tray .cookie img {
  max-width: 100%;
  height: var(--cookie-size);
  display: block;
}

Select a cookie to eat!

Dialog HTML and content

Our <dialog> aims to confirm whether a user intended to "eat" the penguin cookie. We will include two buttons to select either "Eat Cookie" or "Cancel". I've opted for custom data attributes to distinguish the button actions from one another.

Also, note the .cookie-name element, which we'll populate via JavaScript shortly.

<dialog id="cookie-confirmation">
  <div class="dialog-content">
    <h3>Cookie Selection Confirmation</h3>
    <p>Are you sure you want to eat <strong class="cookie-name"></strong>?</p>
    <ul class="dialog-actions">
      <li><button type="button" data-action="confirm">Eat Cookie</button></li>
      <li><button type="button" data-action="cancel">Cancel</button></li>
    </ul>
  </div>
</dialog>

Additionally, we've added a presentational div.dialog-content which will soon enable us to include the ability to dismiss the modal from a click on the backdrop.

At this point, the dialog is not visible unless we add the open attribute (leading the browser to treat it as non-modal) or add a small bit of script to launch it.

The use of the open attribute is not recommended because it is possible to have state conflicts between the attribute and the dialog JS methods.

Opening the dialog

Since we want the modal behavior of the dialog, our script essentially involves detecting a click on a .cookie button and attaching the showModal() method to the dialog. We're also taking advantage of image semantics to grab the alt value and populate the .cookie-name.

Dialog open script

const dialog1 = document.getElementById("cookie-confirmation-1");

document.getElementById('dialog-demo-1').addEventListener("click", ({ target }) => {
  if (target.matches(".cookie")) {
    // Populate the .cookie-name with the img `alt` value
    dialog1.querySelector(".cookie-name").textContent = target.querySelector(
      "img"
    ).alt;

    // Open the dialog as a modal
    dialog1.showModal();
  }
});

Select a cookie to eat!

If you're following along at home, since we haven't styled the dialog, here's the default dialog appearance in Chromium, including the positioning, which is not currently relative to our cookie tray but to the viewport (some content styles have been established).

Because "Eat Cookie" is the first focusable element, by default, the browser will focus it when the dialog is opened. If you need to change the first-focused element, you can add the autofocus attribute.

Note that if you determine that the dialog itself or something like a headline or other non-interactive element should be focused, you'll need to add tabindex="0" to enable it as focusable. I recommend Adrian Roselli's article to learn more about dialog focus management.

Through testing with VoiceOver on Mac, the h3 title is also read out before announcing the focused button, which helps lend context to the action.

Closing the dialog

We haven't yet added a script to indicate an element to close the button, but the Esc key is enabled for closing due to using the showModal() method (refer back to the "Modal vs. non-modal dialogs" section). This behavior is not available when using the show() method for non-modal dialogs.

Due to how we want our modal to work, we will enable closing of the dialog for both buttons as a starting point. The following enhances our previous dialog script.

document.addEventListener("click", ({ target }) => {
  // ... show logic

  // Close the dialog when either action button is clicked
  if (target.matches("[data-action]")) {
    dialog.close();
  }
});

Removing cookies

There's one more behavior we want for our modal which is when the confirm button for "Eat cookie" is selected then we need to remove the selected cookie.

Upon closing a dialog, the browser will place focus back on the element that launched the dialog. We can take advantage of this behavior to remove that cookie. The browser tracks the currently focused element via document.activeElement.

document.addEventListener("click", ({ target }) => {
  // ... show logic
  // ... close logic

  if (target.matches('[data-action="confirm"]')) {
    // find cookie based on active focus
    const cookie = document.activeElement;
    // remove cookie from DOM
    cookie.remove();
  }
});

However, we also need to define a replacement element to give focus to.

In this case, we'll enable the .cookie-tray unordered list as a programmatically focusable element by adding tabindex="-1". We'll also update the headline to add an id attribute which we'll reference from the aria-labelledby attribute on the list. This will help re-orient screen reader users after the cookie disappears and the focus is moved.

<!-- Updates to the headline and `ul` -->
<h2 id="cookie-tray-title">Select a cookie to eat!</h2>
<ul role="list" class="cookie-tray" tabindex="-1" aria-labelledby="cookie-tray-title">

Then, update the script to add the focus to .cookie-tray:

const cookieTray = document.querySelector(".cookie-tray");

document.addEventListener("click", ({ target }) => {
  // ...

  if (target.matches('[data-action="confirm"]')) {
    // ...

    // Set focus to ul.cookie-tray
    cookieTray.focus();
  }
});

As a bonus of .cookie-tray being a list element, the announced number of list items will update to only include non-empty list items, therefore accurately reflecting the number of cookies visible on the tray!

Depending on your reason for removing DOM elements, you may need to alter this logic to instead move focus to the next, first, or last item in the list depending on the position of the removed element.

Fully working dialog

const dialog2 = document.getElementById("cookie-confirmation-2");
const cookieTray = document.querySelector("#dialog-demo-2 .cookie-tray");

document.getElementById('dialog-demo-2').addEventListener("click", ({ target }) => {
  if (target.matches(".cookie")) {
    dialog2.querySelector(".cookie-name").textContent = target.querySelector(
      "img"
    ).alt;
    dialog2.showModal();
  }

  if (target.matches("[data-action]")) {
    dialog2.close();
  }

  if (target.matches('[data-action="confirm"]')) {
    const cookie = document.activeElement;
    if (cookie.matches(".cookie")) {
      cookie.remove();
    } else {
      // Safari prior to 16.1 does not re-focus dialog triggering element
      const cookieName = dialog2.querySelector(".cookie-name").textContent;
      cookieTray.querySelectorAll(".cookie img").forEach((c) => {
        if (c.alt.includes(cookieName)) {
          c.closest(".cookie").remove();
        }
      });
    }
    cookieTray.focus();
  }
});

Styling the dialog

Our dialog still looks quite plain, so let's fix it up!

The following demo styles the buttons and content, but also adjusts the modal position with the following declarations which centers the dialog within the viewport. You may want to also explicitly add dimension styles depending on your dialog's content - be sure to test cross-browser!

dialog {
  margin: auto;
  position: fixed;
}

If needed, you can also specifically style open modal dialogs using the :modal pseudo class.

Additionally, there is a pseudo-element available when the dialog is open which can be styled with the ::backdrop selector. We'll darken it to a 35% opacity black and also use the property backdrop-filter to create a blurred effect of the content behind the modal.

::backdrop {
  background-color: hsl(0 0% 0% / 35%);
  backdrop-filter: blur(2px);
}

Final dialog with styles

#dialog-demo-3 dialog {
  margin: auto;
  padding: 0;
  width: min(40ch, 100vw - 2rem);
  position: fixed;
  border-radius: 0.5rem;
  font-size: 1.35rem;
  background-color: white;
  border: 2px solid;
}

#dialog-demo-3 .dialog-content {
  padding: clamp(1rem, 5%, 2rem);
}

#dialog-demo-3 ::backdrop {
  background-color: rgba(0, 0, 0, 0.35);
  backdrop-filter: blur(2px);
}

#dialog-demo-3 dialog .dialog-actions {
  list-style: none;
  padding: 0;
  margin: 1rem auto 0;
  display: flex;
  flex-wrap: wrap;
  justify-content: center;
  gap: 1rem;
}

#dialog-demo-3 dialog .dialog-actions button {
  padding: 0.5em 1em;
  border: 1px solid gray;
  border-radius: 0.25rem;
  cursor: pointer;
  text-align: center;
}

#dialog-demo-3 dialog .dialog-actions li {
  margin: 0;
}

#dialog-demo-3 [data-action=confirm] {
  --button-focus: hsl(80 70% 25%);
}

#dialog-demo-3 [data-action=confirm]:is(:focus, :hover) {
  background-color: #bbe467;
}

#dialog-demo-3 [data-action=cancel]:is(:focus, :hover) {
  background-color: #f4c7be;
}

const dialog3 = document.getElementById("cookie-confirmation-3");
const cookieTray3 = document.querySelector("#dialog-demo-3 .cookie-tray");

document.getElementById('dialog-demo-3').addEventListener("click", ({ target }) => {
  if (target.matches(".cookie")) {
    dialog3.querySelector(".cookie-name").textContent = target.querySelector(
      "img"
    ).alt;
    dialog3.showModal();
  }

  if (target.matches("[data-action]")) {
    dialog3.close();
  }

  if (target.matches('[data-action="confirm"]')) {
    const cookie = document.activeElement;
    if (cookie.matches(".cookie")) {
      cookie.remove();
    } else {
      // Safari prior to 16.1 does not re-focus dialog triggering element
      const cookieName = dialog3.querySelector(".cookie-name").textContent;
      cookieTray3.querySelectorAll(".cookie img").forEach((c) => {
        if (c.alt.includes(cookieName)) {
          c.closest(".cookie").remove();
        }
      });
    }
    cookieTray3.focus();
  }
});

dialog3.addEventListener("click", ({ target }) => {
  if(target.matches('dialog')) {
    dialog3.close();
  }
});

Closing on backdrop interaction

In the final styled demo, we also included the ability for clicks on the backdrop to close the dialog by detecting clicks that land on the dialog element itself. The method demonstrated works only if there is a child element that wraps the visible dialog contents and covers their full dimensions, and the dialog takes up the remaining viewport space. Meaning, for example, if you add padding, ensure it's on the content wrapper instead of the dialog. Our child element is div.dialog-content, and the dialog covers the viewport due to the margin filling the space.

dialog.addEventListener("click", ({ target }) => {
  if(target.matches('dialog')) {
    dialog.close();
  }
});

Additional resources on dialogs

While this demo covered the essentials for defining, opening, closing, and styling the <dialog> element, there is quite a bit more to consider (like, do you even need a dialog?).

MDN documentation on dialog
Further definition of and accessibility considerations for non-modal dialogs
"An open dialog" from Scott O'Hara shares some history and remaining considerations for using <dialog>
"In defense of dialog" by Sam Thorogood covers more use cases and features
A thorough guide to "Creating An Accessible Dialog from Scratch" from Kitty Giraudel explaining all the considerations you'd have to address if you didn't use the dialog element
Also from Kitty is the wonderful a11y-dialog script which may presently be more suited for your audience if they are not using the latest browsers

Stephanie selected The Trevor Project for an honorary donation of $50 which has been matched by

The Trevor Project’s mission is to end suicide among LGBTQ young people.

Cascade Layers

2022-12-17T00:00:00.000Z

Specificity is only one part of the CSS Cascade, but it's the part we interact with the most often – and it can quickly become a labyrinth of twisted selectors, frustration, and swearing. That's a terrible way to start the holidays! Unless we’re talking about the Jim Henson movie, which is excellent…

But this year, something changed in CSS. Back in February/March of 2022, all the modern web browsers released Cascade Layers – a new feature that gives you (and me) control over how our selectors interact, regardless of their specificity or code order:

/* establish layer-order: last takes precedence */
@layer default, theme, state;
 
@layer default {
  button {
    background: rebeccapurple;
    color: white;
  }    
}

@layer state {
  :disabled {
    background: dimgray;
  }    
}

@layer theme {
  button.danger {
    background: maroon;
  }

  button.info {
    background: darkslateblue;
  }

  #call-to-action {
    background: mediumvioletred;
  }
}

Since the state layer has the highest layer priority and layers override specificity, the disabled styling will always win in a conflict – even though the theme styles have a higher specificity and come later in the code. We can also nest layers:

@layer reset, framework, components, utilities;

@layer components {
  @layer default, theme, state;
  
  @layer state {
    /* the nested components.state layer */
    :disabled { background: dimgray; }    
  }
}

@layer components.state {
  /* also the nested components.state layer */
  :focus-visible { outline: thin dashed hotpink; }
}

And import entire stylesheets into a layer:

@import url(reset.css) layer(reset);
@import url(bootstrap.css) layer(bootstrap.external);

@layer bootstrap.local {
 /* anything here will override the imported code in bootstrap.external */
}

This can be useful on any size project for both overall architecture and individual components:

Demos: I often use setup and demo layers when creating small code samples. Michelle Barker has a great article about doing that on her CSS { In Real Life } blog.
Prototypes: This same approach is useful for trying something new over top of something that already exists. Put the existing code in a lower layer and prototype in a layer above. If everything in the codebase is layered, you have options! Slot something between layers, or add it to the top of the stack.
Components: Working on a single component, like the buttons above, I’ll ask myself what different layers of styling I need. I find that often results in a similar set of default styles, themes or modifiers, and states.
Site Architecture: When I start a new project, even a small personal site, I’ll often put a few generic styles in a reset or defaults layer – and work my way up from there. Why wait for conflicts to show up when I can avoid them from the start? This also applies to large teams and projects, where the potential for conflicts can seem to scale exponentially. Harry Roberts talks about organizing CSS in an Inverted Triangle, with different "layers" of specificity. Using the @layer rule and layered imports, we can turn that implicit organizing convention into an explicit part of the cascade!
Frameworks & Tools: Many of the existing approaches for managing specificity rely on everyone using the same strict conventions, but it’s impossible to ensure third-party code is following the same rules we use locally. Cascade layers remove the guesswork when using outside tools and let us make the priority of styles clear and consistent.

Layer Ordering

Layers are stacked in the order that each layer-name first appears in the codebase, with later layer-names taking precedence over earlier layers. That means we can allow them to stack implicitly:

@layer low { /* the lowest layer */ }
@layer medium { /* a middle layer */ }
@layer high { /* the highest layer */ }

Or we can define the layer order explicitly by introducing layer names in order with a single list. This is recommended because it ensures a "single source of truth" for the intended order of layers:

@layer low, medium, high;

But there’s no magic to the list syntax – it simply introduces layer names to the stack. Since the stack is based on the first appearance of a name, repeating layer names won’t change their order. This will result in exactly the same layer order as above:

/* introduce the low and medium layers */
@layer low, medium;

@layer low { /* ... */ }
@layer medium { /* ... */ }
@layer low { /* ... */ }
@layer high { /* introduce the highest layer! */ }

/* all these layers already exist, so nothing changes... */
@layer high, medium, low;

We can think of this behavior as though the layers with a shared name are sorted together and merged, so the result is still:

@layer low { /* all the code from ‘low’ layer rules */ }
@layer medium { /* all the code from ‘medium’ layer rules */ }
@layer high { /* all the code from ‘high’ layer rules */ }

That sorting happens independently at each layer of nesting:

/* both medium & medium.low are introduced */
@layer low, medium.low;

@layer high { /* … */ }
@layer medium.high { /* … */ }

First, the top-level layers are sorted (low, medium, high), and then the nested layers are sorted inside of those:

@layer low;
@layer medium.low;
@layer medium.high;
@layer high;

At each level, styles that are un-nested have the highest priority - no matter where they appear in the code. In this example, all the links will be green, since that selector is layered the least:

/* styles not nested in a layer take priority */
a { color: green; }

@layer one { 
  /* the less nesting, the the more powerful */
  a { color: brown; }

  @layer two { 
    a { color: red; }
  }
}

Layers don’t add priority the same way that !important does, but instead, they remove priority in relation to unlayered styles. Rather than creating an arms race to the top, they help us de-prioritize code that we should be able to override easily from somewhere else. But it’s also more nuanced than the :where() selector that simply removes all specificity information from the selectors inside it. We can have both!

Layers help us reclaim declarative control of the intent behind our CSS without removing helpful information about the specificity of selectors. We’re managing the cascade instead of removing it.

By defining a full list of layers up-front, we not only ensure a single source of truth – but it also allows us to load the rest of our layered styles in any order we want. That can be especially useful when using automated tools, like JS frameworks that only load the styles for components that are used on a given page. If all those styles are layered, and all the layer ordering is defined in advance, it doesn’t matter what order the component styles are loaded.

There’s a lot more we could get into here – like anonymous layers and the interaction between layers and importance. I recommend checking out some other articles that get into more detail:

A Complete Guide to CSS Cascade Layers (by Me)
Getting Started With CSS Cascade Layers (by Stephanie Eckles)
The Future of CSS: Cascade Layers (CSS @layer) (by Bramus Van Damme)

Getting Started

Layers already have very broad browser support, so many of us can start using them right away. There’s also a polyfill written in postCSS, for adding support to older browsers without any performance issues.

To start integrating layers onto an existing project, I work from the bottom up. Since layers deprioritize styles, I start with the styles that should have the lowest priority: resets, normalization, and global defaults. Depending on the project, that might be a single layer or multiple, but the idea is the same.

First, we add a layer list that is easy to find at the top of our styles. It doesn’t need to be a full list, just the layers we know we’re going to need. We can even put that directly in the HTML if that helps ensure it always comes first:

<style>/* keep this before linked styles */
@layer reset, default;
</style>
<link rel="stylesheet" href="path/to/styles.css">

If we want to take that a step further, we can also use @import to load our existing styles into a layer of their own:

<style>
@layer reset, default, legacy;
@import url(path/to/new-styles.css); /* put our layered styles in here */
@import url(path/to/old-styles.css) layer(legacy);
</style>

It’s great to get all our styles layered if we can because once we have un-layered styles, there’s nowhere higher to go. By making sure everything is in a layer, we have total flexibility to add new styles above or below what’s already there.

Once the low-priority styles are layered, I would focus on any external styles that a site relies on: design systems, component libraries, and third-party frameworks. Those are the most likely source of specificity frustration, and moving them into layers will make them much easier to manage.

I use Harry Roberts’ Inverted Triangle as a guide. Where he recommends allowing specificity to grow slowly with each implied layer of a project:

I break off one layer at a time, from lowest to highest, making it an explicit layer in the cascade:

As each layer is given an explicit place in the cascade, we have more freedom to use a range of specificity within that layer. We no longer need to constrain ourselves to single-class BEM selectors or carefully remove specificity everywhere possible! Each layer is self-contained, and we can rely on specificity to help work things out inside each layer:

Unleash the Selectors!

Selectors are one of the most powerful (and under-utilized) features in CSS – allowing us to target elements for styling based on a whole range of details. We can use them to represent state, enforce accessibility patterns, manage content flow and element spacing, incorporate randomness, establish component parameters, and so much more. Most importantly, selectors allow us to define abstracted style patterns that can be written in one place and reused across components.

CSS is designed to be systemic and declarative – giving the browser information about why different styles might be applied in different situations. While we can apply the same styles to .contact–submit__focus or .contact [type='submit']:focus-visible, the former is a meaningless string of characters that we have to define and apply ourselves (often with JS), while the latter conveys detailed information that the browser can use to apply styles on our behalf. The result is more resilient, performant, and readable code.

Selectors are there for a reason, and we should take advantage of their full potential. Instead, we’ve been restricting what selectors are allowed and enforcing more and more limited conventions in an attempt to somehow avoid the cascade. But the cascade is unavoidable; it’s the core of the language. There will always be selector conflicts, and there will always be an algorithm to resolve those conflicts. All we’ve been doing is denying ourselves access to one of the coolest features on the web platform.

I hope that cascade layers can help to turn that trend around.

Miriam selected Colorado Freedom Fund for an honorary donation of $50 which has been matched by

While people with money can pay their way out of jail, poor people don’t have that luxury. CFF is an abolitionist-led non-profit, and a member of the National Bail Fund Network – paying cash bail for our neighbors trapped in Colorado cages.

FormData API

2022-12-16T00:00:00.000Z

Historically, getting all of the data from a form into a single object was a bit difficult, but modern techniques make it a lot easier.

Let’s dig in!

Creating a FormData object

The FormData object provides an easy way to serialize form fields into key/value pairs.

You can use the new FormData() constructor to create a new FormData object, passing in the form to serialize as an argument.

For example, let’s imagine you have a form that looks like this.

<form>
    <label for="title">Title</label>
    <input type="text" name="title" id="title" value="Go to the beach">

    <label for="body">Body</label>
    <textarea id="body" name="body">Soak up the sun and swim in the ocean.</textarea>

    <input type="hidden" name="userId" value="1">
    <button>Submit</button>
</form>

To create a FormData object, you would pass the form into the new FormData() constructor, like this.

// Get the form
let form = document.querySelector('form');

// Get all field data from the form
// returns a FormData object
let data = new FormData(form);

The FormData object is an iterable.

You can loop through it using a for...of loop. Each entry is an array of key/value pairs.

// logs...
// ["title", "Go to the beach"]
// ["body", "Soak up the sun and swim in the ocean."]
// ["userId", "1"]

for (let entry of data) {
    console.log(entry);
}

Here’s a demo for you to play with.

You can also use array destructuring to assign the key and value to their own variables within the for...of loop.

// logs "title", "Go to the beach", etc.

for (let [key, value] of data) {
    console.log(key);
    console.log(value);
}

Here’s another demo, with array destructuring.

Getting, setting, and updating FormData values

The FormData object has a handful of methods that you can use to get, set, and update values.

The FormData.get() method accepts the name of the field as an argument and returns its value. Here, we would get the value of the [name="title"] field.

// returns "Go to the beach"
let title = data.get('title');

If you had multiple fields with the same name, you might instead use the FormData.getAll() method. It returns an array of values instead.

// returns ["Go to the beach"]
let titles = data.getAll('title');

You can use the FormData.set() method to add a new value to your FormData object. If an entry with that name already exists, the FormData.set() method overwrites it.

Pass in a name and value as arguments.

// Add a new entry, "date", to the FormData object
data.set('date', '2022-12-25');

// Overwrite the "id" entry
data.set('id', '42');

The FormData.append() method adds an additional value for an existing entry if one with that name already exists. If not, it creates a new entry.

Pass in a name and value as arguments.

// Adds an additional "id" value
data.append('id', '123');

// Creates a new entry, "tags"
data.append('tags', 'vacations');

The FormData.delete() method deletes all values for an entry.

Pass in the name of the item to delete as an argument.

// Deletes the "body" entry
data.delete('body');

Here’s a demo with all of the methods for manipulating FormData values.

It’s worth noting that all of these changes happen to the FormData object and its values, not the actual form element or its fields.

None of these methods will update the state of the DOM or UI.

Convenience methods

The FormData object also provides a few convenient methods for working with form data.

The FormData.has() method can be used to check if a FormData object contains an entry with a specific name.

It returns a boolean: true if the entry exists and false if it does not.

// returns true
let hasID = data.has('id');

The FormData.keys() method returns an iterator with all of the keys in the FormData object.

You can loop them with a for…of loop, or convert them into an array using the Array.from() method.

// Loop through all keys
for (let key of data.keys()) {
  console.log(key);
}

// Convert to an array
let arr = Array.from(data.keys());

Here’s a demo of the FormData.keys() method.

The FormData.values() method returns an iterator with all of the values in the FormData object.

// Loop through
for (let val of data.values()) {
  console.log(val);
}

// Convert to an array
let arr = Array.from(data.values());

Here’s a demo of the FormData.values() method.

Serializing FormData into an object

You might intend to pass your FormData object along to an API.

While some APIs will accept a FormData object in its native form, many require you to pass along an object instead.

If your form does not contain multiple fields with the same name, you can use the Object.fromEntries() method to convert your FormData object into a plain object ({}).

// returns...
// {
//   title: "Go to the beach",
//   body: "Soak up the sun and swim in the ocean",
//   id: "1"
// }

let serialized = Object.fromEntries(data);

However, if your form has multiple fields with the same name, only the value of the last field with that name will appear in the object.

We instead need to loop through each entry with a for...of loop and add it to an object.

let obj = {};

for (let [key, value] of data) {
    obj[key] = value;
}

To account for multiple fields with the same name, we need to check if the key already exists in the obj.

If it does, we want to convert it to an array and Array.push() the new value into it.

let obj = {};

for (let [key, value] of data) {
    if (obj[key] !== undefined) {
        if (!Array.isArray(obj[key])) {
            obj[key] = [obj[key]];
        }

        obj[key].push(value);
    } else {
        obj[key] = value;
    }
}

If you find yourself doing this often, I’ve put together a helper method you can use.

Once you have your object, you can pass it into the JSON.stringify() method to send along to an API.

let stringified = JSON.stringify(obj);

Serializing FormData into a query string

Some APIs instead require data as a query string.

let str = 'key=some+value&another-key=some+other+value';

To convert our FormData object into a query string, we’ll use the URLSearchParams().

It provides methods for getting, setting, and modifying query string values and has a similar API as the FormData object.

First, we’ll use the new URLSearchParams() constructor to create our query string object.

let params = new URLSearchParams();

Next, we’ll loop through each item in our FormData object with a for…of loop, and use the URLSearchParams.append() method to add the key and val to our query string.

The URLSearchParams.append() method automatically encodes the value for us.

for (let [key, val] of data) {
  params.append(key, val);
}

Finally, we can use the URLSearchParams.toString() method to get the actual query string.

let str = params.toString();

Here’s a demo of the URLSearchParams object.

Wrapping up

We covered a lot in this article, so let’s quickly wrap up what we learned.

To get a serialized object of your form fields, pass the form element into the new FormData() constructor.
You can get, set, and update values using the get(), getAll(), set(), and delete() methods.
The has(), keys(), and values() methods provide an easy way to check if a value exists and get all of the keys or values from a FormData object.
You can serialize form values to a plain object using the Object.fromEntries() method or by looping through each entry and adding it to an object.
You can serialize form values into a query string using a for…of loop and the URLSearchParams API.

If you enjoyed this, you might also like my Daily Developer Tips newsletter. Each weekday, I send out a short email on how to build a simpler, more resilient web.

Chris selected Feeding America for an honorary donation of $50 which has been matched by

CSS image()

2022-12-15T00:00:00.000Z

What is the image() function?

When we declare a background-image, we use the url() function to tell the browser where it can find the image.

While very useful, url() has some limitations that can sometimes result in hacky solutions, so as part of the level 4 spec for CSS Image Values and Replaced Content, the working group has introduced the image() function.

While at first glance it is very similar to url(), it opens up some new doors as it can allow us to define:

Image fragments. These allow us to define a specific part of the image that should be visible rather than the entire image (this is also being added to url() but with a slight drawback which we’ll talk about).
The directionality of the image. This might sound strange but could prove very useful in some situations.
A solid color to use as a fallback if the image fails to load, or even to define the background itself without an image. On first glance, this sounds a little pointless, but it might be my favorite use case for image().

The very basics of image()

The image() function can accept three optional values:

A tag for image directionality (either ltr or rtl)
An image source
A color

Because everything is optional, it can look a lot like url() at first:

.keeping-it-simple {
  background-image: image("images/my-image.webp");
}

Image fragments

When we provide the URL for the image, we can add a media fragment identifier to display only a portion of the image rather than the entire thing.

We do this by supplying an x and y coordinate, which are the starting point, followed by a width and height.

We do this by appending the information after the URL with a #xywh= followed by the values we want to use for the starting coordinates, width, and height.

.hero {
  background-image: image("images/my-image.jpg#xywh=150,50,500,300");
}

In the example above, we would start in the top-left corner, move 150 pixels across and 50 pixels down, and then select the region that would be 500px wide by 300px tall from that starting point.

Use cases for image fragments

One thing that might come to mind is being able to use one image and crop it in different ways within a media query. However, this means you are loading in a larger image than is required, and you might be better served using the <picture> element, which allows for different sources based on the viewport size.

If you are using the same image multiple times within a page and need to crop it in different ways, image fragments would be a lot easier than working with background-size and background-position and would allow you to load in one single image rather than multiple different versions of it.

Another use case would be image sprites, where we can simplify how we have traditionally done them using background-position.

.icon-1 {
  background-image: image("images/icon-sprite.png#xywh=0,0,16,16");
}

.icon-2 {
  background-image: image("images/icon-sprite.png#xywh=16,0,16,16");
}

.icon-3 {
  background-image: image("images/icon-sprite.png#xywh=32,0,16,16");
}

Using pixels or percentage

When we define the fragment, the default units used are pixels, but we can explicitly tell the browser to use percentages instead by including percent: before the coordinates.

.pixel-based-fragment-1 {
  background-image: image("images/my-image.jpg#xywh=20,30,500,300");
}

.pixel-based-fragment-2 {
  background-image: image("images/my-image.jpg#xywh=pixel:20,30,500,300");
}

.percentage-based-fragment {
  background-image: image("images/my-image.jpg#xywh=percent:10,10,70,80");
}

When we do this, all of the coordinates will be a percentage.

That means in the example above, the class .percentage-based-fragment would show 70% of the total width and 80% of the total height of the original image, starting 10% across and 10% down.

The url() function and image fragments

Image fragments have also been added to the url() function.

If a browser doesn’t support image() it simply won’t load the image, whether or not there is a fragment.

When using an image fragment within a url(), if a browser doesn’t support image fragments, it will still load in the image provided in a url(), but the fragment will be ignored, resulting in the entire image loading in.

Depending on the situation—such as with image sprites—this could be problematic.

Instead, we could provide a fallback as a url() for browsers that do not support fragments.

.with-fallback-image {
  background-image: url("images/my-fallback.jpg");
  background-image: image("images/my-image.jpg#xywh=20,30,500,300");
}

Directionality

With the rise of logical properties, it is now easier than ever to deal with different writing directions.

The idea of an image changing directions might seem a little strange, as most images you use shouldn’t be flipped when switching between a left-to-right or right-to-left language.

If we omit a direction tag, then the image is considered to have no directionality, and the writing direction will have no impact on the image.

If you have images or icons that denote directionality, such as an arrow on a bullet list, this feature could be super handy!

Taking that arrow example, you might do something like this:

.arrow-list {
  list-style-image: url('arrow.png');
}

This would work fine until you switch the writing direction, which would result in this:

Using the image() function, we can add directionality to the image by indicating it before the URL with either ltr or rtl for left-to-right or right-to-left.

This defines the original direction of the image, telling the browser that if the writing direction changes from what we have defined, the image should follow that switch.

.arrow-list {
  list-style-image: image(ltr 'arrow.png');
}

Creating a fallback

When we declare a background-image it is a good idea to provide a solid color fallback in case the image doesn’t load so that we can ensure any text that would be on top of the image is still readable.

Using image(), we can do this by simply providing a color along with our URL.

.with-fallback-color {
  background-image: image("images/my-image.jpg#xywh=20,30,500,300", #123456);
}

Being able to declare a fallback color is already very handy, but it also opens up another possibility that I’m very excited by.

Tinting an image

A common complaint about background images is that there is no easy way to reduce their opacity.

Either we need to open up some editing software or use a pseudo-element as a layer between our background and the content.

This is because if we have a background-color and a background-image, the image is always on top of the color.

We can use a background-blend-mode to blend the two, but this can be hit-and-miss, and the effect can change drastically from one image to another.

One useful thing we can do with background-image is stack multiple images on top of one another, and because image() allows us to declare a solid color, that color can be part of that stack of images.

We can use this to tint an image by putting the top layer in our stack as a solid color with a reduced opacity.

.tinted-bg-image {
  background-image: image(hsl(210 47% 20% / .75)), url("images/my-image.jpg");
}

With this, we can tint an image quickly with any color we want, including the same color we’ve used as the background to simply make the image look like it has a lower opacity on it.

.tinted-bg-image {
  background-image: image(hsl(210 47% 20% / .75)), url("images/my-image.jpg");
}

.fake-low-opacity-bg {
	background-image: image(hsl(0 0% 100% / .8)), url("images/my-image.jpg");
}

Wrap up

CSS seems to be evolving at a faster pace than ever, with a few big features, like :has() and container queries getting a lot of attention (with good reason, they’re amazing).

While I’m looking forward to a lot of the big new things as well, things like image() often go under the radar but end up being those little things that improve how CSS works at its core.

By being able to easily bring in image fragments instead of having to fight with background-position and background-size, providing fallback colors, and enabling layers of images and colors, those of us who author CSS are gaining a lot of small quality-of-life things that, over time, we’re sure to simply take for granted.

Additional resources

Kevin selected CHU Sainte-Justine Foundation for an honorary donation of $50 which has been matched by

Support CHU Sainte-Justine in its pursuit of excellence and its commitment to providing children and mothers with one of the highest levels of health care in the world, now and in the future.

View Transitions API

2022-12-14T00:00:00.000Z

Using creative animations can provide enjoyable and memorable user experiences in many ways:

Animating loaders while data is being loaded
Micro-interactions to reveal or hide sections of pages
Increase the perceived performance of a site or application

State changes, more specifically page transitions, are rather difficult to animate, however. There are several third-party JavaScript packages for managing page transitions, but there has not been a solid native solution to this as of yet.

The W3C CSS Working Group is currently working on a draft specification for a new native API for page transitions called View Transitions.

Browser Compatibility

At the time of writing, the View Transitions API is unsupported in all major browsers as it is an extremely experimental feature within Chrome and is subject to change.

To enable this feature: you must be on Chrome (Canary) 109 or greater and enable the View Transitions feature flag at chrome://flags/#view-transition.

Basic example

A very basic example of View Transitions follows this pattern:

const viewTransition = () => {
  if (!document.startViewTranstion) {
    // handle unsupported browsers
  }

  document.startViewTransition(() => thingToTransition());
};

Inside the .startViewTransition() method, you can pass in any type of DOM manipulation you want. You aren’t limited to just page transitions here; you can also move elements from one parent element to another, add or remove elements, toggle classes, and more.

Once the .startViewTransition() method is called, the View Transitions API creates snapshots of both the current state and the state that is being transitioned to, then performs the transition between the two.

The default animation used in View Transitions is a crossfade animation, which looks something like this:

While the transition is occurring, a set of pseudo-elements is provided that we can use to customize the transition.

Customizing Transitions

The pseudo-elements provided by the View Transitions API are organized into a tree, like so:

::view-transition
└─ ::view-transition-group(root)
    └─ ::view-transition-image-pair(root)
       ├─ ::view-transition-old(root)
       └─ ::view-transition-new(root)

These pseudo-elements can be used inside CSS to create more customized animations to occur during the transition. An important thing to note here is root refers to the default transition. Currently, this means everything being transitioned is the root transition. We can have multiple transitions by setting view transition names, where we can apply different animations to different transitions (more on that in a bit).

A simple test customization is changing the animation duration via CSS, like so:

::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 5s;
}

This will slow down the crossfade animation to 5 seconds:

While the transition is slowed down, you can really see what is happening here: ::view-transition-old(root) is fading out the current state, while ::view-transition-new(root) is fading the new state in.

A smoother transition might be expanding the image to full size after clicking on a thumbnail. To do this, we need to set a few other CSS properties on the elements that are targeted during the transition.

There are actually multiple elements being transitioned here: the thumbnails on the gallery page and the full-sized image on the image page.

In our example, the thumbnail images are selected by targeting .gallery-item img. We will need to apply the contain: layout property to these thumbnail images like so:

.gallery-item img {
  /* ...other styles */
  contain: layout;
}

The contain property indicates that the element is as independent as possible from the rest of the page. The layout value isolates the element’s internal layout, preventing anything from the outside from affecting its internal layout. This is helpful as the layout of the element being transitioned needs to remain intact during the transition.

For the full-sized image, we will give it the contain: layout property as well, but we also want to apply a unique name to the view transition. We can do so by giving it the CSS property view-transition-name:

.full-size img {
  view-transition-name: full-size;
  contain: layout;
}

With just this CSS, we have actually accomplished the effect we are aiming for!

Applying a transition name will separate the transitions a bit, giving us a little more flexibility regarding how each transition can be animated. Now we can target both the root transition as well as the full-size transition when applying animations:

::view-transition-old(root),
::view-transition-new(root) {
  /* CSS animations styles for root */
}

::view-transition-old(full-size),
::view-transition-new(full-size) {
  /* CSS animations styles for full-size */
}

Completed transition:

Further Information

You will need Chrome Canary to test this with, but feel free to check out the source for the demo on Github.

This is a super exciting feature, and I’m looking forward to when we can implement this on production sites.

For more information on View Transitions, check out Jake Archibald’s article on the topic below, as it is currently the main reference for the API.

Other Resources:

Ryan selected The Trevor Project for an honorary donation of $50 which has been matched by

The Trevor Project’s mission is to end suicide among LGBTQ young people.

New Viewport Units

2022-12-13T00:00:00.000Z

Once upon a time, web designers worried about browser window sizes—was the site supposed to be 640x480, 800x600, 1024x768? Even, dare we hope, 1280x960? And we fretted over whether a scrollbar would show or not, because that might throw off the horizontal layout space by a few pixels.

But then came Responsive Web Design, where we freed ourselves from those pixel plateaus and plunged headlong into the world of infinite diversity in infinite device displays. Once we were setting breakpoints and writing styles for whole strata of screen sizes at a time, our past preoccupations with a single scrollbar seemed silly.

There was a serpent in the Garden of E-mail, though. If you’ve used a mobile web browser in the past decade or so, you know they have a tendency to slide the URL bar and navigation buttons in from the top and bottom of the viewport when needed, and away when not. It’s a nice way to balance the desire for maximum reading space and access to browser chrome. But it raises the question: what defines the viewport? Is it the display space the browser UI hidden? The space between them when they appear? Both? Neither?

This matters because of viewport units like vh (viewport height) or vb (viewport block). If you set an image to be 100vh tall, trying to fill out the height of the viewport, will it actually fill the whole display? Will it shrink a bit to fit between the browser bars when they appear, or will it be overlapped? Should it instead be the minimum available height when the browser UI is visible, thus leaving it shorter than the display when the chrome is gone?

What if you want access to all those behaviors?

Enter the large, small, and dynamic viewports.

A diagram shows the difference between the "large viewport" and "small viewport", where the large occupies the space when dynamic UI is hidden and the small occupies the space when dynamic UI is visible. Large units are displayed as lvh and lvb for the height/block direction, and lvw and lvi for the width/inline direction. Small units are displayed as svh and svh for the height/block direction, and svw and svi for the width/inline direction.

Large Viewport

The large viewport is the viewport without any dynamic browser interface showing. On a mobile device, that would generally be the entire display surface, so setting an element to be 100lvh and 100lvw means it will be the same size as the device display.

A good use case for the large viewport is an illustration or “cover page” at the beginning of an article, sized to cover some or all of the entire viewport, where it’s okay if some parts are overlapped by the browser interface. A three-quarter-screen page might get CSS something like this:

article > header {
  width: 100lvw;
  height: 75lvh;
  background-image: url(cover-illo.jpg);
  background-size: cover;
}

So, if you plan to use the large viewport units, you should probably make sure your coding font makes clear the difference between 1 (one) and l (lowercase L), or else you might think you’ve specified 1,001 vw or 751 vh.

Small Viewport

Anyway, the small viewport is the viewport with all the dynamic browser interface showing. Therefore, setting an element to be 100svh and 100svw means it will be exactly sized so that it will fit inside all the dynamic browser interfaces.

A good use case for the small viewport would be sizing a dialog so that no part of it can ever be overlapped by the browser interface, which is important for dialogs that have “X to dismiss” or similar. So you might style such a thing like this:

.warning {
  width: 40em;
  height: auto;
  max-width: 100svh;
  max-height: 100svh;
}

Dynamic Viewport

If you want something to resize itself as the browser interface elements appear and disappear, you size with regard to the dynamic viewport. An element 100dvh and 100dvw will be exactly the same size as whatever part of the viewport is visible between browser interface elements. If there are none, the dynamic viewport is the same size as the large viewport. If all the browser interface is visible, the dynamic viewport is equal to the small viewport.

Keep in mind that as browser interface elements appear and disappear, the dynamic viewport will change from moment to moment, which means the exact length of the dvh and dvw units will change from moment to moment. This, in turn, means anything sized using those units will change, sort of like an interface-linked animation.

Picture it: a user starts to scroll a page on a mobile device, causing the URL bar and navigation bar to slide away. Anything sized using dynamic viewport units will resize even as the page is scrolling and the viewport is changing. This could be a significant performance hit, and even if not, the visual effect could be unsettling, potentially triggering users with vestibular disorders or epilepsy.

Using New Viewport Units

Although these may seem very mobile- or at least handheld-centric, these units may become more handy for desktop and embedded contexts over time. Desktop browsers may become more like their mobile counterparts in terms of setting dynamic UI elements, and embedded-display browsers on things like home appliances or auto dashboard displays (which one could think of as mobile devices, in their own way) could very well use dynamic UI conventions.

Given all that, it’s definitely worth getting comfortable with these new viewports and their units. And here they are, spread out in a holiday table for you.

Viewport	Large	Small	Dynamic
height	lvh	svh	dvh
block axis	lvb	svb	dvb
width	lvw	svw	dvw
inline axis	lvi	svi	dvi
minimum axis	lvmin	svmin	dvmin
maximum axis	lvmax	svmax	dvmax

You can use these new viewport units today as a progressive enhancement by also including the stable unit in the corresponding direction, example:

.cover-dynamic-viewport {
  width: 100vw;
  width: 100dvi;
  height: 100vh;
  height: 100dvb;
}

Eric selected Rebecca’s Gift for an honorary donation of $50 which has been matched by

The money raised by Rebecca’s Fund will be added to the St. Baldrick’s efforts to fund promising research in the prevention of tumor reemergence.

Container Queries

2021-12-24T00:00:00.000Z

Updated September 2022

CSS Container Queries are an upcoming way to move beyond media queries that are tied to the viewport and instead will enable us to modify an element's behavior based on the container it's within. This has been a requested feature for many years, with developers desiring to change an element based on its own width. However, the in-progress spec will allow querying for other property values - including from custom properties - to alter a component.

Back in May, I wrote "A Primer on CSS Container Queries" and since that time the spec has moved into being a Public Working Draft and some of the syntax has been updated.

Enabling container queries

If you would like to view the demos in this article and experiment with container queries yourself, you'll need to be on a supporting browser:

All nightly versions
Chromium 105+
Safari 16+

Defining containment

Given that the container query spec is not final, keep in mind that the syntax discussed in this post is at risk of changing.

A key concept of container queries is that you must explicitly define which elements allow containment. Then you query against those containers which allow you to affect the properties of its children. This can be a bit of a gotcha, which we'll look at in action a bit later.

At minimum for queries intended to be based on width, containment is defined by setting container-type: inline-size on a containing element.

main {
  container-type: inline-size;
}

Optionally, you can also name your container with container-name which is useful if you have several layers of containment so that you can be more explicit about which queries affect elements.

Both type and name can be defined using the shorthand container property, where the name is first and separated from the type by a forward slash.

main {
  container: main / inline-size;
}

If a container query is applied to an element that has no defined containing ancestor, the query will fail to apply. In other words - there is no default fallback containment on either the body or html elements.

Defining a container query

Now that we know how to apply containment to an element, we're ready to actually write a container query!

Eventually, we'll be able to not just query based on size but also style properties (at time of writing, querying on style was not yet supported).

With our current container-type using inline-size, we'll write our first query. We'll also explicitly query against our named container of "main". If we left off the name, this query would be against the h2's nearest ancestor with containment.

@container main (width >= 40ch) {
  h2 {
    color: blue;
  }
}

Oh, and what's that? A new syntax for the query definition using math comparisons? Oh yes! This is an update that will be coming to "old fashioned" media queries against the viewport as well! Thanks, CSS Working group 🥰

Demo of responding to size containment

Let's put the pieces we've learned so far together. For myself, so far treating container queries similar to the idea of "mobile first" has made the most sense in developing my "breakpoints" across component states. By which I mean styling for the narrowest view as the default then handling updates for larger widths via the container queries.

We'll be using CSS grid and grid areas to adjust a card layout, and particularly to update the card image location and aspect ratio.

Narrow container card styles

For the narrowest expected container, our card elements simply stack and the image is set at aspect-ratio: 4/3.

Our initial HTML is very simple:

<div class="card">
  <img src="https://source.unsplash.com/V7SKRhXskv8/400x300" alt="">
  <h3>Container Queries Rule</h3>
  <p>Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?</p>
</div>

Demo of narrowest card styles

.card {
  display: grid;
  gap: 1rem;
  margin: 5vh auto;
  padding: 1rem;
  border-radius: 0.5rem;
  box-shadow: 0 .25rem 0.5rem -.15rem hsla(0 0% 0% / 55%);
}

.card > * {
  margin: 0;
}

.card img {
  max-width: 100%;
  aspect-ratio: 4/3;
  object-fit: cover;
  border-radius: inherit;
}

Container Queries Rule

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?

This may look a little strange if you are viewing this on a larger viewport because the card currently has no width constraints.

I mentioned we'd be updating the card layout using CSS grid template areas, and we want those to apply based on container queries. Let's see what happens if we add containment to the card class, and then add a container query to define the grid template areas.

Demo of applying containment to .card

.card--contained {
  container-type: inline-size;
}

@container (width >= 30ch) {
  .card--contained {
    grid-template-areas: "image title" "content content";
  }
}

Container Queries Rule

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?

If you're in a browser with container query enabled, you might be surprised that no change has occurred... unless you remember the "gotcha" I noted earlier.

Since an element can't change its properties within a container query unless it has an ancestor with containment, our attempt at updating the display of the card was unsuccessful.

In this case, we need to add a wrapping element to provide containment. Let's make that adjustment to our HTML and then adjust the styles. Note that the demo styles require a bit of extra scoping to be able to show the change from the previous state.

<div class="card-container">
  <div class="card">
    <img src="https://source.unsplash.com/V7SKRhXskv8/400x300" alt="">
    <h3>Container Queries Rule</h3>
    <p>Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?</p>
  </div>
</div>

Demo of adding a wrapping element with containment

.card-container {
  container-type: inline-size;
  margin: 0;
}

@container (width >= 30ch) {
  .card-container .card {
    grid-template-areas: "image title" "content content";
    grid-auto-columns: 33% 1fr;
    align-items: center;
  }
  
  .card-container .card p {
    grid-area: content;
  }
  
  .card-container .card img {
    aspect-ratio: 1;
  }
}

Container Queries Rule

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?

Hooray, our query was successfully applied!

You can probably assess that we can improve the layout here even more for larger widths, so let's do that. We'll adjust the template areas so the image takes up the left third and the title and content share the remaining inline space. There is no change needed for our HTML.

Demo of the "large" card container query

@container (width >= 60ch) {
  .card-container--large .card {
    grid-template-areas: "img title" "img content";
  }
  
  .card-container--large .card img {
    grid-area: img;
  }
 
  .card-container--large .card h3 {
    align-self: end;
  }
  
  .card-container--large .card p {
    align-self: start;
  }
}

Container Queries Rule

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?

Multi-card layout

Now, as a standalone card the variations still aren't too impressive, and you may be thinking the container query hasn't added much value.

Let's add a few more cards and place them within a flexbox-based grid layout.

Demo of cards within a flexible grid layout

.card-grid {
  display: flex;
  flex-wrap: wrap;
  gap: 2rem;
  list-style: none;
  padding: 0;
  margin: 0;
}

.card-grid .card-container {
  flex: 1 1 30ch;
}

.card-grid .card {
  margin: 0;
}

Container Queries Rule

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?
Container Queries Rule

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?
Container Queries Rule

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?

If you are unable to use a supporting browser on your device, here's a preview of what these cards look like within the grid. Because of how we've setup our flexbox behavior, when there is enough room the third card can expand fullwidth. So in this preview we see the first and second card have taken on our medium container size and the third has taken on the large container size.

Container query units

Along with the main spec is the inclusion of a new set of units related to the container size.

To me, one of the most exciting applications for these is responsive typography. Today, we can create what's often called fluid typography using the CSS function clamp() and viewport units. But those are not contextually ideal for smaller components like the cards we created since they are tied to the viewport.

We can take our cards one step further by applying the relevant container query unit as a swap for what we previously used a viewport unit for to make our card typography responsive.

We're still using clamp() to provide a range of acceptable values, and the container unit we've selected is cqi which represents increments of 1% of the container's inline size.

Demo of using container units for responsive typography

.card-container--units .card h3 {
  font-size: clamp(1.25rem, 3cqi + 1rem, 2.5rem);
}

.card-container--units .card p {
  font-size: clamp(.9rem, .5cqi + 1rem, 1.5rem);
}

Container Queries Rule

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?
Container Queries Rule

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?
Container Queries Rule

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?

Additional resources on CSS container queries

I hope this overview has sparked your interest in container queries! It's definitely the CSS feature I'm most hopeful will make it into more browsers in 2022.

If you'd like more of a background on what problem container queries are trying to solve and some additional considerations, be sure to read my original primer.

The primary spec author for container queries is Miriam Suzanne, and I highly recommend watching one of her presentations that covers not just CQ but also the other specs she's working on that are very exciting: layers and scope. I also encourage you to read her additional explainer doc.

There is already a page on MDN.

More examples of ways to use container queries (note that not all may have the updated syntax):

Miriam's collection of CodePens
Ahmad Shadeed's overview with practical applications
And even more links to checkout in Stu Robson's repo Awesome-Container-Queries

Form Autocomplete

2021-12-23T00:00:00.000Z

Howdy! Ben here.

This month, deep in the throes of shopping for last-minute gifts online, I've encountered a lot of forms. The thing about forms is they can get repetitive fast. Name, email, phone number, address, billing details… It might be Christmastime, but it's feeling more like Groundhog's Day!

To that end, let's talk about some handy web form APIs that can make forms much more comfortable to fill out: autocomplete and virtual keyboard options.

Autocomplete

This holiday season, give your users the gift of not having to fill out forms themselves! With the <input> element's autocomplete attribute, we can tell our user's browsers which common bits of form data we're expecting, and the browser will give users the chance to populate those fields instantly using values from their previous submissions.

This is commonly used to fill out contact info, such as:

<form>
  <label for="name">Name:</label>
  <input type="text" 
    id="name" 
    autocomplete="name" />
</form>

If we need, we could get individual piece of our user's name with autocomplete="honorific-prefix", "given-name", "additional-name", "family-name", "honorific-suffix", and "nickname" (but beware of misconceptions about how names work):

<form>
  <label for="prefix">
    Honorific Prefix (for example, Ms., Mx., Dr.):
  </label>
  <input type="text" 
    id="prefix" 
    autocomplete="honorific-prefix" />

  <label for="firstName">
    First Name:
  </label>
  <input type="text" 
    id="firstName" 
    autocomplete="given-name" />

  <label for="middleName">
    Middle Name:
  </label>
  <input type="text" 
    id="middleName" 
    autocomplete="additional-name" />

  <label for="lastName">
    Last Name:
  </label>
  <input type="text" 
    id="lastName" 
    autocomplete="family-name" />

  <label for="suffix">
    Suffix (for example, Jr., III, PhD):
  </label>
  <input type="text" 
    id="suffix" 
    autocomplete="honorific-suffix" />

  <label for="nickname">
    Nickname:
  </label>
  <input type="text" 
    id="nickname" 
    autocomplete="nickname" />
</form>

We can help the user autofill their address:

<form>
  <label for="name">
    Name:
  </label>
  <input type="text" 
    id="name" 
    autocomplete="name" />

  <label for="addressLine1">
    Address Line 1:
  </label>
  <input type="text" 
    id="addressLine1" 
    autocomplete="address-line1" />

  <label for="addressLine2">
    Address Line 2:
  </label>
  <input type="text" 
    id="addressLine2" 
    autocomplete="address-line2" />

  <label for="city">
    City:
  </label>
  <input type="text" 
    id="city" 
    autocomplete="address-level2" />

  <label for="state">
    State:
  </label>
  <input type="text" 
    id="state" 
    autocomplete="address-level1" />

  <label for="zip">
    Postal Code/ZIP Code:
  </label>
  <input type="text" 
    id="zip" 
    autocomplete="postal-code" />

  <label for="country">
    Country:
  </label>
  <input type="text" 
    id="country" 
    autocomplete="country-name" />
</form>

… Or their billing information!

<form>
  <label for="name">
    Cardholder Name:
  </label>
  <input type="text" 
    id="name" 
    autocomplete="cc-name" />

  <label for="cardNumber">
    Card Number:
  </label>
  <input type="text" 
    id="cardNumber" 
    autocomplete="cc-number" />

  <label for="cardExpiryMonth">
    Expiration Month:
  </label>
  <input type="text" 
    id="cardExpiryMonth" 
    autocomplete="cc-exp-month" />

  <label for="cardExpiryYear">
    Expiration Year:
  </label>
  <input type="text" 
    id="cardExpiryYear" 
    autocomplete="cc-exp-year" />

  <label for="cardSecurityCode">
    Card Security Code:
  </label>
  <input type="text" 
    id="cardSecurityCode" 
    autocomplete="cc-csc" />
</form>

autocomplete has so many options to give your users a boost when they're filling out forms on your site. You can autofill their birthdays (with "bday" — or "bday-day", "bday-month", and "bday-year"), their phone numbers ("tel"), their username ("username"), and more! It's worth going to MDN to see them all!

Autocomplete for One-Time Codes

While I'm just listing out possible autocomplete values, I'm gonna pause here to geek out about one option I've found especially convenient: autocomplete="one-time-code". This particular value is supported by iOS and Android, and it's meant for when a user is trying to sign in to your site from their phone and they receive a text message with a six-digit one-time code to log in. The user's mobile browser can get that six-digit code from their text messages and fill out the field automatically, so that the user doesn't have to switch between their browser and their texts. See `"one-time-code" in action here!

The web is really cool, sometimes.

Autocomplete and Accessibility

Autocomplete aids accessibility! For instance, for people with motor disabilities and chronic illnesses, who might find filling out large forms difficult or painful, autocomplete can really save time and spoons. It's also less taxing for people with memory issues or anyone whose disabilities make it difficult to read or write.

In fact, using autocomplete values when available is required for meeting WCAG Success Criterion 1.3.5 - Identify Input Purpose. This criterion specifically states that an input's purpose can be "programmatically determined" which is exactly what autocomplete helps do. The criterion also notes that a proper label helps in this goal, for example in clarifying what type of email is required, such as business or personal or someone else's.

Virtual Keyboard Modes

In addition to autocomplete="one-time-code", mentioned above, we devs have more ways to show love to forms in mobile browsers. Specifically, we can give the user's mobile browsers hints as to tweak the on-screen virtual keyboard interface that pops up.

The primary way we tweak this is through the <input>'s type: <input type="text" /> shows the user's normal keyboard, <input type="email"> shows an adjusted keyboard which displays the @ key more prominently, <input type="number"> shows a numeric keyboard, and so forth. Adding the type attribute also hints to the browser that it should apply a bit of validation to those fields before submitting the form.

Thanks to the <input> element's inputmode and enterkeyhint attributes, we can tweak the virtual keyboards further:

inputmode

inputmode can be used to change the virtual keyboard's layout. It typically highlights certain keys for certain kinds of content like type does, but it doesn't enable field validation like type will. Your inputmode options are:

text - the default keyboard
search - for search queries
email - for email addresses
url - for URLs
numeric - for numbers without decimal points
decimal - for numbers with decimal points
tel - for phone numbers

Here's a look at the difference between "numeric" and "decimal" on my iPhone.

The difference is pretty subtle — the decimal example shows a decimal point key in the bottom-left corner of the keypad. It's a little thing, but it can help guide users into supplying the right information.

enterkeyhint

Finally, we're able to tweak the message that shows up in the mobile user's virtual Enter key, thanks to the enterkeyhint attribute, which can be one of the following:

done
enter
go
next
previous
search
send

Here are a few examples of that in action:

Why should we worry about tweaking a single key on our user's virtual keyboard display? Submitting a form, especially a critical, sensitive form, can be nerve-wracking, and our users might be nervous about clicking the wrong button at the wrong time and submitting their form prematurely. By changing the enterkeyhint, we can clue them in to what will happen when they click the button, so they know what's safe or not.

Contact Form demo

The following demo comes from HtmlRecipes.dev with one tweak to not make the button submit the form strictly for demonstration so you can safely test the autocomplete values for the name and email.

Contact form using autocomplete

.demo {
  background-color: lightblue;
  display: grid;
  place-content: center;
}

.contact-form {
  /* demo reset from site styles */
  all: unset;
  max-width: 40ch;
  margin: auto;
  background-color: white;
  padding: 1rem 2rem;
  border-radius: 20px;
  box-shadow: 0 0 #0000, 0 0 #0000, 0 25px 50px -12px rgba(0, 0, 0, 0.65);
}

.contact-form label {
  display: block;
}

.contact-form input {
  width: 100%;
  height: 3em;
  margin-bottom: 1em;
}

.contact-form textarea {
  width: 100%;
}

Bonus tip: Styling form fields

Steph has covered styling form fields over on her series on ModernCSS.dev:

Web Speech API

2021-12-22T00:00:00.000Z

Did you know your browser has speech recognition capabilities? (Well, except Firefox for now).

Similar to the MediaStreams API we learned on Day 6, this API will trigger a prompt to get the user's permission to listen to their microphone. Then we can set up logic to recognize words to send back a response within a chat-like interface.

To help us learn this API, we'll be building a "Chat with Santa" application.

Intro to the Web Speech API

The API has two kinds of functionality - recognition and synthesis (aka text-to-speech, aka speaking text aloud). It's important to know that current implementations in Chromium and Safari/webkit do not allow offline access so the service would not be available for progressive web apps (PWAs).

Additionally, the API is technically in experimental status, which you'll see reflected in the MDN browser compatibility table. But we're here to celebrate what the web is capable of, and this is certainly still an impressive bit of functionality!

"Chat with Santa" features

For our voice-enabled chat with Santa, we'll need the following functionality:

Allow users to start and stop the speech recognition
Evaluate the speech transcript for keywords
Respond in the chat as Santa based on the keywords

Chat application HTML and CSS

As we've done throughout the series, we'll start with the markup and styles.

First up, our HTML, which is quite simply a container, headline, button to start and stop the listening, and an unordered list to populate with the chat messages.

<div class="santa-chat-app">
  <h2>Chat with Santa</h2>
  <button class="santa-listen" data-state="inactive">Start listening</button>
  <ul class="santa-chat"></ul>
</div>

We'll be using mostly flexbox to align our chat elements, and just a touch of flourish provided by a pseudo-element and box-shadow to make the chat messages stand out.

There are two bits of state we'll style for related to when the app is listening for speech. We'll update the color of the button, and add a duo-tone green box-shadow to the chat log as an extra visual cue that listening is active.

The style demo has added the active class to preview that style.

Santa chat styles

.santa-chat-app {
  --santa-red-hue: 10;
  --santa-green-hue: 120;
  --santa-saturation: 90%;
  --santa-red: hsl(var(--santa-red-hue), var(--santa-saturation), 45%);
  --santa-green: hsl(var(--santa-green-hue), var(--santa-saturation), 35%);
  --sanata-green-light: hsl(var(--santa-green-hue), var(--santa-saturation), 85%);

  display: grid;
  gap: 2rem;
  justify-items: start;
  border: 2px solid var(--santa-red);
  border-radius: 0.5rem;
  padding: 2rem clamp(1.5rem, 5%, 2.5rem);
  font-family: system-ui, sans-serif;
}

.santa-chat-app h2 {
  margin: 0;
  color: var(--santa-red);
}

.santa-listen {
  all: unset;
  cursor: pointer;
  color: hsl(var(--santa-green-hue), var(--santa-saturation), 25%);
  border-radius: 0.5rem;
  border: 2px solid;
  padding: 0.25em 0.5em;
}

.santa-listen:is(:focus, :focus-visible) {
  outline: 2px dashed currentColor !important;
  outline-offset: 2px;
}

.santa-listen[data-state=listening] {
  color: var(--santa-red);
}

.santa-chat {
  list-style: none;
  margin: 0;
  padding: 1.25rem 1.5rem;
  justify-self: stretch;
  height: 20em;
  overflow-y: auto;
  border: 1px dashed grey;
  border-radius: 0.5rem;
  display: flex;
  flex-direction: column;
  justify-content: flex-end;
  gap: 0.75rem;
  color: #222;
  font-size: 1.15rem;
}

.santa-chat.active {
  border-color: green;
  box-shadow: 0 0 0 4px var(--sanata-green-light), 0 0 0 6px var(--santa-green);
}

.message {
  position: relative;
  border-radius: 0.75rem;
  padding: 0.5rem 0.75rem;
}

.message::after {
  content: "";
  position: absolute;
  top: 50%;
  right: 0;
  transform: translate(100%, -50%);
  border: 0.5em solid transparent;
}

.message--user {
  align-self: flex-end;
  background-color: var(--sanata-green-light);
  border: 1px solid var(--santa-green);
  box-shadow: 2px 2px 0 var(--santa-green);
}

.message--user::after {
  border-left-color: var(--santa-green);
}

.message--santa {
  align-self: flex-start;
  display: inline-flex;
  align-items: center;
  gap: 0.25em;
  background-color: hsl(var(--santa-red-hue), var(--santa-saturation), 85%);
  border: 1px solid var(--santa-red);
  box-shadow: -2px 2px 0 var(--santa-red);
}

.message--santa::after {
  border-right-color: var(--santa-red);
  left: 0;
  transform: translate(-100%, -50%);
}

.message--santa::before {
  content: "🎅";
  font-size: 1.15em;
  transform: translateY(-5%);
}

Chat with Santa

Hello, Santa!
Ho ho ho - have you been good this year?

Adding Speech Recognition

To prepare our app for speech recognition, we'll initiate a connection as recommended by the MDN docs, including setting our language.

// Configure SpeechRecognition
var SpeechRecognition = SpeechRecognition || webkitSpeechRecognition;
const recognition = new SpeechRecognition();
recognition.lang = "en-US";

Then we'll access the two elements we'll be manipulating - the listen button and the unordered list - as well as create our custom activate and deactivate functions.

// Access chat elements
const listenButton = document.querySelector(".santa-listen");
const speechLog = document.querySelector(".santa-chat");

const activateChat = () => {
  recognition.start();
  listenButton.dataset.state = "listening";
  listenButton.textContent = "Stop listening";
};

const deactivateChat = () => {
  recognition.stop();
  speechLog.classList.remove("active");
  listenButton.dataset.state = "inactive";
  listenButton.textContent = "Start listening";
};

The start() and stop() methods are part of the speech API. We're also toggling the state of the listening button by altering our custom data-state attribute and the actual button text.

You may have noticed we remove the active class for deactivation but don't set it as part of activation. That's because there's an API event we'll use for attaching that state instead - onstart. Functionally for our app, we could place it within activateChat(), but it's useful to know about the onstart event.

recognition.onstart = () => {
  speechLog.classList.add("active");
};

In addition to onstart, we have two events that can signal that the API has stopped listening. The first is when the user actually stops talking which is onspeechend. The other is triggered when the API hits a timeout which in Chrome for example seems to be 60 seconds. This timeout seems to be more of a "session" time before the API requires the user to re-initiate the action to start the recognition.

We'll set both of these events to use deactivateChat() so that the app doesn't falsely appear to be listening.

recognition.onspeechend = () => {
  deactivateChat();
};

recognition.onend = () => {
  deactivateChat();
};

Speaking of the user initiating recognition - it's time to finally hook up our listening button. We'll use a simple click handler and check for the current data-state to continue with either activating or deactivating recognition.

listenButton.addEventListener("click", () => {
  const state = listenButton.dataset.state;

  if (state === "inactive") {
    activateChat();
  } else {
    deactivateChat();
  }
});

Providing the user's speech result

At this stage, you could test our app and you would get the prompt for permission to access your microphone. But we need to connect the pieces to be able to output what you say and have Santa give a response.

This will be done via the onresult event of the speech API. This is triggered when the recognition determines that a user has stopped speaking and has evaluated the speech. The important part here is the returned transcript value.

recognition.onresult = function (event) {
  // get the results of the speech recognition
  const transcript = event.results[0][0].transcript;
};

Once we have the transcript value, we'll output that back to the user so they can see what was "heard" by the recognition. We'll do this by creating a new list element with the user classes and appending it to the list.

// Create element for user message
const newMessage = document.createElement("li");
newMessage.classList.add("message", "message--user");
const newMessageTranscript = document.createTextNode(transcript);
newMessage.appendChild(newMessageTranscript);

// Add transcript to DOM
speechLog.append(newMessage);

Responding to recognized words and phrases

To create the illusion of Santa typing back, we'll set a small timeout then pass the transcript off to a function we'll create to handle the responses. This should be placed as the last thing in the onresult event function.

setTimeout(() => {
  handleSantaResponse(transcript);
}, 500);

We'll kickstart the response function by adding a new list element populated with ellipses to allude to Santa "typing" a new message.

const handleSantaResponse = (transcript) => {
  const newResponse = document.createElement("li");
  newResponse.classList.add("message", "message--santa");
  const typing = document.createTextNode("...");
  newResponse.appendChild(typing);
  speechLog.append(newResponse);
});

Then, to better be able to match against the transcript, we'll transform it to lowercase, remove punctuation, and trim extra whitespace.

transcript = transcript
  .toLowerCase()
  .replace(/[\.\?,!]/gm, "")
  .trim();

To prepare for responding, we'll setup a default response if there are no matches. We'll also have a default delay and a boolean to indicate if we should continue with listening or not. The delay will be modified to add a touch of "realness" of having Santa think about his response.

let santaResponse = "Happy Holidays!";
let delay = 800;
let continueChat = true;

Then we'll have a series of simplistic searches for words and phrases to then alter the santaResponse, etc. Here's the initial one anticipating a greeting.

if (transcript.includes("hello") || transcript.includes("hi")) {
  santaResponse = "Ho ho ho - have you been good this year?";
  delay = 1200;
}

In the full demo you can see the other types of prepared responses. But I recommend keeping it hidden until you've tried out the chat first 😉

After our prepared responses, we update the textContent of the list item we created and populated with ellipses earlier.

setTimeout(() => {
    newResponse.textContent = santaResponse;

    if (continueChat) {
      activateChat();
    } else {
      deactivateChat();
    }
  }, delay);

We also automatically begin speech recognition as long as continueChat is true. The one instance where continueChat would not be true is when the user says "goodbye" or "bye". However, the API may experience a session timeout before that point which would trigger the onend event and the user would have to re-initiate the chat via the listen button.

That completes the setup for our Santa chat app! Try it out in the demo.

In my testing, you'll get the best results in Chromium. Safari seemed to take longer to respond and sometimes provided duplications in the transcript.

Demo of Santa Chat speech recognition application

// Configure SpeechRecognition
var SpeechRecognition = SpeechRecognition || webkitSpeechRecognition;
const recognition = new SpeechRecognition();
recognition.lang = "en-US";

// Access chat elements
const listenButton = document.querySelector("#demo .santa-listen");
const speechLog = document.querySelector("#demo .santa-chat");

const activateChat = () => {
  recognition.start();
  listenButton.dataset.state = "listening";
  listenButton.textContent = "Stop listening";
};

const deactivateChat = () => {
  recognition.stop();
  speechLog.classList.remove("active");
  listenButton.dataset.state = "inactive";
  listenButton.textContent = "Start listening";
};

recognition.onstart = () => {
  speechLog.classList.add("active");
};

recognition.onspeechend = () => {
  deactivateChat();
};

recognition.onend = () => {
  deactivateChat();
};

listenButton.addEventListener("click", () => {
  const state = listenButton.dataset.state;

  if (state === "inactive") {
    activateChat();
  } else {
    deactivateChat();
  }
});

recognition.onresult = function (event) {
  // get the results of the speech recognition
  const transcript = event.results[0][0].transcript;

  // Create element for user message
  const newMessage = document.createElement("li");
  newMessage.classList.add("message", "message--user");
  const newMessageTranscript = document.createTextNode(transcript);
  newMessage.appendChild(newMessageTranscript);

  // Add transcript to DOM
  speechLog.append(newMessage);

  setTimeout(() => {
    handleSantaResponse(transcript);
  }, 500);
};

const handleSantaResponse = (transcript) => {
  const newResponse = document.createElement("li");
  newResponse.classList.add("message", "message--santa");
  const typing = document.createTextNode("...");
  newResponse.appendChild(typing);
  speechLog.append(newResponse);

  transcript = transcript
    .toLowerCase()
    .replace(/[\.\?,!]/gm, "")
    .trim();

  let santaResponse = "Happy Holidays!";
  let delay = 800;
  let continueChat = true;

  if (transcript.includes("hello") || transcript.includes("hi")) {
    santaResponse = "Ho ho ho - have you been good this year?";
    delay = 1200;
  }

  if (
    transcript === "yes" ||
    transcript.includes("been good") ||
    transcript.includes("yes i have") ||
    transcript.includes("i guess so") ||
    transcript.includes("maybe")
  ) {
    santaResponse = "Oh, jolly good! You'll have a full stocking!";
    delay = 1000;
  }

  if (
    transcript === "no" ||
    transcript.includes("been bad") ||
    transcript.includes("no i") ||
    transcript.includes("naughty")
  ) {
    santaResponse = "Oh dear! Rudolph will be sorry to hear that.";
    delay = 1000;
  }

  if (transcript.includes("thank you")) {
    santaResponse = "Of course! Anything else you want?";
  }

  if (
    transcript.includes("how are you") ||
    transcript.includes("you doing") ||
    transcript.includes("you busy")) {
      santaResponse = "Feeling jolly! What do you want this year?";
      delay = 1200;
  }

  if (
    transcript.includes("i want") ||
    transcript.includes("i'd like") ||
    transcript.includes("i would like") ||
    transcript.includes("can i have")
  ) {
    santaResponse = "That's quite a list, the elves and I will do our best!";
    delay = 1200;
  }

  // includes does partial matching so this also works for "goodbye"
  if (transcript.includes("bye")) {
    santaResponse = "Ho ho ho - See ya real soon! Don't forget my cookies!";
    continueChat = false;
  }

  setTimeout(() => {
    newResponse.textContent = santaResponse;

    if (continueChat) {
      activateChat();
    } else {
      deactivateChat();
    }
  }, delay);
};

Chat with Santa

Additional resources for the Web Speech API

Given the experimental status and inability to work offline, the speech API isn't really ready to perform critical functions. But it can be fun for personal projects or for a limited well-known audience.

Review all of the web speech API capabilities on MDN
Alvaro Montoro created a virtual assistant for his wife to use to help teach Spanish which includes the speech synthesis functionality to actually vocalize the responses.
Louis Hoebregts worked with Alex Trost to build a voice-powered image search that connects to the Unsplash API
On day 20 of Wes Bos' free JavaScript 30 course, you'll learn how to receive continuous speech results for building out things like a to-do list

CSS Animation

2021-12-21T00:00:00.000Z

Let's get right to it! We'll review:

Transitions and Transforms

Animating by transitioning transforms is the most performant way to apply subtle movement. It's often used to transition between states such as for an interactive element's hover or focus state. Transforms can also be used to provide "entrance" and "exit" animations.

Here's a selection of 4 transition utility classes using transforms that come from one of my other projects, SmolCSS. We're triggering the transition of the child elements on :hover of the parent. The reason for this is that for transitions that move the element, it could end up moving out from under the mouse and causing a flicker between states. The rise transition is particularly in danger of that behavior.

We're also wrapping our effect class in a media query check for prefers-reduced-motion: reduce that instantly jumps the transition to the final state. You can learn more about why this is important on Day 7 about preference queries.

Transition utility classes

.smol-transitions {
  display: grid;
  place-content: center;
}

.smol-transitions > * {
  --transition-property: transform;
  --transition-duration: 180ms;

  transition: var(--transition-property) var(--transition-duration) ease-in-out;
  background-color: lightblue;
  padding: 0.25em;
  font-size: 1.35rem;
  border-radius: 0.25rem;
}

.rise:hover > * {
  transform: translateY(-25%);
}

.rotate:hover > * {
  transform: rotate(15deg);
}

.zoom:hover > * {
  transform: scale(1.3);
}

.fade > * {
  --transition-property: opacity;
  --transition-duration: 500ms;
}

.fade:hover > * {
  opacity: 0;
}

@media (prefers-reduced-motion: reduce) {
  .smol-transitions > * {
    --transition-duration: 0.01ms;
  }
}

/* demo dispay */
.smol-flexbox-grid {
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
  list-style: none;
  padding: 0;
  margin: 0;
}

.smol-flexbox-grid > * {
  flex: 1 1 20ch;
  margin: 0;
}

.smol-transitions {
  padding: 1rem;
  border: 2px dashed;
  border-radius: 0.5rem;
}

rise
rotate
zoom
fade

Keyframe Animations

The next step up from transitions and transforms is keyframe animations

Keyframes are defined as different steps from 0 to 100% which correspond to that point along the duration of the animation. For example for a 400ms animation, 25% would correspond with the 100ms point.

Typically an animation moves smoothly (aka "tweens") between the keyframes, but you can also use the step() timing function to move sharply between them. This is desirable for something like sprite animation for characters to create a walking sequence.

This demo shows an example of a default tweened animation and a stepped animation. We're using the animation shorthand, and you can review all the animation options on MDN.

Demo of tweened vs. stepped animation timing

.keyframe-animations {
  display: grid;
  gap: 1rem;
}

.animated {
  position: relative;
  left: 0;
  width: 12ch;
  padding: 0.15em;
  text-align: center;
  background-color: lightblue;
  animation: glide 5000ms var(--timing-function, linear) infinite;
  animation-play-state: var(--play-state, paused);
}

.stepped {
  --timing-function: steps(4);

  background-color: goldenrod;
}

@keyframes glide {
  50% {
    background-color: palevioletred;
  }
  100% {
    left: calc(100% - 12ch);
    background-color: unset;
  } 
}

document.addEventListener("click", (e) => {
  const animation = e.target.dataset.animate;

  if (animation) {
    const playpause = e.target;
    const isPlaying = playpause.dataset.state === "playing";
    const animate = document.querySelector(animation);

    if (isPlaying) {
      animate.style.setProperty('--play-state', 'paused');
      playpause.dataset.state = 'paused';
      playpause.textContent = "Play animation";
    } else {
      animate.style.setProperty('--play-state', 'running');
      playpause.dataset.state = 'playing';
      playpause.textContent = "Pause animation";
    }
  }
});

I'm tweened

I'm stepped

Learn more about how to think about and create keyframe animations from Amit Sheen at LondonCSS.

Motion animation with offset-path

CSS motion path allows moving an object along a path which is drawing using SVG path syntax. Previously called motion-path, the current critical property is now offset-path. It is at least partially supported in Chromium and Firefox with Safari support on the way (currently in the technical preview).

While there are times this can remove the need for a heavier JS library solution, the biggest drawback is lack of built-in native support for scaling the path or making it relative to a container. Depending on your viewport width, you may or may not see the entire timeline of the demo. Michelle Barker has a resizing solution via scaling, and Jhey provides a tutorial as well as library to accomplish responsive resizing of the path.

Additionally, SVG path syntax can be tricky, especially if you do not have a vector drawing program. An online tool I found useful in creating the demo was SvgPathEditor.

In the following demo, if you are on iOS or Safari 15.2 or less, you will see the fallback to using CSS transitions and transforms.

Michelle has also written a much more comprehensive overview of CSS Motion Path with several great demos.

Demo of offset-path animating Santa's sleigh

.sleigh-ride {
  height: 180px;
  overflow: hidden;
  background-color: lightblue;
}

.sleigh-ride img {
  offset-path: path('M -1 120 s 165 -5 346 -32 s 179 9 411 25');
  animation: ride 6000ms ease-in-out var(--play-state, paused);
  transform-origin: left center;
  opacity: 0;
}

@supports not (offset-path: path('M 1 1')) {
  .sleigh-ride img {
    --sleigh-position: 100%;
    --sleigh-transform: translateY(25%) rotate(12deg);

    position: relative;
    left: 0;
    transform: translateY(150%) rotate(-12deg);
  }
}

@keyframes ride {
  5%, 95% {
    opacity: 1;
  }
  100% {
    offset-distance: 100%;
    left: var(--sleigh-position, 0);
    transform: var(--sleigh-transform, none);
    opacity: 0;
  }
}

document
  .querySelector(".sleigh-ride img")
  .addEventListener("animationend", (e) => {
    const sleigh = e.target;
    const sleighPlayPause = document.getElementById("animate-sleigh");

    // disable animation to reset for replay
    sleigh.style.animation = "none";

    // reset play state and button state
    document
      .querySelector(".sleigh-ride")
      .style.setProperty("--play-state", "paused");
    sleighPlayPause.dataset.state = "paused";
    sleighPlayPause.textContent = "Play animation";

    // trigger reflow to successfully replay animation
    sleigh.offsetWidth;
    // re-enable animation
    sleigh.removeAttribute("style");
});

Scroll-Linked Animations

On the cutting-edge of native CSS animation capabilities are scroll-linked animations. These animations enhance keyframe animations by attaching them to scroll position instead of the classic timeline.

Unfortunately, these are not stable in any browser but are available as an experiment in Chromium 89+ if you enable "Experimental Web Platform Features" under chrome://flags. I recommend doing this in Chrome Canary to prevent accidentally harming your normal browsing experience if you forget you have this on.

For more demos and a very thorough explanation of how scroll-linked animations work and what they're capable of, be sure to watch Bramus Van Damme presentation from CSS Cafe. Once you have the experimental flag on, you can also peruse his collection of demos on CodePen.

Demo of a scroll-linked progress indicator

@keyframes progressbar {
  0% {
    transform: scaleX(0);
  }
  100% {
    transform: scaleX(1);
  }
}

@scroll-timeline progressbar-timeline {
  time-range: var(--progress-time);
  source: selector(#scroll-animation);
}

.progress-bar {
  background-color: blue;
  height: 1rem;
  position: sticky;
  top: 0;
  transform-origin: left;
  animation: progressbar linear forwards var(--progress-time, 0);
  animation-timeline: progressbar-timeline;
}

#scroll-animation {
  position: relative;
  height: max(10rem, 30vh);
  overflow-y: auto;
}

.warning {
  background-color: lightyellow;
  border: 2px solid orange;
  padding: 1rem;
}

@supports (animation-timeline: yes) {
  .warning {
    display: none;
  }

  .progress-bar {
    --progress-time: 1s;
  }
}

⚠️ Your browser does not support CSS Scroll-Linked Animations. View this demo by using Chromium 89+ with “Experimental Web Platform Features” enabled.

Lorem ipsum, dolor sit amet consectetur adipisicing elit. Maxime nemo accusamus velit sunt atque maiores neque!

Dicta sint, quo nesciunt expedita quisquam id ipsum quaerat minima voluptate aut in, numquam unde? Expedita.

Nihil itaque esse, molestiae soluta minus earum temporibus dignissimos hic. Ab provident quasi voluptatem distinctio odit!

Labore ipsa architecto provident ullam, molestias assumenda obcaecati! Libero quidem doloremque voluptatum repellendus cumque facere sit!

Quas animi recusandae corrupti repellat culpa dolore, temporibus repudiandae omnis eum atque distinctio tempora ullam consequatur.

Ipsam molestiae deleniti cumque, maxime, error nulla sunt veniam corporis qui laboriosam quas excepturi voluptatibus laborum!

Unde iste repellat accusamus, quibusdam corporis placeat velit, cumque dolorum labore voluptas eligendi porro saepe rerum.

Laboriosam in error ipsam, dolorem aliquam magnam officiis totam exercitationem doloribus dicta excepturi incidunt unde earum!

Quas animi recusandae corrupti repellat culpa dolore, temporibus repudiandae omnis eum atque distinctio tempora ullam consequatur.

Ipsam molestiae deleniti cumque, maxime, error nulla sunt veniam corporis qui laboriosam quas excepturi voluptatibus laborum!

Unde iste repellat accusamus, quibusdam corporis placeat velit, cumque dolorum labore voluptas eligendi porro saepe rerum.

Laboriosam in error ipsam, dolorem aliquam magnam officiis totam exercitationem doloribus dicta excepturi incidunt unde earum!

Bonus: 3D CSS animation

Transforms also provide the opportunity to create 3D animation.

Get inspired by these jaw-dropping 3D animations created by Amit Sheen. Then check out Amit walking through how to create 3D shapes with Kevin Powell and begin animating them.

Image Display Elements

2021-12-20T00:00:00.000Z

Images on the web are hard. In this article, we're going to focus on the options for the display of responsive images.

There are a few different ways to add images to your page depending on what you care about in regards to what part of the image is displayed, the quality, and the performance. This is a high-touch overview that really only scratches the surface of these methods. Be sure to check the additional resources for more assistance researching the best method for your use case.

Basic img element

If you have optimized your image and aren't doing anything unusual with its display and aren't concerned about serving higher density images for retina screens, just a simple img will do.

<img src="image.png" width="600" height="400" />

I've intentionally added the width and height attributes here to give the browser information about the image's intrinsic aspect ratio. Evergreen browsers now will pick up on the computed aspect ratio and prop open the space necessary for the image while waiting for it to download which can reduce cumulative layout shift. Watch Jen Simmons explain more about how it works.

img with srcset

If you want to begin to have some performance gains, you can save out your image in multiple sizes. Then, define them within the srcset attribute on a single img along with the value of their intrinsic (actual) width or the pixel density you prefer to be used. The browser will select the optimum choice given conditions like the viewport size, resolution, user preferences, and bandwidth.

<img 
  alt=""
  src="image-small.jpg"
  srcset="image-large.jpg 1600w,
        image-medium.jpg 768w,
        image-small.jpg 320w"
  width="1600"
  height="800"
/>

<img 
  alt=""
  src="image-1x.jpg"
  srcset="image-3x.jpg 3x,
        image-2x.jpg 2x,
        image-1x.jpg 1x"
  width="1600"
  height="800"
/>

We're still including width and height to give the browser the aspect ratio hint. It's ok that the browser might choose a different image size because the assumption is a single image is resized which means the aspect ratio is the same throughout, regardless of ultimate rendered size.

img with srcset and sizes

With only srcset to go off of, the browser still has to wait for CSS to help determine the size to render. You can provide an additional hint by also adding the sizes attribute which relates to approximately how large the image will render within your layout.

The sizes attribute will be ignored if srcset is not provided. This is because the matching size will inform which image within srcset to use. The other condition is that srcset must be using widths and not density for this relationship to work.

When using sizes, the format is [media condition] [display width], [media condition] [display width], [display width] where display width is the intended width in your layout. The last value in the list must not have the media condition.

The browser will use the first matching media condition in the list based on device size and then select the exact srcset size if there's a match or the next largest size if there's no exact match.

<img 
  alt=""
  src="image-small.jpg"
  srcset="image-large.jpg 1600w,
        image-medium.jpg 768w,
        image-small.jpg 320w"
  sizes="(min-width: 120ch) 33vw, 100vw"
  width="1600"
  height="800"
/>

In that example, I'm letting the browser know that on a larger viewport I expect my image to take up roughly a third of the available space because it will be in a 3-column grid. Below that point, I expect it to take up essentially full width so we don't have to be more specific than 100vw. This still leaves it up to the browser to choose exactly which image to serve to best fit the layout expectations I have provided as well as its other conditions mentioned previously.

Art directing with picture

If you would like more control over which image is used and the flexibility for varying aspect ratios (aka "art directing" the image selected), then look to the picture element.

This involves a series of source elements that use the media attribute to define the media condition at which an image should be displayed. It's essentially like defining media query breakpoints directly on the image with the advantage of the browser knowing exactly which image to choose and start downloading even when CSS isn't available yet.

<picture>
  <source media="(min-width: 600px)" srcset="image-landscape.jpg">
  <source srcset="image-portrait.jpg">
  <img src="image-landscape.jpg" alt="">
</picture>

This method removes browser heuristics beyond viewport size from the equation and puts the responsibility back on you to provide the best image for the user. If your image maintains a consistent aspect ratio across various sizes, choose the img with srcset option or keep reading for a combination option.

Here's a video showing the art direction idea in action. Above 480px viewports, a landscape image is shown where a woman is laughing while sitting in a meeting at a Mac laptop with another woman who is partially visible turned to her with a hand raised mid-storytelling. Below that viewport size, the image is cropped in to feature the laughing woman.

Offering modern image formats

If your primary goal is to score some performance wins, then the picture element is again what you need. It allows you to list images using modern image formats like WebP, AVIF, and JPEG XL for the browser to select from, where the first supported type by DOM order of your source elements will be used.

<picture>
    <source srcset="image.jxl" type="image/jxl">
    <source srcset="image.avif" type="image/avif">
    <source srcset="image.webp" type="image/webp">
    <source srcset="image.jpg" type="image/jpeg">
    <img src="image.jpg" alt="" width="600" height="400">
</picture>

We're once again providing width and height attributes for this method to ask the browser to hold open space for the image to load into.

Prioritizing performance

To get the best of modern image formats while also allowing the browser to determine which image is best for the user's current context, we can use the srcset attribute on sources within picture. Users of browsers with support for WebP or other modern formats will enjoy a significant performance boost compared to only providing standard jpeg images within a single img srcset.

<picture>
  <source 
    type="image/webp" 
    srcset="wreath-w_200.webp 200w, 
      wreath-w_660.webp 660w, 
      wreath-w_960.webp 960w">
  <source 
    type="image/jpeg" 
    srcset="wreath-w_200.jpg 200w,
      wreath-w_660.jpg 660w,
      wreath-w_960.jpg 960w">
  <img 
    src="wreath-w_660.jpg" 
    alt="A holiday wreath made of evergreens and pinecones hangs from a round metal doorknocker attached to a teal door." 
    width="960" 
    height="640">
</picture>

In the demo, resize your viewport and then hover over the <img> tag in dev tools to see which image type and size was selected by the browser. Since we haven't used the media attribute, if your browser has downloaded a larger size it may not switch to the smaller size for a resize event since there is no performance gain. A refresh may trigger a change in the size selected for smaller viewports.

Also, note that the chosen size depends on not just viewport CSS pixels but also pixel density which may cause a larger than expected image to be selected. As in, the 660w image doesn't mean that image will be selected at 660px viewports.

Demo of srcset on source in picture

/* ensure the image resizes with its container
as well as keeping its aspect ratio */
img {
  max-width: 100%;
  height: auto;
}

Lorem ipsum dolor sit, amet consectetur adipisicing elit. Suscipit, reprehenderit doloremque. Tempore, esse dolorum? Quasi sunt sed temporibus perferendis, officia voluptatum sit fuga doloremque repellat, deleniti quod officiis esse mollitia.

Lorem ipsum dolor sit amet, consectetur adipisicing elit. Et exercitationem sint quis ullam quae, vitae libero doloremque dolores reprehenderit, fugit totam quisquam. Eum nostrum incidunt quas expedita nobis suscipit et!

You can take this method one step further since the source elements also support the sizes attribute. Note that you can only select a combo of either media and srcset, or srcset and sizes.

Boosting CSS background images with image-set

There are certainly reasons why adding an inline image may not be feasible due to using a CMS or other systems without full control over the HTML. In the cases where you at least have CSS control, you can still start to get some benefits similar to srcset by using the CSS function image-set.

Rather than supply widths, the available option is to mark a resolution such as 1x and 2x. The browser will choose the best match including assessing the resolution as a proxy to assume a lower resolution will be more efficient for low bandwidth.

There is also a type value for defining modern image formats but it doesn't have sufficient support yet. However, browsers that support image-set() also support webp format so we can use webp in image-set() as well as a fallback of a regular background-image with a jpg.

For the current best support, we need to include the -webkit prefixed version as well:

.image-set {
  background-repeat: no-repeat;
  background-size: cover;
  background-image: url(wreath-w_660.jpg);
  background-image: -webkit-image-set(
    url(wreath-w_660.webp) 1x,
    url(wreath-w_960.webp) 2x
  );
  background-image: image-set(
    url(wreath-w_660.webp) 1x,
    url(wreath-w_960.webp) 2x
  );
}

This will behave differently than srcset since we can only give a hint at the resolution. But being able to draw out the more modern image format (even if a bit hacky right now) can still be worthwhile savings.

Styling picture as a background image

Thanks to modern CSS, we can mix up the best of all the techniques to enable using picture with modern formats and srcset and sizes as a background. The other benefit we'll get is being able to retain alt descriptions which are lost as a side effect of actual CSS background-image.

Here's the HTML setup for this effect:

<div class="background-picture">   
  <div class="background-picture__content">
     <p>Yay background picture!</h3>
  </div> 
  <picture>
    <source type="image/webp" srcset="wreath-w_200.webp 200w, wreath-w_660.webp 660w, wreath-w_960.webp 960w">
    <source type="image/jpeg" srcset="wreath-w_200.jpg 200w, wreath-w_660.jpg 660w, wreath-w_960.jpg 960w">
    <img src="wreath-w_660.jpg" alt="A holiday wreath made of evergreens and pinecones hangs from a round metal doorknocker attached to a teal door." width="960" height="640">
  </picture>
</div>

To accomplish placing the text over the picture, we'll use CSS grid and a trick we first learned for the Day 6 holiday card generator for stacking elements.

Additionally, we've added one of my favorite CSS properties, object-fit, which makes the img behave as the container for its own contents. In other words, we gain the behavior of background-size but on a regular inline image.

You can even sprinkle in some art direction by using the companion property object-position which you can experiment with using my web app Object-Fit Focal Point.

Using CSS grid to stack content over the picture element

.background-picture {
  display: grid;
  /* create a single named grid area */
  grid-template-areas: "bp";
}

.background-picture > * {
  /* assign all direct children to the single grid area */
  grid-area: bp;
}

.background-picture__content {
  align-self: center;
  /* bring above picture when picture is last in DOM order */
  z-index: 1;
  color: #fff;
  text-align: center;
  font-size: clamp(1.35rem, 5vw, 1.75rem);
  font-weight: bold;
  padding: 5vh 1rem;
}

.background-picture :is(img, picture) {
  display: block;
}

.background-picture img {
  object-fit: cover;
  width: 100%;
  height: 100%;
  /* decrease brightness to improve text contrast */
  filter: brightness(0.65) saturate(1.25);
}

Yay background picture!

The demo also includes a succinct bonus modern CSS technique to improve text contrast over the image by reducing its brightness with a filter. We also bumped up the saturation to prevent completely losing the image's vibrancy. You could take this a step further and manage the brightness and saturate values with custom properties.

Aligning the content over the background picture

To change from a centered alignment, you can place the content using the -self alignment properties available for CSS grid.

Horizontally along the X-axis with justify-self
Vertically along the Y-axis with align-self (current style, set to center)
Set both axes at once with place-self, ex. place-self: end would put the content in the bottom right corner

Additional resources on image display and performance

Understanding the elements we've reviewed, when to use them, and how to construct the attribute values is a complicated venture. Here are some additional recommended resources to help guide you to a scenario that works best for you.

First, I highly encourage you to review the MDN docs on each element:

picture
source
img (Yes, really! I'm positive you'll learn something!)

Additionally, MDN has an excellent guide to responsive images that provides more demos of the things we touched on in this article.

Two tools to help prepare images:

Responsive Image Breakpoints Generator from Cloudinary
Squoosh app to convert between image types and adjust optimization

Still confused on when to use which type? Read these resources to help you understand... well, the bigger picture 😉

Chris Coyier dropping knowledge and advice in 2014/15 that still holds up (that's the nice thing about HTML!)
And more recently, Chris created a guide to responsive image syntax
Eric Portis wrote this absolutely stunning article (coincidentally also in 2014) that is exceptional at explaining the srcset and sizes attributes
More recently, Addy Osmani covered a lot about images as well as the relationship to Core Web Vitals (and he wrote an entire book dedicated to Image Optimization which you can find at the end of that article)
The HTML spec includes guidance on a whole series of responsive image scenarios with example code
Learn about responsive images and the picture element in the Responsive Design module from web.dev

Preference Queries

2021-12-19T00:00:00.000Z

You may be familiar with media queries to detect a user's viewport resolution, like the following:

@media (min-width: 60rem) {
  /* Styles for viewports larger than 60rem */
}

But did you know that @media - also known as one of the CSS at-rules - contains 24 total features to query against? Review the whole list of @media features on MDN, and check the browser support table (about 19 have decent cross-browser support).

The two we'll be covering have to do with user preferences - as in, features that are determined by operating system settings.

prefers-color-scheme
prefers-reduced-motion

About prefers-reduced-motion

As MDN states, this preference query "is used to detect if the user has requested that the system minimize the amount of non-essential motion it uses."

I've been a developer for nearly 15 years, and over that time I've seen a lot of trends. One with a significant amount of staying power was parallax animation, thanks to being boosted by big brands like Nike and Apple.

Parallax animation is a good example of a harmful type of motion for users with vestibular disorders. This is due to the foreground and background moving at different rates, which for some users can cause dizziness, nausea, and headaches. As Val Head notes in Designing Safer Web Animation for Motion Sensitivities, the negative effects for some users can last long after they've seen the animation.

With the use of prefers-reduced-motion, we can take steps towards reducing the impact of potentially harmful animations.

Using prefers-reduced-motion

There are two keywords for determining the state of a user's setting related to reduced motion that is surfaced via prefers-reduced-motion:

no-preference - the default, which as Tatiana Mac suggests may mean a user is ok with motion or that they aren't aware an option exists to reduce motion
reduce - a user has explicitly set their OS system setting for a reduced motion experience

And here's an example of setting both types. You can adjust this setting via your OS, or in Chromium dev tools it can be emulated under the "Rendering" tab.

Demo of using prefers-reduced-motion

@media (prefers-reduced-motion: no-preference) {
  .shake:hover {
    animation: shake 400ms ease-in-out;
  }
}

@media (prefers-reduced-motion: reduce) {
  .shake {
    /* !important due to overriding this site's rules to
    remove transitions when meeting this condition */
    transition: transform 180ms ease-in !important;
  }

  .shake:hover {
    transform: translateX(.25rem);
  }
}

@keyframes shake {
  0%, 100% {
    transform: translateX(0.5rem);
  }
  50% {
    transform: translateX(-0.5rem);
  }
}

.shake {
  font-size: 1.35rem;
  font-weight: bold;
}

Shake on hover if motion allowed

If you are using many animations, you can instead place them all in their own stylesheet and conditionally load it in via the media attribute on the link element:

<link rel="stylesheet" href="animations.css"
  media="(prefers-reduced-motion: no-preference)">

Or, if you have only some minimal animations or transitions, you can borrow a technique popularized from Andy Bell's modern CSS reset. This fast-forwards animations and transitions when a user prefers reduced motion.

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Why not completely remove them? Because there are times when a script may be listening for the transitionend or animationend events so it's safer to allow an imperceptible duration.

Handling prefers-reduced-motion with JavaScript

There is also a JavaScript way to detect the value of prefers-reduced-motion, which is beneficial if your animations are JS controlled.

In the following snippet, we're checking if prefers-reduced-motion: reduce matches. If it does match, then prefersReducedMotion will evaluate to true meaning the user prefers reduced motion.

const motionMQ = window.matchMedia('(prefers-reduced-motion: reduce)');
const prefersReducedMotion = motionMQ.matches;

We can then extend that to listen in case that preference changes so we can adapt the experience accordingly.

motionMQ.addEventListener('change', handleMotionChange);

In this demo, the text will be set according to your preference and update if you toggle your motion setting.

Detecting prefers-reduced-motion in JS

.mq-element { font-size: 1.35rem; }

const motionMQ = window.matchMedia('(prefers-reduced-motion: reduce)');

const updateMQ = (reduced) => {
  const element = document.querySelector('.mq-element');
  if (reduced) {
    element.textContent = 'reduce';
  } else {
    element.textContent = 'no preference';
  }
};

// Update on load
updateMQ(motionMQ.matches);

// Update on change
motionMQ.addEventListener('change', () => {
  updateMQ(motionMQ.matches);
});

...

Additional resources on prefers-reduced-motion

Learn more about the related WCAG Success Criterion 2.3.3: Animation from interactions which gives more context into why it's important to reduce animations
Eric Bailey gives a bit more history and a demo in his introduction to the reduced motion media query
Val Head presenting Making Motion Inclusive at An Event Apart demonstrates how reduced motion doesn't mean no animations allowed
Lindsey Kopacz walks through creating a toggle to allow your users to choose a reduced motion experience instead of only relying on the preference query
Josh Comeau looks at using prefers-reduced-motion in React

Using prefers-color-scheme

The second preference query you may have heard of since it is associated with providing a dark mode version of your site.

The prefers-color-scheme media feature does in fact detect whether a user has requested a dark or light theme.

While this often gets bundled up by developers into a face-off similar to tabs vs. spaces, the matter of dark or light has a lot to do with accessibility. For example, I myself preferred a light theme for years until I learned I had astigmatism which was making dark themes uncomfortable due to the appearance of "halos" around the letters.

The options for this query are fairly self-explanatory:

light
dark

Keep in mind that these are not expected to be as polar as white vs. black, but more about increasing the use of light or dark colors particularly for large areas of text.

A nifty way to manage your themes is by using CSS custom properties (covered in Day 3). By choosing general-purpose names for your custom property colors and using them carefully throughout your stylesheets, you can flip their values to retheme your site when either dark or light is requested.

:root {
  --theme-background: white;
  --theme-text: #222;
}

@media (prefers-color-scheme: dark) {
  :root {
    --theme-background: #222;
    --theme-text: white;
  }
}

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

The following demo shows a minimal example of this idea in action. Once again you can change your user settings or test this via dev tools as noted for the previous section.

Demo of theming with prefers-color-scheme

.site {
  --theme: "Light";
  --theme-background: lightblue;
  --theme-text: #222;
  --theme-inverse: #f9f9f9;
  --theme-primary: blue;

  background-color: var(--theme-background);
  color: var(--theme-text);
  padding: 1rem;
}

@media (prefers-color-scheme: dark) {
  .site {
    --theme: "Dark";
    --theme-background: #222;
    --theme-text: #f9f9f9;
    --theme-inverse: #444;
    --theme-primary: cyan;
  }
}

.site article {
  width: min(40ch, 100%);
  margin: 0 auto;
  padding: 1rem;
  background-color: var(--theme-inverse);
}

.site article * {
  margin: 0;
}

.site article * + * {
  margin-top: 1em;
}

.site article h2::after {
  content: " " var(--theme);
}

.site a:not([class]) {
  color: var(--theme-primary);
}

.site-btn {
  display: inline-block;
  text-decoration: none;
  background-color: var(--theme-primary);
  color: var(--theme-inverse);
  padding: 0.5em 0.75em;
  border-radius: 0.25em;
}

Theme Demo

Lorem ipsum dolor, sit amet consectetur adipisicing elit. Exercitationem amet magnam corrupti!

Magnam, a. Delectus consectetur hic at? Consequuntur maxime hic repellat numquam culpa.

Button

Handling prefers-color-scheme with JavaScript

We can detect and use the prefers-color-scheme value in a nearly identical format to prefers-reduced-motion.

This demo also includes a different option for managing color themes via CSS custom properties.

Detecting prefers-color-scheme in JS

.theme-element {
  background: var(--background, white);
  color: var(--color, black);
  border: 1px solid;
  padding: 2rem;
  font-size: 1.35rem;
}

@media (prefers-color-scheme: dark) {
  .theme-element {
    --background: #222;
    --color: white;
  }
}

const themeMQ = window.matchMedia('(prefers-color-scheme: dark)');

const updateTheme = (dark) => {
  const element = document.querySelector('.theme-element');
  if (dark) {
    element.textContent = 'dark theme';
  } else {
    element.textContent = 'light theme';
  }
};

// Update on load
updateTheme(themeMQ.matches);

// Update on change
themeMQ.addEventListener('change', () => {
  updateTheme(themeMQ.matches);
});

...

Additional resources on prefers-color-scheme

Accessibility expert Adrian Roselli reminds us that when building a theme toggle, there are really three options: light, dark, and inherit from system preferences
Andy Bell walks through one way to make a toggle including saving a user's selection to localStorage

A few posts on setting up dark and light themes:

Michelle Barker covers the custom property way to switch themes
Christopher Kirk-Nielsen offers a DRY approach for managing themes that is flexible for more than two options
The Material Design guidelines are worth a glance for different things to consider when developing a dark theme

Capturing User Media Streams

2021-12-18T00:00:00.000Z

The MediaDevices interface allows accessing a user's webcam and microphone, as well as allowing screen sharing. It requires a secure connection and prompts the user for permission after which the output - aka MediaStream - can be used within your application.

We'll specifically be learning how to use getUserMedia() to stream a user's webcam video and compose it with an SVG inside of HTML canvas to generate a screenshot, like mine!

Requesting and displaying a video media stream

There are a few essential parts of requesting a media stream, as in a user's video source like a webcam and/or an audio source like from a microphone.

The starting point is a call to navigator.mediaDevices.getUserMedia() along with an object holding the requested "constraints." The constraints include which types of media streams you would like - video and or audio - and other features like preferred dimensions. For the purposes of our holiday card, we're also going to request the front-facing camera as the preferred.

A Promise is returned from getUserMedia() along with the media stream if successful. The media stream can contain multiple "tracks" for each of audio and video sources.

We can wrap up the minimal required pieces as follows:

const handleSuccess = (stream) => {
  const video = document.querySelector("video");

  window.stream = stream;
  video.srcObject = stream;
};

const handleError = (error) => {
  console.error("Error: ", error);
};

const startWebcam = () => {
  navigator.mediaDevices
    .getUserMedia({ video: true })
    .then(handleSuccess)
    .catch(handleError);
};

In your HTML you would have an empty <video> element, and a <button> to trigger startWebcam(), such as:

<video autoplay muted playsinline></video>
<button onclick="startWebcam()">Start Webcam</button>

This is of course missing some important features, particularly the way to stop the webcam, but if you'd like you can test this in something like CodePen. If you haven't previously given your localhost or CodePen access to your webcam, your browser will display a prompt for you to give permission.

We also placed a few attributes on the video element which are critical to the streaming working cross-platform. The autoplay attribute prepares the video element so that as soon as it receives the stream it will play it back live. The muted and playsinline attributes are primarily to ensure the stream successfully plays back on iOS, as described in their video policies announcement.

Holiday card generator process

Our initial display will position the SVG of the card frame illustration over the video element. Then, when a user selects "Start webcam", they'll see a preview of what their holiday card screenshot will look like.
Once they select "Take Photo", we'll stop the video and pass the video stream and SVG into HTML Canvas which has a method that we can use to set the composite as the src of the image.
The user can then save the screenshot like any other image on the web.
If they want to retake, they can again select "Start Webcam" and we'll reset the image src to the SVG frame.
Additionally, we'll flip the start action to stop so that they can cancel the video access without taking a screenshot.

Holiday card HTML and CSS

Our generator has two sections: one to hold the card display, and one to hold the action buttons.

<div class="holiday-card">
  <video class="holiday-card__video" autoplay muted playsinline></video>
  <img class="holiday-card__img" src="/img/12DaysCardFrame.svg" alt="">
</div>
<div class="holiday-card__actions">
  <span id="holiday-webcam-instructions">Webcam required to enable taking a photo for the holiday card</span>
  <button type="button" class="holiday-card-webcam" aria-describedby="holiday-webcam-instructions" data-state="offline">Start Webcam</button>
  <button type="button" class="holiday-card-photo" disabled>Take Photo</button>
</div>

We've included a few features for accessibility by adding some instructions so that non-sighted users will get a bit more context for why there is a "Start Webcam" button. These users have a few modes of navigation including tabbing between interactive elements and scanning text content. In scan mode, they'll receive the instructions first due to the DOM order. In tabbing mode the button name will be read first, then the instructions due to the association created by aria-describedby.

Since "Take Photo" cannot perform any action until the webcam stream is available, we have set the disabled attribute.

On the webcam button, we've added the data-state attribute so we can keep track of whether the webcam is currently offline or streaming.

Holiday card styles

We'll be using CSS Grid and one of my favorite tricks to stack elements within a single grid cell in order to place the SVG image frame above the video. This technique is an upgrade from using the less flexible solution of absolute positioning.

The relevant styles for stacking the video and image with grid are as follows:

.holiday-card {
  display: grid;
  place-items: center;
  grid-template-areas: "card";
}

.holiday-card__video,
.holiday-card__img {
  grid-area: card;
}

.holiday-card__img {
  position: relative;
}

Through testing, I found relative positioning was necessary to ensure the image appeared above the video element.

While I won't go over every line in the styles, another key part is where we've set the .holiday-card wrapper to use aspect-ratio: 16/9. We're going to be requesting a video feed in HD format. The CSS property for aspect-ratio has seen increased support over just this past year, but we want to provide a fallback if it's not yet supported.

For that, we'll use a combination of the native CSS @supports feature and a custom property for setting the element's max-height. We'll update that value with JavaScript so that we can ensure it ends up with the 16/9 aspect ratio. We'll do that part when we complete our generator script.

@supports not (aspect-ratio: 16/9) {
  .holiday-card {
    max-height: var(--card-height, 30vh);
  }
}

Here's our styled card application with some other goodies like candy cane striping.

Holiday Card Generator CSS

.demo {
  background-color: lightblue;
}

[class*="holiday-card"] {
  margin: 0;
}

.holiday-card {
  display: grid;
  place-items: center;
  grid-template-areas: "card";
  background-color: #222;
  aspect-ratio: 16/9;
  width: 100%;
  border-radius: 2rem 2rem 0 0;
  overflow: hidden;
}

@supports not (aspect-ratio: 16/9) {
  .holiday-card {
    max-height: var(--card-height, 30vh);
  }
}

.holiday-card__video,
.holiday-card__img {
  grid-area: card;
  display: block;
  max-width: 100%;
  max-height: 100%;
  /* required to prevent mobile portrait overflow */
  overflow: hidden;
}

.holiday-card__img {
  position: relative;
  width: 100%;
}

.holiday-card__actions {
  --color-green: #30a45e;
  --color-red: #e63a48;
  --color-light: #fcdce2;

  display: grid;
  grid-auto-flow: column;
  justify-content: center;
  gap: min(2rem, 4vw);
  padding: clamp(.5rem, 5%, 1rem);
  background: #e63a48;
  background-image: repeating-linear-gradient(45deg, var(--color-red) 0 2%, var(--color-light) 2% 5%);
  border-radius: 0 0 2rem 2rem;
  box-shadow: 0 0.5rem 0.5rem -0.25rem rgba(0, 0, 0, 0.35);
}

.holiday-card__actions button {
  all: unset;
  cursor: pointer;
  text-align: center;
  border-radius: 0.5em;
  border: 0.15em solid var(--color-light);
  color: #fff;
  background-color: var(--color-red);
  padding: 0.5em 0.75em;
  font-family: system-ui, sans-serif;
  font-size: 1.25rem;
  font-weight: bold;
  letter-spacing: 0.03em;
  box-shadow: 0.1em 0.15em 0.25em -0.08em rgba(0, 0, 0, 0.75);
}

.holiday-card__actions button:focus {
  outline: 2px dashed currentcolor;
  outline-offset: -7px;
}

.holiday-card__actions button:not(:disabled):hover {
  background-color: var(--color-green);
}

.holiday-card__actions button:disabled {
  cursor: not-allowed;
  opacity: 0.7;
  filter: grayscale(40%);
  box-shadow: inset 0.1em 0.15em 0.25em -0.08em rgba(0, 0, 0, 0.75);
}

#holiday-webcam-instructions {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

Completing the generator script

The minimal script we first discussed is our starting point for the final holiday card generator.

With our card HTML now created, let's first create variables of all the pieces.

const card = document.querySelector(".holiday-card");
const cardImage = document.querySelector(".holiday-card__img");
const cardVideo = document.querySelector(".holiday-card__video");
const cardWebcamButton = document.querySelector(".holiday-card-webcam");
const cardPhotoButton = document.querySelector(".holiday-card-photo");

Recall we also setup a CSS custom property as a fallback for when CSS aspect-ratio wasn't supported, and it's time to supply that value. So now that we have the card element, we can compute the correct height to ensure the 16/9 ratio. This will only actually be set as the height if the browser doesn't support aspect-ratio due to how we set up the CSS using @supports.

card.style.setProperty("--card-height", card.offsetWidth * 0.5625 + "px");

An update to make is to improve the constraints to select for HD resolution and preference the front camera. The ideal key will request that the device provides the nearest available resolution if available. You can review the other available constraint parameters.

const constraints = {
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    facingMode: "user"
  }
};

const handleSuccess = (stream) => {
  window.stream = stream;
  cardVideo.srcObject = stream;
};

const handleError = (error) => {
  console.error("Error: ", error);
};

const startWebcam = () => {
  navigator.mediaDevices
    .getUserMedia(constraints)
    .then(handleSuccess)
    .catch(handleError);
};

And now we'll add the click event listener to handle starting and stopping the webcam.

cardWebcamButton.addEventListener("click", (e) => {
  const webcamState = e.target.dataset.state;

  if (webcamState === "offline") {
    startWebcam();
  } else {
    stopWebcam();
  }
});

The stop function is yet to be created, but it relies on the fact we saved the stream into the window.stream object. The MediaStream API provides getVideoTracks() which returns an array of all found video streams. We're only expecting one, so we then call the stop() method. This immediately disconnects the video stream and the user's webcam will become inactive.

const stopWebcam = () => {
  if (window.stream) {
    window.stream.getVideoTracks()[0].stop();
  }
};

Now we have the basis of our functions but we haven't updated the state of our UI elements.

When the webcam is started successfully, we can do a few extra steps within handleSuccess() to make the "Take Photo" button available and also toggle the webcam button to "Stop" and its state to streaming.

const handleSuccess = (stream) => {
  cardWebcamButton.dataset.state = "streaming";
  cardWebcamButton.textContent = "Stop Webcam";
  cardPhotoButton.removeAttribute("disabled");
  cardImage.src = cardFrame;

  window.stream = stream;
  cardVideo.srcObject = stream;
};

One more piece slipped in, which was to reset the card img back to the SVG file path, which we need to add as a variable. We're doing this because when this function is called after the "Take Photo" action, the image source will be the saved screenshot. This is to reset to allow the video stream to be visible.

const cardFrame = "/12DaysCardFrame.svg";

We'll enhance stopWebcam() to handle the reverse state of the UI.

const stopWebcam = () => {
  cardWebcamButton.dataset.state = "offline";
  cardWebcamButton.textContent = "Start Webcam";
  cardPhotoButton.setAttribute("disabled", "disabled");

  if (window.stream) {
    window.stream.getVideoTracks()[0].stop();
  }
};

Create a video screenshot using HTML canvas

With our webcam start and stop working, it's time to enable taking the screenshot!

First, we need to create a canvas element. This can be added near our UI variables:

const cardCanvas = document.createElement("canvas");

Then, we'll start the function within the click event listener for the photo button. We prepare width and height variables that match the video resolution. This might seem like an odd choice, but it makes our final screenshot easier to take. There is a downside for a particular circumstance, which we'll discuss at the end.

cardPhotoButton.addEventListener("click", () => {
  const width = cardVideo.videoWidth;
  const height = cardVideo.videoHeight;

  // Setup Canvas
  cardCanvas.width = width;
  cardCanvas.height = height;
  const ctx = cardCanvas.getContext("2d");
});

Those dimensions are applied to the canvas element we created, and then comes the required step of obtaining the 2D context. The context is what we attach our drawing methods to for rendering the video and the frame SVG.

Our first item to render to canvas is the video, which is interestingly done via the canvas method of drawImage. The zeroes represent the x and y coordinates for placing the video on the canvas.

// Draw video
ctx.drawImage(cardVideo, 0, 0);

Following that, we begin to set up for rendering the SVG. We create a new canvas Image() and match the dimensions to the canvas. Then, set its source to the SVG file path.

// Create frame image
const frame = new Image(width, height);
frame.src = cardFrame;
frame.setAttribute("crossOrigin", "anonymous");

The crossOrigin attribute may not be necessary if your image is relative to your site, but might be needed if coming from a CDN. You can learn more about why it might be necessary for canvas images.

Creating the image in this way means it needs to load which requires time just like an image loaded into the DOM. Before we proceed with capturing the screenshot, we'll wait for the onload event of the image to ensure it's fully available. Otherwise only the video will be captured.

// Ensure frame loaded
frame.onload = () => {
  // Draw frame to canvas
  ctx.drawImage(frame, 0, 0, width, height);
  // Output final composed canvas to DOM img
  cardImage.src = cardCanvas.toDataURL("image/jpeg", 1.0);
};

The comments capture the steps, but after drawing the SVG we conclude the process by rendering the canvas contents as base64 encoded jpeg data into the card image src.

We selected jpeg as the file format so that it retains the video quality as much as possible and so that it is a type that the user can download and use as they wish. There are other options for toDataURL().

To close out the function, we need to trigger stopping the webcam. And since stopping the webcam disables the photo button, we'll move focus back to the "Start Webcam" button to prevent disorienting assistive technology users since disabled buttons are not focusable.

stopWebcam();
cardWebcamButton.focus();

Have fun trying out the generator!

Holiday Card Generator Demo

const constraints = {
  video: {
    width: { ideal: 1280 },
    height: { ideal: 720 },
    facingMode: "user"
  }
};

const cardFrame = "/img/12DaysCardFrame.svg";
// Scoped to prevent working on the CSS demo :)
const card = document.querySelector(".scripted.holiday-card");
const cardImage = document.querySelector(".scripted .holiday-card__img");
const cardVideo = document.querySelector(".scripted .holiday-card__video");
const cardWebcamButton = document.querySelector(".scripted .holiday-card-webcam");
const cardPhotoButton = document.querySelector(".scripted .holiday-card-photo");
const cardCanvas = document.createElement("canvas");

card.style.setProperty("--card-height", card.offsetWidth * 0.5625 + "px");

const handleSuccess = (stream) => {
  cardWebcamButton.dataset.state = "streaming";
  cardWebcamButton.textContent = "Stop Webcam";
  cardImage.src = cardFrame;
  cardPhotoButton.removeAttribute("disabled");

  window.stream = stream;
  cardVideo.srcObject = stream;
};

const handleError = (error) => {
  console.error("Error: ", error);
};

const startWebcam = () => {
  navigator.mediaDevices
    .getUserMedia(constraints)
    .then(handleSuccess)
    .catch(handleError);
};

const stopWebcam = () => {
  cardWebcamButton.dataset.state = "offline";
  cardWebcamButton.textContent = "Start Webcam";
  cardPhotoButton.setAttribute("disabled", "disabled");

  if (window.stream) {
    window.stream.getVideoTracks()[0].stop();
  }
};

cardWebcamButton.addEventListener("click", (e) => {
  const webcamState = e.target.dataset.state;

  if (webcamState === "offline") {
    startWebcam();
  } else {
    stopWebcam();
  }
});

cardPhotoButton.addEventListener("click", () => {
  const width = cardVideo.videoWidth;
  const height = cardVideo.videoHeight;

  // Setup Canvas
  cardCanvas.width = width;
  cardCanvas.height = height;
  const ctx = cardCanvas.getContext("2d");

  // Draw video
  ctx.drawImage(cardVideo, 0, 0);

  // Create frame image
  const frame = new Image(width, height);
  frame.src = cardFrame;
  frame.setAttribute("crossOrigin", "anonymous");

  // Ensure frame loaded
  frame.onload = () => {
    // Draw frame to canvas
    ctx.drawImage(frame, 0, 0, width, height);
    // Output final composed canvas to DOM img
    cardImage.src = cardCanvas.toDataURL("image/jpeg", 1.0);
  };

  stopWebcam();
  cardWebcamButton.focus();
});

Webcam required to enable taking a photo for the holiday card

Mobile support

Our generator is very likely to be functional on mobile given support of the APIs in use.

However, I noted that there's a potential issue with setting the canvas size to match the video size. And that is that on mobile in portrait mode, our video will not receive a stream using the 16/9 aspect ratio.

You may already be on a mobile device and have discovered how the camera stream in the preview has the portrait aspect ratio and is centered within the frame. This is thanks to CSS positioning the video element.

But, when you take a photo, a screenshot is successfully rendered but continues to have the portrait aspect ratio. This makes it look strange as the replaced still in our image element once again due to the CSS in place which causes it to falsely appear stretched. When you try to save it you'll see that the actual photo is portrait dimensions but this causes the SVG to stretch. This isn't completely terrible except that the demo SVG has text.

Consider this a challenge to you to work out how to resolve for mobile portrait mode! You could try to keep the portrait centered in the final image. Or, swap both the generator preview and the frame to accommodate a portrait orientation. Or whatever other solution makes sense to you!

Ideas for expanding the generator

Our holiday card generator is a solid base for building additional features for interacting with a user's webcam.

Create preset classes that apply CSS filters to the video to pass into the canvas as well
Provide a gallery of different frames to choose from, or different "stickers" or text phrases
Enhance the webcam script to allow the user to choose the video source or change the resolution

If you expand this idea or create something new with what you've learned, tag #12DaysofWeb on Twitter or CodePen to let me know! I'd love to share your creations.

Additional resources

Links to the APIs are included where discussed in the tutorial, and I definitely recommend reviewing the full array of options they provide.

Two tutorials I found very useful in researching how to create this generator:

Capture Audio and Video in HTML5 has an interesting history towards the APIs we used today and several examples of other things that can be done that are sure to inspire you
Taking still photos with WebRTC on MDN covers similar things but in a more straightforward way

For advanced techniques, learn to create webcam effects from Adam Kuhn in this recording. Or go deep on learning real-time effects for images and video with a little extra help from WebGL.

CSS Houdini Paint API

2021-12-17T00:00:00.000Z

The CSS Houdini spec contains a few different APIs but the currently best-supported is the Paint API. Fortunately, there is a polyfill that allows the API to be used today, but it should still be considered a progressive enhancement.

Let's learn more about the Houdini Paint API and create our own worklet - the JavaScript class that contains our paint function.

What is CSS Houdini

Houdini APIs give you direct access to the CSS Object Model (CSSOM) which means you can provide custom instructions to the browser about how to render features not available in CSS. Since Houdini passes off your worklet function to the browser rendering engine, they are very performantly painted off the main thread.

Now, I could explain what's possible with Houdini, but I recommend skipping over to Houdini.how for a few minutes to scroll through the examples.

Notice that paint() function applied to things like background, background-image, border-image, and mask-image? That's how the paint worklet is called. Additionally, a worklet can receive CSS custom properties which makes them flexible and customizable per implementation.

Houdini worklets are encouraged to be shared, and you may have also noticed how those demos included a CDN link and/or NPM link. An additional reason beyond sharing the worklets is that they must be run on a local server or over HTTPS.

Developing a CSS Houdini Paint worklet

Worklets are created as JavaScript classes. For a preview of the worklet we're going to create, scroll to the bottom of the page! The "snow" effect is created via Houdini.

Worklet environment and initial setup

To create the worklet, I'll assume you're working on a local server. I prefer Eleventy to quickly get this up and running, but any setup that can run a local server such as through Browsersync will do.

For the simplest starting point, create:

worklet.js
index.html
style.css

In your HTML file, we won't link to the worklet like a normal script. Instead, we'll call it with a special function to make it available to the browser and our styles:

<!-- added in index.html -->
<script>
if (CSS.paintWorklet) {
  CSS.paintWorklet.addModule("worklet.js");
}
</script>

Earlier I mentioned there was a polyfill, which you'll need for support currently in Firefox and Safari. As the simplest way to include that, you can link to it prior to including your worklet from the unpkg CDN:

<script src="https://unpkg.com/css-paint-polyfill"></script>

While in your HTML file, let's add a simple div that we'll attach the worklet to for testing. There seem to be some issues with trying to attach a worklet to the body unless you will not pass it custom properties. This element can certainly contain other content, it does not need to be reserved to work as a worklet target.

<div class="snow"></div>

Then we'll add just a touch of style to our document so that our snow container has dimensions. We'll also set a background color because that will not be provided as part of our worklet.

* {
  box-sizing: border-box;
}

body {
  margin: 0;
}

.snow {
  background-color: lightblue;
  min-height: 100vh;
}

Initialize the worklet class

Now in our worklet file, we'll begin by defining what we want to call our worklet, which we'll also use to prefix the related custom properties.

// worklet.js
const WORKLET = "houdini-snow";

Following that, we'll begin our class and include the initial call to paint:

class HoudiniSnow {
  paint(ctx, size, properties) {
    
  }
}

registerPaint(WORKLET, HoudiniSnow);

The class name is up to you, but notice it is also passed into the registerPaint function.

Select and access worklet custom properties

At this point, it's good to consider what custom properties - if any - we'd like to provide for customization. For this worklet, I decided on the following:

--houdini-snow-min - minimum snowflake size, an integer that resolves to pixels
--houdini-snow-max - maximum snowflake size, an integer that resolves to pixels
--houdini-snow-fill - a string to select where to fill the element with snowflakes
--houdini-snow-flakes - an integer corresponding to the total number of snowflakes

In order to access those properties, we'll use the method for inputProperties(). Of note, this method can access all properties on the element, not just custom ones. Place this prior to the paint() function within the class:

static get inputProperties() {
  return [
    `--${WORKLET}-min`,
    `--${WORKLET}-max`,
    `--${WORKLET}-fill`,
    `--${WORKLET}-flakes`,
  ];
}

Now we're ready to begin painting, so let's examine the properties we've setup:

ctx refers to the rendering context and is how we'll "draw" output. Officially called PaintRenderingContext2D, it provides access to a subset of the HTML Canvas API.
size returns the width and height of the element the worklet is being painted to
properties is where the custom properties we're expecting from inputProperties get passed into the paint function

We'll begin by pulling out the width and height from size and also gathering the values from the custom properties. For those, we need to do a bit of extra processing depending on what type we're expecting - integer or string. And, we set some defaults in case the properties are not set.

paint(ctx, size, properties) {
  const { width, height } = size;
  const min = parseInt(properties.get(`--${WORKLET}-min`)) || 2;
  const max = parseInt(properties.get(`--${WORKLET}-max`)) || 7;
  // fill: "all" | "top" | "bottom"
  const fill = properties.get(`--${WORKLET}-fill`).toString().trim() || "all";
  const flakes = parseInt(properties.get(`--${WORKLET}-flakes`)) || 1000;
}

Note that for the fill we'll accept three possible strings: all to cover the element, or either top or bottom to only cover the chosen half.

Add randomness responsibly with a PRNG

In order to place the snowflakes, which we'll simply draw as circles, we need to create an array populated with x and y coordinates which is what the canvas requires. And to ensure they don't all end up in the same place but are distributed across the available space, we need a way to introduce some randomness.

The key to remember here about the paint API is that repainting is triggered when anything causes the layout to change. For example, resizing the browser. Depending on your worklet, allowing randomized positioning on repaint can cause an unwanted motion effect or even flashing from the rapid repaints. And that can cause some users migraines or even seizures.

Clever mathematical-minded folks have figured out how to create what they call pseudorandom number generators (PRNG). These have the appearance of randomness, but the behavior is that given an input the function always returns the same output. I found out about this method from George Francis, and I highly recommend their resources if you are interested in diving deep with the paint API and particularly generative art.

The PRNG that George recommends is mulberry32, which looks quite scary but what it ultimately does is intake a "seed" number and returns a number between 0 and 1 for each request. So while those individual requests return a different number, as a group the returned numbers are the same so the output ultimately has the appearance of being the same.

This function may be placed outside of the class.

function mulberry32(a) {
  return function () {
    a |= 0;
    a = (a + 0x6d2b79f5) | 0;
    var t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

We will use the number of flakes as the seed, and create the random variable within our paint function:

const random = mulberry32(flakes);

Create an array of snowflake coordinates

So now we have a way to attach randomness, but we also need to work out how to select a value between a minimum and maximum. This will be used to select x and y points but also to size the snowflake circles.

Once again, George helps point us to the answer here which is a lerp (linear interpolation) function. Given a start, end, and amount value (a number between 0 and 1 aka our random number), it will return a point between the start and end.

We'll set up our lerp function next to the mulberry32 one. When we want to fill the lower half, we have to make an adjustment to ensure it picks a point within the higher range, and it was necessary to pass a fourth optional parameter.

function lerp(start, end, amt, fill) {
  if (fill === "bottom") {
    return end - (start * amt);
  } else {
    return (end - start) * amt;
  }
}

The easy coordinate is x which will always be plotted between 0 and the width of the element. Given this idea of "top" and "bottom" half, the coordinate this affects is y which will move the snowflake up or down within the element. So before we finally calculate the coordinates, we'll prepare variables to adjust the y range start and end.

const startPos = fill === "bottom" ? height / 2 : 0;
const endPos = fill === "top" ? heignt / 2 : height;

Now we have all the setup to create an array to hold each snowflakes coordinates:

const snowflakeArr = [...Array(flakes)].map(() => {
  return {
    x: lerp(0, width, random()),
    y: lerp(startPos, endPos, random(), fill),
  };
});

Draw the snowflakes within the rendering context

If you've made it this far, you're about to be rewarded with finally painting the snowflakes!

Finally, it's time to tap into the rendering context via our ctx parameter and draw the snowflake circles. We'll loop through our snowflakeArr and for each snowflake do the following:

Generate the fill color using hsla to produce a white color that has a randomized alpha with the help of another call to lerp and the PRNG
Begin drawing the path, a crucial step for making a shape
Use the arc function to draw the circle, once again with the help of lerp and the PRNG to add variance to the snowflake circle size
Add the fill color so that the snowflake circle is visible

snowflakeArr.forEach((point) => {
  ctx.fillStyle = `hsla(0 0% 100% / ${lerp(0.4, 1, random())})`;
  ctx.beginPath();
  ctx.arc(point.x, point.y, lerp(min, max, random()), 0, Math.PI * 2);
  ctx.fill();
});

And with that, our houdini-snow worklet is complete.

Demo of the houdini-snow worklet

Try out changing the provided custom properties for this demo in dev tools to see how they affect the rendering of our houdini-snow worklet.

houdini-snow worklet sandbox

.houdini-snow {
  --houdini-snow-min: 4;
  --houdini-snow-max: 8;
  --houdini-snow-fill: top;
  --houdini-snow-flakes: 400;

  background-color: lightblue;
  height: 30vh;
  background-image: paint(houdini-snow);
}

Using the polyfill and providing fallback styles

While we already included the link to the polyfill earlier, there's an issue that can arise where it needs a little extra nudge to work after the page loads. We can use setTimeout to trigger a repaint on elements that should be rendering a worklet by calling window.getComputedStyle() against each element.

setTimeout(() => {
  const snow = document.querySelector(".snow");

  if (snow) {
    window.getComputedStyle(snow);
  }
}, 250);

As with anything, be sure to test in Firefox and Safari to ensure the rendering meets your expectations.

The polyfill does not seem to support rendering within pseudo-elements which can be a significant limitation if you are making your worklet a focal point. You may need to fall back to background images or other solutions, which you can accomplish using CSS @supports.

@supports not (background-image: paint(worklet)) {
  /* fall back styles here */
}

Additional resources and worklet ideas

For an overview of additional features available in the Paint API, review the guide from MDN.

I've mentioned George Francis and if you are interested in the Houdini Paint API and/or generative art, definitely check out their other resources, including:

Conjuring Generative Blobs which also shows how to use the produced shape as a mask
Creating Generative Patterns reviews how to create many types of shapes and several spacing and layout methods
Watch George explain creating generative design with Houdini at LondonCSS
Get inspired by reviewing George's Houdini worklets on CodePen

Over on CSS-Tricks, Temani Afif has done a series of ideas, starting with this one on image fragmentation effects (motion warning).

Jumpstart your worklet environment including getting it ready to publish on npm by using my Eleventy-based worklet starter.

Don't forget to check out the resources available on Houdini.how.

Have fun painting!

Audio API

2021-12-16T00:00:00.000Z

While you're not likely to be embedding audio on the web every day, you never know when it might be useful!

The API is vast, and complements the <audio> native HTML element. We'll review the element first, then look at a few parts of the API to build a simple custom player.

The audio HTML element

The <audio> HTML element allows you to embed audio anywhere, and adding the controls attribute also displays the browser's audio player.

<audio controls src="jingle-bells.mp3"></audio>

The results of that HTML will display a little differently depending on your browser.

Audio converted and edited from the Jingle Bells midi.

Additional available attributes outside of controls include autoplay, loop, and muted. You can also include <source> elements as child elements of <audio> instead of using the src attribute.

You may also define what, if anything, to preload, where the default is different per browser. The option selected for preloading depends on how you intend to use the audio element Options include none, metadata, and auto.

Creating a custom audio player

The primary issue with the native player is that there is no cross-browser styling control over its elements. And each browser player is also inconsistent in which controls they provide.

Chromium: play/pause, duration and time elapsed, timeline scrubber, volume, and additional menu to download or select playback speed
Firefox: play/pause, duration and time elapsed, timeline scrubber, and volume
Safari: play/pause, timeline scrubber, and time elapsed

For our custom player, we're using a reduced scope since this is intended as an introduction to this API. There are certainly more features you could add, but we'll focus on:

Displaying track title (static)
Duration and time elapsed
Play/pause state toggle
Mute/unmute state toggle

Audio player HTML

First, we'll build out semantic, accessible HTML for our custom audio player. I encourage always starting with this step (yes, even if you're using a framework).

We'll create a container with the role of "group" to help define the boundaries of our custom player for assistive technology (AT), as well as an aria-label to label the group "Audio player". And, we'll go ahead and add an <audio> element as the first child. Note that we're specifically defining the preload here since we are planning to use the metadata for display.

<div role="group" aria-label="Audio player" class="audio-player">
  <audio preload="metadata" src="jingle-bells.mp3"></audio>
</div>

Since we haven't added the controls attribute, browsers will default to hiding the audio element.

Next, we'll use a headline element to label what is currently playing:

<h3 class="audio-player__current"><small>Playing:</small> Jingle Bells</h3>

Following that, we'll add two button elements to use as our player toggles for play and mute actions. We're wrapping the text in a span which we'll accessibly hide so that it is used for the label by AT. The icon svg include aria-hidden="true" since they are decorative as far as AT is concerned given the accessible labeling text.

<button data-action="play" data-state="paused" class="audio-player__button" type="button">
  <span class="audio-player__label">Play</span>
  <svg data-play height="24" width="24" aria-hidden="true">
    <path d="M8 5v14l11-7z" />
  </svg>
  <svg data-pause hidden height="24" width="24">
    <path d="M6 19h4V5H6v14zm8-14v14h4V5h-4z"/>
  </svg>
</button>
<button data-action="mute" class="audio-player__button" type="button" aria-pressed="false">
  <span class="audio-player__label">Mute</span>
  <svg height="24" width="24" aria-hidden="true">
    <!-- svg path -->
  </svg>
</button>

There are two SVG icons for a "play" and "pause" icon, where the "pause" initially has the hidden attribute so that it is not displayed. We'll toggle the icons' hidden attribute as well as the label content when it is selected.

The other important attributes on the buttons are:

data-action: used for finding the element in JS. We're avoiding an ID in case of multiple audio players and avoiding a class to discourage removing or changing the name
aria-pressed: identifies the mute button as a toggle button for AT and will convey the changed state which will update dynamically in JS

Finally, we'll use a paragraph to contain the time information and set default zero values. Here again, we're preparing our markup to hide the AT labels, so the final visual will be 0:00 / 0:00.

<p class="audio-player__time">
  <span class="audio-player__label">Elapsed time&nbsp;</span><span data-time="remaining">0:00</span> / <span class="audio-player__label"> Total time&nbsp;</span><span data-time="total">0:00</span>
</p>

Audio player styles

Since our audio player is completely made of custom elements now, we have full styling control. We'll be leveraging CSS grid to arrange the elements.

You can expand the styles to review them fully, and lookout for a few key features:

We hide our labels using the styles from Scott O'Hara's visually hidden class
On the .audio-player container, we set width using fit-content which visually shrinks the player to its intrinsic width where supported
For the toggle buttons SVG, we set pointer-events: none so that the click event "falls through" to the button element
The time content has set font-variant-numeric: tabular-nums which, when supported by the font, requests that numeric values take on monospace behavior, which prevents our audio player's width visibly adjusting when wider or narrower numbers are displayed

Audio player CSS

.audio-player * {
  margin: 0;
}

.audio-player__label {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

.audio-player {
  padding: 1rem;
  background: #222;
  color: #fff;
  border-radius: 0.5rem;
  display: grid;
  grid-template-columns: auto auto 1fr;
  align-items: center;
  width: fit-content;
  gap: 1rem;
}

.audio-player__current {
  grid-column: 1 / -1;
  display: flex;
  align-items: center;
  gap: 0.25em;
  font-size: 1.25rem;
  font-weight: bold;
}

.audio-player__current small {
  font-weight: normal;
  text-transform: uppercase;
}

.audio-player__button {
  all: unset;
  cursor: pointer;
  display: inline-grid;
  place-content: center;
  border-radius: 0.25rem;
  border: 2px solid #fff;
  padding: 0.15em;
}

.audio-player__button:focus {
  outline: 2px solid #fff;
  outline-offset: 2px;
}

.audio-player__button svg {
  fill: currentcolor;
  pointer-events: none;
}

.audio-player__button[aria-pressed=true],
.audio-player__button[data-state=playing] {
  background-color: #fff;
  color: #222;
}

.audio-player__time {
  font-variant-numeric: tabular-nums;
}

Playing: Jingle Bells

Elapsed time 0:00 / Total time 0:00

Audio player API events

Both the audio and video API inherit the HTMLMediaElement interface. There are many properties, methods, and events that you can use. We'll hone in on some of the most essential for our simple player.

The capabilities we need for our audio player:

Toggle the aria-pressed state for the play and mute action buttons
Toggle play state
Toggle mute state
Set the total duration
Update the elapsed timestamp during playback
Reset the elapsed timestamp and play toggle state when the audio ends

First, we'll find each element, including the <audio> since we directly respond to events and set properties on it.

const audioElement = document.querySelector(".audio-player audio");
const audioPlay = document.querySelector('[data-action="play"]');
const playLabel = audioPlay.querySelector('.audio-player__label');
const playIcon = audioPlay.querySelector('[data-play]');
const pauseIcon = audioPlay.querySelector('[data-pause]');
const audioMute = document.querySelector('[data-action="mute"]');
const audioTimeRemaining = document.querySelector('[data-time="remaining"]');
const audioTimeTotal = document.querySelector('[data-time="total"]');

Our play button functionality is the most complex. For setting play versus pause, we call those functions against the audio element. Additionally, we update the data-state which is tied to styles, as well as change the text content of the label. Last, we use the handle toggleAttribute JS function to toggle the hidden attribute of the icons to efficiently flip their visibility.

audioPlay.addEventListener("click", (e) => {
  const isPlaying = audioPlay.dataset.state === "playing";

  if (isPlaying) {
    audioElement.pause();
    audioPlay.dataset.state = 'paused';
    playLabel.textContent = "Play";
  } else {
    audioElement.play();
    audioPlay.dataset.state = 'playing';
    playLabel.textContent = "Pause";
  }
  
  playIcon.toggleAttribute('hidden');
  pauseIcon.toggleAttribute('hidden');
});

For mute, we toggle the boolean muted property and aria-pressed state.

audioMute.addEventListener("click", (e) => {
  const isMuted = audioMute.getAttribute("aria-pressed") === "true";
  audioMute.setAttribute("aria-pressed", !isMuted);
  audioElement.muted = !isMuted;
});

Now that the toggles are working, it's time to handle the time updates. There are three events we'll listen to:

loadedmetadata: allows us to confidently set the total time by getting the duration
timeupdate: fires during playback and we'll use it to update the elapsed time
ended: signals the audio file has completed playback which we'll use to reset the player state

Since the time is calculated in seconds, we'll first create a function to format it to mm:ss for display.

const formatAudioTime = (time) => {
  if (isNaN(time)) return;
  const minuteValue = Math.floor(time / 60);
  let secondValue = Math.floor(time - minuteValue * 60);
  if (secondValue < 10) {
    secondValue = "0" + secondValue;
  }
  return minuteValue + ":" + secondValue;
};

Then, we'll call the formatting function for setting the total time upon the loadedmetadata event and setting the time remaining on the timeupdate event.

audioElement.addEventListener( "loadedmetadata", () => 
  (audioTimeTotal.textContent = formatAudioTime(audioElement.duration))
);

audioElement.addEventListener( "timeupdate", () => 
  (audioTimeRemaining.textContent = formatAudioTime(audioElement.currentTime))
);

Finally, we'll complete our player by resetting the play button state and remaining time upon the ended event.

audioElement.addEventListener("ended", () => {
  audioPlay.dataset.state = 'paused';
  playLabel.textContent = "Play";
  playIcon.toggleAttribute('hidden');
  pauseIcon.toggleAttribute('hidden');
  audioTimeRemaining.textContent = "0:00";
});

The following is our final demo as well as the complete script.

Audio player JS

// .playable scoping due to previous CSS demo
// ⚡️ Challenge: Adapt this to work for multiple players per page
const audioElement = document.querySelector(".playable.audio-player audio");
const audioPlay = document.querySelector('.playable [data-action="play"]');
const playLabel = audioPlay.querySelector('.audio-player__label');
const playIcon = audioPlay.querySelector('[data-play]');
const pauseIcon = audioPlay.querySelector('[data-pause]');
const audioMute = document.querySelector('.playable [data-action="mute"]');
const audioTimeRemaining = document.querySelector('.playable [data-time="remaining"]');
const audioTimeTotal = document.querySelector('.playable [data-time="total"]');

audioPlay.addEventListener("click", (e) => {
  const isPlaying = audioPlay.dataset.state === "playing";

  if (isPlaying) {
    audioElement.pause();
    audioPlay.dataset.state = 'paused';
    playLabel.textContent = "Play";
  } else {
    audioElement.play();
    audioPlay.dataset.state = 'playing';
    playLabel.textContent = "Pause";
  }
  
  playIcon.toggleAttribute('hidden');
  pauseIcon.toggleAttribute('hidden');
});

audioMute.addEventListener("click", (e) => {
  const isMuted = audioMute.getAttribute("aria-pressed") === "true";

  audioMute.setAttribute("aria-pressed", !isMuted);
  audioElement.muted = !isMuted;
});

const formatAudioTime = (time) => {
  if (isNaN(time)) return;

  const minuteValue = Math.floor(time / 60);
  let secondValue = Math.floor(time - minuteValue * 60);

  if (secondValue < 10) {
    secondValue = "0" + secondValue;
  }

  return minuteValue + ":" + secondValue;
};

audioElement.addEventListener( "loadedmetadata", () => 
  (audioTimeTotal.textContent = formatAudioTime(audioElement.duration))
);

audioElement.addEventListener( "timeupdate", () => 
  (audioTimeRemaining.textContent = formatAudioTime(audioElement.currentTime))
);

audioElement.addEventListener("ended", () => {
  audioPlay.dataset.state = 'paused';
  playLabel.textContent = "Play";
  playIcon.toggleAttribute('hidden');
  pauseIcon.toggleAttribute('hidden');
  audioTimeRemaining.textContent = "0:00";
});

Playing: Jingle Bells

Elapsed time 0:00 / Total time 0:00

Ideas for using the audio API

Audio elements with no controls can be used to help respond to play() commands to add fun audio enhancements. Click Jason's head for inspiration. Be sure to also provide the user a toggle to turn off all sounds.
Create a more full-featured player including visualizations
Use the API to aid animation like Andrew Rubin does to animate a cartoon band
Have a podcast? Now you can create a custom player embed!

Additional resources

Learn with Jason from Lindsey Kopacz to create an accessible audio player
MDN has a large section with many guides to explore the audio API
Check out what all is available for the HTMLMediaElement (which applies to video, too)
If you're wondering why we didn't use aria-pressed for the play button, learn from Sarah Higley about conveying the state of toggle buttons to AT

CSS Custom Properties

2021-12-15T00:00:00.000Z

CSS custom properties are very well supported and are absolutely something to make a priority to learn and use in 2022.

There are many things to love about custom properties, and we'll overview the following:

What are CSS custom properties?

Custom properties allow you to define variables for re-use in your styles. Just like other CSS properties, they abide by the rules of the cascade. This is a great feature because it means we can define them with defaults and then provide overrides as needed. If you're a JS dev, think of them as equivalent to being defined with let.

To define a custom property, use the name of your choice preceded by two dashes, for example: --my-property. Then you can use that value by calling it within the var() CSS function in place of providing a standard value.

For this class, we're defining a custom --color property and then using it for the color value:

.btn {
  --color: blue;
  color: var(--color);
}

How custom properties differ from preprocessor variables

Preprocessors like Sass or LESS have had variables for many years. However, those variables are ultimately static once compiled into your final stylesheet. This is great for values that you repeat across your styles but don't have a need to change post-compilation.

Custom properties have the advantage for values that may change dynamically client-side or contextually via inline style overrides. Additionally, using preprocessor variables to set a value such as our button color requires redefining all properties used in a modifier class to change to a different preprocessor variable. In other words, you can't change the value of a preprocessor variable after it was defined, but you can do that with CSS custom properties (pending cascade inheritance).

Another advantage for preprocessor variables over custom properties is defining strings to use anywhere, such as for media query breakpoints, or to even define a selector string which can look like the following:

// Example in Sass which allows overriding the $classes value
$classes: ".class-a, .class-b" !default;
#{$classes} {
  // define properties for this rule
}

Why should I use CSS custom properties?

Let's answer that by enhancing our previous code example for changing the .btn color.

If I want to change the color of the button text and border on hover, I no longer need to repeat those properties. Instead, we can just change the --color value.

Notice how we're able to use the var() function as only part of the value, in this case, to define the border-color. This opens up endless opportunities for custom properties!

CSS to update color variable for hover state

.btn {
  --color: blue;

  color: var(--color);
  border: 2px solid var(--color);
  padding: 0.25em 0.5em;
  border-radius: 0.25em;
  text-decoration: none;
}

.btn:hover {
  --color: red;
}

Hover or tap me!

Using custom properties to set defaults

A feature of var() is the ability to both call a custom property, but also set a fallback which you can also think of as a default.

var(--color, blue)

We can even set the default using another custom property. Using that idea, let's create a different version of our .btn class to allow modifying the --border-color while also setting the --color variable as a default.

Combining local variables with defaults

.btn-v2 {
  --color: blue;

  color: var(--color);
  border: 2px solid var(--border-color, var(--color));
  padding: 0.25em 0.5em;
  border-radius: 0.25em;
  text-decoration: none;
}

.btn-v2:hover {
  --border-color: red;
}

Hover or tap me!

Custom properties and inheritance

It's important to learn a few things about how CSS custom properties are computed and inherited.

My own introduction into custom properties led me to believe that I should load them all on the :root selector. Instead, it's recommended to only hold truly global properties in the :root, and more class or component-specific styles closer to where they are needed.

A key concept is that custom property values are computed once per element, and then the computed value is available for inheritance. When you use custom properties within calc() or other values that need to be calculated, like the hue of hsl(), then you are making the total computed value inheritable. You are not able to change a value within a calculation if it is set on an ancestor, as shown:

:root {
  --unit: 10px;
  --size-lg: calc(3 * var(--unit));
}

/* this will not use the updated unit value for the calculation */
.margin-top-3xl {
  --unit: 30px;
  margin-top: var(--size-lg);
}

One option to fix the previous inheritance issue is by using a combination of a base and modifier class so that the values are computed against the same element. In the demo, we're still setting a global --unit value and using it as the default on the base class.

Handling custom property inheritance

:root {
  --unit: 10px;
}

.margin-top {
  --margin-unit: var(--unit);
  --multiplier: 1;

  margin-top: calc(var(--multiplier) * var(--margin-unit));
}

.margin-top--3xl {
  --margin-unit: 30px;
  --multiplier: 3;
}

div[class*="margin"] {
  background-color: dodgerblue;
  color: white;
  padding: 0.5rem;
  font-size: 1.5rem;
}

.margin-top

.margin-top.margin-top--3xl

There are also times where it can be beneficial to use an undefined custom property, such as making utility classes even more flexible. The benefit of an undefined property is that it can inherit its value from any ancestor, which is excellent for updating values for a group of related elements.

Two options for using unset properties:

Completely undefined with no default, which means it will likely have the behavior of unset for that property, for example: color: var(--color) where --color is not set within the rule
Undefined with a fallback to get the benefits of both inheritance and ensuring a default, example: color: var(--color, blue)

We used the second option in the demo around setting defaults to allow an optional --border-color value.

A gotcha with the first is that you may expect it to use a previously set style for that element in your stylesheet. However, by the time the custom property is evaluated the browser will have already tossed out a previously set, non-inherited value.

In this demo, if --color is not set, all paragraphs will use unset behavior. For paragraphs, this evaluates to using inherit for color. Since the custom property caused throwing out the previously set paragraph style, the color will inherit from the nearest ancestor instead. You can experiment with adding --color to the paragraph using dev tools to see it successfully set and used. Adding via dev tools works due to causing a repaint.

Demonstration of custom properties using 'unset' behavior

/* tossed out */
p.unset { color: red }
/* behaves as 'inherit' per 'unset' rules */
p.unset { color: var(--color) }

My color will inherit from the nearest ancestor where it is set

Accessing and setting custom properties with JavaScript

There are typically JavaScript counterparts for interacting with CSS, and using JS to dynamically set or update custom properties is kind of a superpower. We can keep the overall style setup in our CSS and update parts of it as needed.

Some opportunities to update custom properties with JavaScript:

CSS transform values for animations
values within a calc to use viewport dimensions
any number value that can't be gained in CSS alone
filling the gap for unsupported CSS properties

To access the value of a custom property within JavaScript, use the following combination of getComputedStyle() with getPropertyValue().

getComputedStyle(element).getPropertyValue("--my-var");

In this next demo, we're using JavaScript to get the width of the paragraph. Then we assign that to the custom property assigned as the hue value within the hsl() color function. As an aside, this works because hsl allows any numeric value for hue because it just loops back around the color wheel for numbers greater than 360.

Updating custom properties with JavaScript

.js-color {
  background-color: hsl(var(--hue), 100%, 80%);
  color: black;
  font-size: 1.5rem;
  padding: 1rem;
}

.js-color::after {
  content: " Current: " attr(style);
}

const p = document.querySelector('.js-color');
const setColor = () => p.style.setProperty('--hue', p.offsetWidth);
window.onresize = setColor;
setColor();

Resize your viewport to change my background color (warning: flashing possible).

Combining preprocessor variables and CSS custom properties

As a software engineer who works on design systems, I've grown fond of using Sass together with custom variables so that I can use the strengths of each.

In order to use a Sass variable as a custom property value, you need to use interpolation which looks like this:

--custom-property: #{$sass-var};

In my work, I'm usually including theming capability. With Sass, we can set static variables using the !default flag which means they are overridable. Then, we can pass that in to be used as custom property values. Plus we can take advantage of other Sass features like looping to help produce similar groups of properties.

$color-link: blue !default;
$font-sizes: (
  "small": .875rem,
  "normal": 1rem,
  "medium": 1.25rem,
  "large": 2rem
) !default;

:root {
  --color-link: #{$color-link};

  @each $size, $value in $font-sizes {
    --font-size-#{$size}: #{$value};
  }
}

This setup allows re-theming an application without modifying the core Sass file setup.

Summary of ways to use custom properties

color theme values and other design tokens
to update select values across states, as we did for the .btn demo
allow contextual updates for classes while providing defaults
in partnership with values received from JS
to compensate for preprocessor values being unable to change after being set
...and a whole lot more

Additional resources

Posts from Lea Verou
A strategy guide to structuring and applying custom properties
More info on how to work with custom properties and the cascade
The CSS-Tricks complete guide
7 practical ideas for using custom properties from Michelle Barker on CSS-IRL
Also hear more about custom properties from Michelle in this recording from Smashing Meets
Even more practical use cases from Ahmad Shadeed

Details / Summary

2021-12-14T00:00:00.000Z

Using details and summary is appropriate to reveal (aka "disclose") supplemental information. However, there is a fine line between acceptable and inaccessible usage. While we won't dive into that in this post, be sure to check the additional resources for more information.

Setting up details and summary

Here is the most essential markup for this pattern. The details element is the parent, and the first child is the summary.

<details>
   <summary>Summary text</summary>
   <p>The content that appears when the details element is open</p>
</details>

Which produces the following, which is shown using default browser styles:

Summary text

The content that appears when the details element is open

You can also predefine that the details should be open which means the full content is revealed as the default state.

Important to note: you have to remove the open attribute completely to close the details, not just set it to "false".

<details open>
   <summary>Open summary text</summary>
   <p>This content is visible by default</p>
</details>

Open summary text

This content is visible by default

When the details element open attribute is toggled, it emits a "toggle" event that you can listen for in JavaScript. You can also programmatically add or remove the open attribute.

JS for the details "toggle" event

const details = document.querySelector('.js-ds');
details.addEventListener('toggle', event => {
  const summary = details.querySelector('summary');
  if (details.open) {
    summary.style.backgroundColor = 'pink';
  } else {
    summary.style.backgroundColor = 'tomato';
  }
});

Background will change on toggle

Pie wafer apple pie jelly cotton candy chocolate bar icing jelly beans. Apple pie shortbread carrot cake cupcake pastry gummi bears chupa chups lollipop.

Styling considerations for details and summary

One of the main issues with browser (aka user agent) styles is that they don't ship with very good focus or hover indicators to reinforce the interactivity. So, let's fix those two items up first. These styles will be attached to the summary since that receives those states.

CSS for summary hover and focus

summary.styled {
  /* Provide a more expected visual affordance for this clickable element */
  cursor: pointer;
}

summary.styled:hover {
  background-color: #ddd;
}

summary.styled:focus {
  outline: 2px solid currentColor;
  outline-offset: 2px;
}

I have style!

Gummies topping topping lollipop shortbread candy canes sweet roll. Topping lemon drops sweet muffin lemon drops tootsie roll chupa chups sesame snaps caramels.

We can take it further by customizing the native arrow indicator thanks to a modern CSS selector for ::marker (which also can style list bullets).

CSS for styling the summary ::marker

summary.styled--marker::marker {
  color: magenta;
}

Even more stylish!

Gummies topping topping lollipop shortbread candy canes sweet roll. Topping lemon drops sweet muffin lemon drops tootsie roll chupa chups sesame snaps caramels.

Ways to use details and summary

FAQs as long as you aren't intending them to be an accordion, which would be an inaccessible use case
A tangential fact within a longer post
An audio or video full transcript
Allowing expanding/collapsing code snippets related to a demo as you'll see throughout this site

Additional Resources

Due to there being a narrow range for ensuring your use of details and summary is accessible, I encourage you to check out Adrian Roselli's post on Disclosure Widgets. You'll learn about a few other similar patterns that would not be appropriate to use details and summary, and also find the very simple JS and CSS required if you choose to roll your own.

Intersection Observer

2021-12-13T00:00:00.000Z

What is the Intersection Observer API?

The Intersection Observer (IO) Web API is an asynchronous way to watch the visibility of target elements either within their ancestors or the main viewport. You can then trigger additional events based on the target element's visibility and position - aka where it's "intersecting". Importantly, this "observation" happens off the main thread (that's the async part) meaning it can be a more performant alternative to other scroll tracking methods.

While IO is technically an experimental API, it has very good browser support. Being experimental mostly means it is possible that it could undergo breaking changes. This is good to be aware of, but the core feature set can absolutely start being used today.

IO core features and concepts

Let's consider a scenario where an IO is useful: a sticky table of contents for in-page links where you want to highlight the current section.

Previously, you may have taken measurements between the top of the viewport and the top of each new section, then set up scroll tracking to add a class to the related link. With IO, we can instead separately observe when each page section intersects say the midpoint of the viewport and then trigger updating an "active" link state.

When using IO, the target element's intersection is calculated based on three option parameters:

root: an ancestor element used for tracking visibility, defaulting to the browser viewport
rootMargin: enables changing the intersection bounding box using percent or pixel values corresponding to top right bottom left similar to margin, useful for tracking based on passing for example the midpoint of the ancestor vs. the bottom edge
threshold: the percentage of the target element that must be visible to trigger the callback, defined as a single number or an array of decimal values between 0 and 1

Once the target is visible based on these parameters, the IO initiates a callback with additional data you can use for your event. One interesting bit of data is the time in milliseconds between when an observer was started and when the callback was triggered.

A gotcha for IO is the threshold value. If you select 1, meaning when the element is 100% visible, then the entirety of the element must be visible within the root at once. Given scrollable areas ranging from phones to mega monitors with varying resolution aspect ratios, 100% is difficult to achieve without failing in some scenarios. The default for threshold is 0, meaning as soon as even 1 pixel is visible the callback will initiate. A more reliable way to change when a callback occurs is to adjust the rootMargin to reposition at what point the target element needs to intersect the root.

Creating a basic Intersection Observer

First, we'll make sure the API is available:

if ('IntersectionObserver' in window) {
  // IO code here
}

Then we'll initiate the observer, and begin observing our target:

// Target to observe
const boxEl = document.getElementById('box');
// Observer
const boxObserver = new IntersectionObserver(callback, options);
// Observing #box
boxObserver.observe(boxEl);

For the callback function, we'll receive an array of entries regardless of the number of target elements. In our example, we're only worried about a single entry, so we can save that by the zero index. We'll ensure it's intersecting, remove the observer, and perform our event.

const callback = (entries) => {
  const box = entries[0];
  if (!box.isIntersecting) return;
  boxObserver.unobserve(box.target);
  boxEl.textContent = 'intersected';
  boxEl.style.backgroundColor = 'yellow';
}

Removing the observer is best if you only need to trigger the callback once. In the scenario of our sticky table of contents, we would want to keep the observer active.

Due to the setup of this tutorial page, we need to scope our observer root to the demo scrollable element of box-root. Then we'll also adjust the rootMargin to pull the bottom up to 50%, meaning our callback won't trigger until the box has scrolled above the midpoint of the root element.

const rootEl = document.getElementById('box-root');
const options = {
  root: rootEl,
  rootMargin: '0% 0% -50% 0%'
}

Basic Intersection Observer

#box-root {
  height: 200px;
  overflow-y: auto;
  border: 1px solid red;
  padding: 1rem;
  font-size: 1.5rem;
}
#box {
  margin: 300px auto;
  border: 2px solid black;
  height: 4rem;
  display: grid;
  place-content: center;
}
.midpoint {
  position: sticky;
  top: 50%;
  width: 100%;
  color: red;
  text-align: center;
  transform: translateY(-50%);
}

if ('IntersectionObserver' in window) {
  const boxEl = document.getElementById('box');
  const rootEl = document.getElementById('box-root');

  const options = {
    root: rootEl,
    rootMargin: '0% 0% -50% 0%'
  }
  const callback = (entries) => {
    const box = entries[0];
    if (!box.isIntersecting) return;
    boxObserver.unobserve(box.target);
    boxEl.textContent = 'intersected';
    boxEl.style.backgroundColor = 'yellow';
  }

  const boxObserver = new IntersectionObserver(callback, options);
  boxObserver.observe(boxEl);
}

Scroll...

midpoint

...

Ideas for using Intersection Observer

Besides the sticky table of contents tracking (possibly also familiar to you as "scroll spy"), here are some other ideas.

analytics events involving visibility or read time
triggering animations
lazy loading assets and scripts
closing out-of-view menus, tooltips, and overlays

Additional resources

MDN documentation
I explored a few different tracking methods in the context of gathering analytics events
Travis Almand provides a deep investigation into IO
Preethi provides several practical use cases for IO like lazy loading or pausing out-of-view videos

12 Days of Web

2025-01-13T20:40:02.099Z

12 Days of Web 2021

2025-01-13T20:40:02.079Z

12 Days of Web 2023

2025-01-13T20:40:02.079Z

12 Days of Web 2022

2025-01-13T20:40:02.079Z

12 Days of Web

CSS margin-trim and line height units

Line height units

Margin trim

Try it yourself

Take your typography to the next level

How to Use Baseline Data

Why not include polyfills in Baseline?

Why not include things that are easy progressive enhancements?

Baseline reduces the number of features you need to make a decision about

Finding the Widely available date

The future of Baseline

BroadcastChannel API

Sending and Receiving Broadcast Messages

Demo App: Santa's List

Other Opportunities for Use

Resources

CSS light-dark()

Color scheme

Enter light-dark()

Themed variables using light-dark()

Overriding color-scheme

To the CodePen!

Further reading

JS Import Maps

Introduction

Understanding Import Maps

The Problem with Bare Imports

How Import Maps Help

Example Usage

Advanced Features

Scoped Imports

Version Management

Browser Support and Fallbacks

VS Code Extension

Project Ideas

1. Winter Task Tracker with Snowfall Effects

2. Holiday Gift List Organizer

3. Winter Weather Dashboard

Additional Resources

Conclusion

CSS box-decoration-break

What is a box?

What are decorations?

What’s a break?

Enter box-decoration-break

The re-introduction

Block-level box-decoration-break for multi-column layout.

'box-decoration-break: slice'

'box-decoration-break: clone'

That’s box-decoration-break

Declarative Shadow DOM

The Problem

The Problem with Shadow DOM

Our Requirements

The HTML

The initial custom element JavaScript

The CSS

Fetching the CSS

Some more DOM manipulation

Loading the data

A fork in the road

Declarative shadow DOM to the rescue!

The template

The Shadow and the Custom Element

CSS in the Declarative Shadow

Conclusion: Embracing Declarative Shadow DOM

Some common questions

What about including the same component with the same CSS multiple times on the same page?

What about a Flash Of Unstyled Content (FOUC)?

Could you generate the template server side for non-declarative shadow DOM?

Demo projects

Shadow Core HTML

Shadow Core

Neo-Shadow HTML

Neo-Shadow

Neo-Shadow Laravel

The support landscape

Additional Resources

CSS content-visibility