Ryan Mulligan

Style Review

2021-11-05T00:00:00Z

Donut dessert lollipop dragée pudding marzipan jelly

Danish icing cake sugar plum chocolate bar candy canes macaroon pie.

Bear claw bear claw biscuit fruitcake icing brownie. Jelly-o pudding tart cake ice cream jelly-o. Danish sugar plum chocolate cake wafer cake pudding sweet roll sesame snaps tiramisu. Carrot cake soufflé chocolate bar biscuit ice cream donut bear claw muffin marzipan.

Carrot cake?

Toffee wafer bonbon dessert dragée topping. Jelly tiramisu ~~gingerbread pie~~ toffee chocolate chocolate cake caramels. Donut gummi bears oat cake sugar plum cake marzipan marzipan. Cake gingerbread fruitcake tart chupa chups.

Chocolate cake! Danish toffee!

Danish sugar plum chocolate cake wafer:

The fanciest of the chocolate cakes

Pastry jelly tootsie roll biscuit sesame snaps sesame snaps cotton candy sweet. Muffin tart cupcake jelly marzipan jelly beans liquorice pudding. Croissant powder marshmallow donut candy canes cupcake.

Tiramisu apple pie muffin fruitcake wafer powder macaroon muffin caramels.

Pie sugar sweet roll jujubes cake
Tart sweet pudding caramels candy candy marzipan carrot cake soufflé chocolate bar biscuit.
Dessert toffee donut jelly
Powder gummies cheesecake brownie

Biscuit wafer danish sweet roll wafer

Toffee jelly beans fruitcake cake candy canes liquorice gingerbread:

Tart
fruitcake
shortbread
chupa chups
chocolate cake
cheesecake
gingerbread

Jujubes chocolate sesame snaps donut topping pie. Cake gummies powder chocolate cake cookie sesame snaps chocolate cake. Gummi bears bear claw chocolate sugar plum chupa chups.

Pudding lollipop cake gummi bears oat cake bear claw muffin powder chupa chups. Tiramisu apple pie muffin fruitcake wafer powder macaroon muffin caramels.

Chupa chups bear claw biscuit cookie! Sweet biscuit powder... ice cream cupcake danish? Cake gummies powder chocolate cake cookie.

Sweet chocolate cake oat cake dragée candy apple pie. Oat cake soufflé brownie toffee gummi bears marzipan chocolate bar. Try getChocolate('cake') or fruitcake pie chocolate bar shortbread.

Chocolate cake sweet roll jelly beans. Cake lollipop apple pie lollipop jelly beans cookie.

const yum = document.querySelector(".yum");

function handleClick() {
  // Log something sweet
  console.log("Chocolate!");
}

yum.addEventListener("click", handleClick);

Chocolate cake sweet roll jelly beans.
Cake lollipop apple pie.
Lollipop jelly beans cookie!

Jelly-o gummi bears cake. Dragée chocolate cake danish toffee cupcake brownie cheesecake oat cake topping. Carrot cake chupa chups ice cream tart soufflé gummi bears gummies danish.

Donut.

Migrating to Eleventy

2021-11-08T00:00:00Z

Hello, world!

The time has come. I've finally decided to explore the wonderful world of 11ty!

The migration process for my personal website was dead simple. Not that moving a tiny one-pager over to a static site generator is really a big deal, but getting started was just so easy. Build An Eleventy (11ty) Site From Scratch by Stephanie Eckles was an incredible introduction to helping me understand the basics.

Why choose Eleventy?

Most of my curiosity around 11ty stems from the amount of positive feedback and love I see for this project around the web. It's decoupled from the rest of my tech stack and tooling. It works with multiple template engines (using markdown and nunjucks here). Spinning up dynamic pages from external data is no sweat. There are no client-side javascript dependencies. Instead of me going on about it, check out the 11ty Docs or amazing resources like 11ty.rocks and 11ty.recipes.

On top of all that, the community is made up of really stellar people that I admire. People that care about a performant and inclusive web. I'll always be sold on that.

What's next then?

This only marks the beginning of this website's evolution. It will probably be a slow burn. Which is fine. Getting set up on 11ty gives me the opportunity to spin up content quickly.

I have often wanted to write small articles around front-end techniques that have been helpful for me and share them with the community. It will also be nice to have a space where I can look up solutions I've since forgotten. I haven't been compelled to set up that space until now. The desire to mess around with 11ty gave me the push I needed.

Be on the lookout for small snippets and chunks of thoughts. Looking forward to sharing with you all and getting feedback on improvements or alternatives.

A Horizontal Scroll List and Custom Keyboard Navigation

2021-11-15T00:00:00Z

Getting started

It was time for a personal site refresh. I didn't plan much for this next iteration, but I knew I wanted to include a showcase of my CodePen projects. With so many to choose from, it was tough deciding on how I'd ultimately like to visibly display project content. To kick things off, a list of linked cards presented in a horizontal scroll container felt worthy of exploring.

The argument against a carousel-style UX popped in my head, naturally, and maybe I should not use a carousel. However, I wanted to try this aesthetic with the following scope in mind:

An inline overflow of multiple cards provides context for scrolling the x-axis of this section. Although, I do recognize some edge case viewport widths where this may not seem overtly obvious.
When hovering this project section, a scroll bar will appear as another indication that content is horizontally scrollable.
This layout can be achieved with just HTML and CSS, even utilize scroll snap properties.
It creates a similar experience across all modern input devices and screen sizes.
We can quickly scan down to the next article on the page without scrolling through a list of 40+ cards, e.g. displayed in a layout such as a traditional responsive grid.

Below is a stripped-down CodePen demo focused on layout and keyboard navigation criteria:

Open CodePen demo

Overall, I'd consider this a horizontal scroll container. Not really a carousel. If you're shaking your head, disagree, and have feedback already, I'm looking forward to it! For the sake of getting to the real purpose of this article, let's read on.

User flow on a keyboard

After building out the page structure, I tried navigating the site homepage using my keyboard. I quickly noticed how tedious it was tabbing through every single one of those CodePen project links. Perhaps there's a way to make this interaction and page flow feel more seamless.

Let's jump into some solutions. The following is what I had tried with the latter option being the path forward.

Skip links

My first solution was to introduce a "skip to next section" anchor element that would be focused prior to entering the project list. It's similar to skip navigation links, a common pattern for keyboard navigation and screen readers that allow us to jump directly to the site's main content area.

While inactive, this anchor element is visually hidden on the page. Once focused, the link appears on screen. We can then press the enter key and skip over these projects to the next page section containing the id used in the href attribute.

Using shift + tab to navigate back up the page will surface the same issue in reverse. At this point, I debated appending a skip link to the end of the project list. Doing so would lead to something like this:

<section id="above-section">
  <!-- section content -->
</section>

<a href="#below-section">Skip project section</a>
<ul class="projects">
  <!-- 40+ links -->
</ul>
<a href="#above-section">Skip project section</a>

<section id="below-section">
  <!-- section content -->
</section>

Hmm. This seems somewhat restrictive and may be confusing. Let's explore a different way to handle this navigation instead of sandwiching the component with these skip elements.

Custom keyboard control

This iteration explores setting focus on the project list element with tabindex. By customizing the tabindex on this component, we now have the choice of interacting with this list of links or jumping to the next focusable element on the page.

Here's how it works:

The script is initialized, and tabindex="0" is applied to the project list. This adds it as a focusable element in the document's source order.
tabindex="-1" is set on every project link making them unreachable through sequential keyboard navigation.
When the list element is focused, the left and right arrow keys become activated to traverse its links.
The right arrow jumps to the next project link in sequence until it reaches the end, then loops back to the beginning of the list.
The left arrow focuses the previous project link until it reaches the first item, then it jumps to the end of the list and continues working backwards.

In an effort to better surface this interaction, helper text is inserted into the DOM when the container focus is visible. My screen reader testing has been limited to Voiceover on macOS at the time of writing this article, but it's good to note that with Voiceover enabled, we are given feedback on how to traverse the list using built-in keyboard shortcuts.

An example of the voiceover notification that reads, 'You are currently on a list. To move between items in this list, press Control-Option-Right Arrow or Control-Option-Left Arrow.'

One final tweak: Elements now scroll completely into view when focused. Without this bit of code, it was possible to focus an element overflowing the boundary of the viewport but it did not pull it all the way on screen. Combining the scrollIntoView method with a programmatic focus improves this flow:

const reducedMotion = window.matchMedia("(prefers-reduced-motion: reduce)");
//...
selected.scrollIntoView({
  block: "nearest",
  inline: "start",
  behavior: reducedMotion.matches ? "auto" : "smooth",
});

selected.focus({ preventScroll: true });

Notice that a prefers-reduced-motion conditional is applied to the behavior option. This will respect our reduced motion settings and disable smooth scrolling of the list.

When JavaScript is disabled

This layout works as intended without JavaScript. The level of control I've added attempts to make it easier to interact with this component, but content is still navigable without it. You can give it a shot by disabling JavaScript in your browser settings. Navigating with your keyboard still works; You'll just have to tab through every project in the list. Mouse and touch scrolling are no different.

What's your take?

I've made quite a few assumptions here. Does this feel intuitive when navigating using a keyboard? Or is it possible that this may diminish the default flow? Your feedback will help me improve this experience or think about this component behavior differently. Reach out on Twitter or send me an email.

Helpful resources

Special thanks to my good friends that gave initial feedback in a draft of this article. Your help is very appreciated! Here are some other supportive resources:

Animating with the Flip Plugin for GSAP

2022-01-07T00:00:00Z

What the flip is it?

Every time a new GSAP plugin is introduced, I'm close to bursting from excitement. The simplicity of the GreenSock API makes learning and applying these tools in projects such a dream. I had the pleasure of beta testing the ScrollTrigger plugin and was blown away by how easily I was able to dive in and start creating.

The Flip plugin is no different. And how about this? As of the 3.9 release (Dec 2021), it's no longer a members-only plugin. T'was a Merry Christmas indeed!

Before I continue, let's take a moment to celebrate the amazing GreenSock team for the incredible animation tools they provide for our web community. 🙏

The technique

FLIP, coined by Paul Lewis, is an acronym for First, Last, Invert, and Play. The Flip plugin harnesses this technique so that web developers can effortlessly and smoothly transition elements between states. Take it straight from the plugin's introduction:

Flip records the current position/size/rotation of your elements, then you make whatever changes you want, and then Flip applies offsets to make them LOOK like they never moved/resized/rotated and then animates the removal of those offsets! UI transitions become remarkably simple to code. Flip does all the heavy lifting.

I recommend reading the docs (always!), and watching that intro tutorial video (or jump straight down to their code examples if that's your fancy) to find out how you, too, can produce super sizzlin' layout animations with a minimal amount of code.

The challenge

The final week's prompt for the December 2021 CodePen Challenge involved using the FLIP technique. This couldn't have lined up more perfectly. The holidays had arrived. The office was quiet. I filled my coffee mug to its very top and, after a few hours of learning and experimentation, came up with this animation prototype:

Open CodePen demo

In the above CodePen embed, click on a product item square and it will magically slingshot towards the cart button. Once the element reaches the end of its transition, it will be inserted into the cart alongside other selected products. Click on the cart button to pull its container into view with those selections. Inside this container, clicking items sends them back to their initial positions in the grid.

Building this functionality without the Flip plugin would take quite a bit of time and strategy. GSAP just handles all of that critical code; the rest is left up to our wild imaginations!

Let's get into some of the key features that bring this animation to life.

How it works

The "Usage" section of the Flip plugin docs breaks this down into three steps that are followed to execute this add-to-cart animation:

Get the current state
Make your state changes
Call Flip.from(state, options)

Step 1: Capture the state

When an item is selected, Flip's getState method is called to collect data about the item's current size, position, rotation, and skew. This gets stored in a variable before applying other DOM edits, style changes, and so on.

const state = Flip.getState(item);

Step 2: Make the changes

After capturing the initial state data, the item gets appended as a child of the cart button.

cartBtnWrapper.appendChild(item);

Step 3: FLIP it!

The selected item is ready to animate from its current grid position over to the cart button. Time for the Flip plugin to dazzle us all with its magic. ✨

Flip.from(state, {
  duration: reducedMotion ? 0 : 0.5,
  ease: "back.in(0.8)",
});

Flip checks out the stored state object, compares it to the item's current state data, and immediately sets the position and size so that the item appears to still exist in its grid placement. Then the item transitions to its actual placement inside the button by animating the removal of these position and size offset values.

I did nearly nothing here. This is all GSAP Flip sorcery. My goodness it's good.

In order to get the item to move into the cart once the animation has finished, the onComplete callback is used to append the item as a child.

Flip.from(state, {
  duration: reducedMotion ? 0 : 0.5,
  ease: "back.in(0.8)",
  onComplete: () => {
    cartItems.appendChild(item);
  },
});

After that, other animations are run such as sliding the item into place and the acrobatic front flip of the count badge. This project is all about the flips. Be sure to jump into the full JS code for those implementation details.

Wrapping up

This experiment seems like it only just begins to harness the superpower supplied by the GSAP Flip plugin. I'm looking forward to seeing how you all utilize this in projects. As always, with this great power comes a lot of responsibility. Consider folks that prefer reduced motion or how larger layout animations could affect the overall experience.

Friendly feedback forever welcome. Share with me on Mastodon.

Helpful resources

Website Themes and Color Schemes

2022-02-01T00:00:00Z

Getting into the mode

Before we begin, I'd like to preface this article with the following resources that were helpful guides on my theming quest. They explain a lot of the intricacies of setting up dark mode and I recommend reading them before my own.

Read those already? Skimmed them a fair amount at least? Fantastic. Let's jump into the theming details for this website.

Range of styles

My first go-around with theme switching was handled with an HTML range input (dubbed theme slider). Each input value correlated to a CSS ruleset. Interacting with the theme slider did a couple things:

Set a data-theme attribute on the <html> element.
Saved the theme value to the browser's local storage to be referenced on subsequent site visits.

Each theme changed the site colors set in CSS custom properties. I've simplified the code in these examples for the sake of brevity.

[data-theme="1"] {
  /* dark theme */
  --color-text: papayawhip;
  --color-bg: midnightblue;
}

/* ...rulesets for themes 2 through 4... */

[data-theme="5"] {
  /* light theme */
  --color-text: darkslategray;
  --color-bg: lightsalmon;
}

The min and max attributes on the theme slider were set to 1 and 5 respectively, allowing five different themes. If the slider had not yet been moved, a theme was applied to the site based on color scheme preferences in a user's system settings. By default, color values were set to CSS custom properties. These values were then updated for dark mode within a prefers-color-scheme media query.

In the following example, you'll notice that the base default colors are the same values in data-theme="5" and then get updated to match data-theme="1" for the dark color scheme preference.

:root {
  /* same values used in theme 5 */
  --color-text: darkslategray;
  --color-bg: lightsalmon;
}

@media (prefers-color-scheme: dark) {
  /* same values used in theme 1 */
  :root {
    --color-text: papayawhip;
    --color-bg: midnightblue;
  }
}

This first iteration felt limited. Preferred color scheme values were tied to specific themes (1 for dark, 5 for light/no-preference) and disconnected from the values sandwiched in between. It was a fine start but left me wondering about other ways to handle these preference settings.

Decoupling scheme and theme

When I first migrated over to 11ty and added more pages to this site, the theme switcher was still only accessible on the homepage. While moving this component into a global layout, I was hit with some swell brain activity:

Instead of relating light and dark mode settings to specific theme values on the slider, they could alter each theme as variants.

🤯

Here's what I came up with. The theme slider works the same as before but now has a new neighbor: a color scheme toggle button. This button sets a light or dark version of the current theme. My selection of colors may be somewhat arbitrary and subjective, but I tried pairing palettes that complement one another.

Open CodePen demo

What I like about this theming model is that it welcomes future variants based on other user preferences and system settings. For instance, introducing high and low contrast styles for each theme using the prefers-contrast media query.

Redundant rulesets

One minor issue is that the same set of styles need to be declared twice for an initial theme to handle dark mode as both a system setting and user-selected preference. Since I'm using Sass, I've abstracted the values into a mixin to avoid the repetition. Below is a reduced example; Review the SCSS tab in the CodePen above for the full code.

@mixin color-scheme-dark {
  --color-text: papayawhip;
  --color-bg: midnightblue;
}

:root {
  --color-text: darkslategray;
  --color-bg: lightsalmon;

  @media (prefers-color-scheme: dark) {
    &:not([data-color-scheme]) {
      @include color-scheme-dark;
    }
  }

  &[data-color-scheme="dark"] {
    @include color-scheme-dark;
  }
}

A hefty thanks to Andy Bell's article for its usage of the :not selector. This ensures that the system settings do not override the user-selected color scheme. It also helped reduce some of the redundant code.

Keyboard combo control

Keyboard navigation and interaction for these two elements works as one might suspect. The button toggles between dark and light mode. The range input updates the theme value. It's debatable that they are best left like that. However, I wanted to explore a version that combined these element interactions; A way to cycle through themes and toggle their light/dark variants as a single control.

tabindex="-1" is set on the theme slider so it's no longer focusable in the keyboard tab sequence.
When the color scheme toggle button is focused, left and right arrow keys cycle through the theme slider values.
The space bar and enter key toggle light and dark mode.
Visually, the toggle button has a focus outline with a left/right arrow icon beside it.
A screen reader informs us that we can press the left and right arrow keys to change the theme in addition to our default button control.

Theme status

One last feature is the usage of the status role, another gem from Andy's article. An HTML element with a role="status" attribute is grouped next to each control. Although visually hidden, when the content inside these containers changes, assistive technology will relay that update back to us.

Clicking the color scheme toggle button announces the change to light or dark mode.
Changing the value in the theme slider announces the new theme being displayed.

Something I enjoy about the latter bullet point is that it reveals the actual theme names which are based on ice cream flavors. Without inspecting code, it's currently the only path to this discovery. What's cooler than being cool? Ice cream.

Ending theme

Thanks for joining while I recounted the tale of my website's first theming trial and its follow-up adventure. Some of the patterns here may change over time but this has been a blast putting together. I'm no champion of color, but I think these are some good lookin' themes.

If you have your own unique implementation or favorites out there on the wild web, please share! Max Böck and Josh Comeau have beautiful theme switchers and wrote detailed articles about their journeys. Definitely worth the read:

Horizontal Scrolling in a Centered Max-Width Container

2022-03-11T00:00:00Z

The layout challenge

When I had first assembled a gallery of CodePen projects to include on my personal site redesign in the summer of 2021, I imagined the following layout and interaction:

The page's main content container is centered on the page with a max-width set.
The first gallery item aligns with the left side of the content container.
Items overflow to the right and beyond the viewport, indicating that it can be scrolled horizontally.
Once scrolling is initiated, the left side of the gallery would break out of the content container, eventually sliding past the left edge of the viewport.

This was a tough layout to get right! Ultimately, I decided to go with a slightly different homepage design that didn't rely on aligning the start position inside the page content area.

Revisiting the desired result

The altered design worked well. But I still couldn't shake it. There had to be a way to build that original layout. Turns out nearly anything is possible with CSS these days. Here's a CodePen containing some gallery examples:

Open CodePen demo

I shared this solution on Twitter back before I had a blog space. Now that I do have one, I thought I'd take a deeper dive into how I achieved the final result.

Using a full-bleed layout

Josh Comeau's Full-Bleed Layout Using CSS Grid is an article I reference often. It's a solid, modern approach to limit the maximum width of page content while allowing "full-bleed" elements such as images to stretch across the viewport width. This style of layout has been achieveable by other means as discussed at length in Full Width Containers in Limited Width Parents on CSS-Tricks but I agree with Josh's sentiment about negative margin approaches being a bit hacky in comparison.

The CodePen above follows Josh's padding example but adds some named template areas which I'll explain:

.content {
  display: grid;
  grid-template-columns:
    [full-start] 1fr
    [content-start]
    min(var(--content-max-width), 100% - var(--space-md) * 2)
    [content-end]
    1fr [full-end];
}

.content > * {
  grid-column: content;
}

.gallery {
  grid-column: full;
  /* other gallery code */
}

The first and third columns are set to 1fr, causing them to fill the space surrounding either side of the second. The value of the second column is calculated by a CSS min() function, which selects the smaller of its two values depending on the window size. On screensizes smaller than --content-max-width, padding is created on either side by doubling a space value and subtracting it from 100% to suppress any unwanted page overflow.

A noticeable difference in this code are the named grid lines declared in grid-template-columns. Appending -start and -end creates a named area (or custom-ident) that can be referenced in a child element's grid-column property. When applied, an element will span the area between these two lines.

content becomes an identifier for the page content area. It will fill the second column of the grid and is the same as declaring grid-column: 2.
The full identifier stretches across all the columns. This is equal to grid-column: 1 / -1.

This approach removes the need for a "full-bleed" utility class on HTML elements. Instead, full and content become reusable values in the CSS for child elements when grid-column is declared. If the columns template should change at all (adding additional values, adjusting sizes) the named areas stay the same.

Creating the gallery styles

With the page layout finished, we can move on to the gallery component, starting on the top-level gallery element:

.gallery {
  grid-column: full;
  display: grid;
  grid-template-columns: inherit;
  padding-block: var(--gap);
  overflow-x: scroll;
  overscroll-behavior-x: contain;
  scroll-snap-type: x mandatory;
  scrollbar-width: none;
}

This is where scroll behavior and scroll snapping are handled, as well as stretching the viewport width. It inherits the grid-columns-template from the parent grid, acquiring the same column values and named grid lines.

In browser developer tools, we can enable layout grid lines visually and get a sense of how it's all working. I'm using Chrome dev tools in the screenshot below but Firefox and Safari share similar steps.

Open the Layout panel and select "Show line names" from the Overlay display settings dropdown.
In the Elements panel, click on the grid pills to the right of the main content and gallery elements to toggle their grid line visibility.

Dev tools can be used to visualize the overlap of the gallery's grid lines on top of the parent container's grid lines.

The inner wrapper

In order to align the initial project item to the page content area, a wrapper element surrounds the project items and has grid-column: content declared. Remember that the gallery inherits grid-template-column from its parent so the named area identifiers are available.

.gallery .wrapper {
  grid-column: content;
  display: flex;
  align-items: center;
  gap: var(--space);
}

.gallery .wrapper::after {
  content: "";
  align-self: stretch;
  padding-inline-end: max(
    var(--space),
    (100vw - var(--content-max-width)) / 2 - var(--space)
  );
}

A flex display is applied to the wrapper so that its children line up in a single row. The gap property adds the gutters between each child.

The wrapper also introduces a pseudo element as a spacer after the last project item to keep it from stopping right on the viewport edge. To make my original spacer code even better, Maarten Bruggink shared a fantastic suggestion that supports scrolling until the last element aligns to the right side of the page content area, even on larger screensizes. 👏

The projects

Adding flex-shrink: 0 on project items keeps them from collapsing to fit within the gallery wrapper. I've applied a combination of inline-sizing and aspect-ratio to projects in this demo so that they share the same responsive dimensions. It's not required though! Depending on what the gallery intends to accomplish, some project items could be wider, some tighter, and the layout would work as you'd expect. In the CodePen demo, scroll down a bit for an example.

A fun scroll snap tidbit

Something that I found really interesting: scroll-snap-align can be declared on nested elements! Notice that scroll-snap-align: center is set on project items. Although, while this works nicely for the center value, the result is not what you might hope for when using start or end. The elements are aligning to the scroll container edges of the gallery, which handles the scroll snap positioning, not the wrapper.

Reverse scroll direction

Scroll direction is handled quite gracefully. For languages that read from right to left, project items will be flipped appropriately thanks to their parent wrapper's flexbox display. The first item aligns to the right edge of the page content area and the gallery scrolls in from the left. Check the CodePen demo for an example of this further down the page.

For more information on this, RTL Styling 101 is an excellent guide. I recommend the Flexbox Layout Module section to learn more about flexbox and right-to-left styling.

CSS is awesome

CSS Grid and Flexbox open the doors to so many layout patterns that, not long ago, were nothing but impossible to produce without leaning into JavaScript. There are so many more exciting new features coming to CSS that will continue to push the boundaries of what we can create. If CSS Cascade Layers are any indication, browser teams are working hard on implementing these features faster than ever.

Helpful resources

Inverted Media Queries and Breakpoints

2022-07-05T00:00:00Z

The occasional breakpoint

Nowadays I lean on modern CSS solutions, fluid layout patterns, and intrinsic sizing over viewport dimension-based media queries – typically referred to as breakpoints – that adapt a design at particular screen sizes. Let's not forget that container queries will soon join our CSS toolset, expanding the exciting universe of parent context styling.

However, I do still find the occasional place to apply adaptive styles. Common example: a "desktop" menu (imagine a horizontal list of navigation items) that converts into its "mobile" counterpart (imagine a hamburger button that toggles a vertically stacked menu's visibility). After building out the foundational styles, I often prefer separating adaptive CSS properties versus having to override or unset them. This means I end up with rulesets that might look like this:

.menu {
  /* base styles */
}

/* below 600px */
@media (max-width: 599px) {
  .menu {
    /* narrow viewport styles */
  }
}

/* 600px and above */
@media (min-width: 600px) {
  .menu {
    /* wide viewport styles */
  }
}

Notice the single pixel difference in the two values, 599px and 600px. If these min- and max-width queries shared the same value, then there would be a single pixel overlap where both styles would apply. Not ideal!

Invert the media query

One way around this is to negate the media query. The not keyword in a media query will invert the query's meaning. To let both values in the previous example be the same, I could instead reuse a query and then invert it:

/* below 600px */
@media not all and (min-width: 600px) {
  /* "... */
}

/* 600px and above */
@media (min-width: 600px) {
  /* "... */
}

If your current browser window is large enough, you can resize the CodePen result window below to see the text and background color change based on their respective media query declarations:

Open CodePen demo

Future CSS solutions

Level 4 media query range contexts, which are getting closer to full modern browser support, will allow use of the same value:

/* @media (max-width: 599px) becomes */
@media (width < 600px) {
  /* ... */
}

/* @media (min-width: 600px) becomes */
@media (width >= 600px) {
  /* ... */
}

I really dig that syntax. I personally find it easier to understand and maintain.

Another exciting solution involves custom media queries, which would allow us to store the media feature to a variable:

@custom-media --breakpoint (min-width: 600px);

/* below 600px */
@media not all and (--breakpoint) {
  /* ... */
}

/* 600px and above */
@media (--breakpoint) {
  /* ... */
}

It seems that this won't be available for a while as it's in a draft of the level 5 media queries spec, but the good news is that there's a PostCSS plugin that give us this power today. 👏

Helpful resources

The Infinite Marquee

2022-08-06T00:00:00Z

The deprecated tag

The HTML <marquee> element had blessed (cursed?) the early days of the internet with the ability to insert scrolling text onto a webpage. It even included options to control text behavior once it reached the end of its container with a handful of attributes. Review them here on MDN if you're curious. Also, when visiting that MDN link, notice the page starts with a deprecation warning that this feature is no longer recommended:

Avoid using it, and update existing code if possible [...] Be aware that this feature may cease to work at any time.

A handful of usability concerns led to <marquee> eventually being nixed. They can be too distracting, don't respect reduced-motion preferences, and in most cases render text unreadable. Things get really out of hand if there are multiple <marquee> visible on screen like this example from MDN.

Fun? Maybe. But maybe don't do that.

A modern approach

Now that we've gleaned a tiny slice of web history, it's arguable that a marquee-style animation can inject some pop to a page when done responsibly. Developers have discovered a few ways of reimagining the concept, the most popular accomplished with HTML and CSS. In this scenario, content is duplicated to create the illusion of it looping indefinitely. Here's a stripped-down example:

<div class="marquee">
  <ul class="marquee__content">
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
  </ul>
  <!-- Mirrors the content above -->
  <ul class="marquee__content" aria-hidden="true">
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
  </ul>
</div>

The marquee concept has been done plenty of times and may seem old hat. However, most of the examples I came across weren't fully responsive. Many rely on a fixed-width parent or having enough elements to overflow the container for a seamless loop. What if, when the parent container is wider than the content overflow, the items spread themselves out so that the loop works at any size? I experimented with a few ideas to see what's possible in making this concept more flexible.

Here are the responsive styles that correspond to the HTML code block above:

.marquee {
  --gap: 1rem;
  display: flex;
  overflow: hidden;
  user-select: none;
  gap: var(--gap);
}

.marquee__content {
  flex-shrink: 0;
  display: flex;
  justify-content: space-around;
  min-width: 100%;
  gap: var(--gap);
}

To get a better sense of what's happening, open up this CodePen demo. Try turning each CSS rule off and on to see how it affects the marquee. Adjust the amount of items in the marquee's HTML. Watch how they spread out as the viewport widens or naturally overflow as it narrows.

Allow me to explain what this CSS is doing.

A flexbox display is applied to both the .marquee parent and .marquee__content child containers. This places every item on a single row without any wrapping.
There is a hidden overflow set on the parent. When the animation loops, the overflow conceals the elements snapping back to their start positions.
user-select: none disables highlighting or selecting text inside the marquee.
flex-shrink: 0 prevents the child containers from shrinking, avoiding overlap of content.
min-width: 100% stretches each child container to the parent width. With this rule, the first child container is visible while the duplicate container is hidden in the overflow.
justify-content: space-around evenly distributes space between each child container item, then applies half of that as empty space before the first item and after the last.

As items begin to overflow, gaps can be set to create room between each item. Gap values for the parent and child containers will need to match; Well that's a perfect case for defining a new CSS custom property! The gap: var(--gap) declaration supplies the space between each item when content overflows the parent plus space between the two child containers. This variable also comes in handy to offset the end position in the animation precisely:

@keyframes scroll {
  from {
    transform: translateX(0);
  }
  to {
    transform: translateX(calc(-100% - var(--gap)));
  }
}

Without including var(--gap) in this calculation, there would be a visible misalignment when the animation loops. Try updating the value to translateX(-100%) to see the issue.

The appearance of an infinite loop happens by animating the first child container completely out into the overflow while simultaneously pulling the duplicate container all the way into view. When the animation restarts, the first container picks up where the last left off. The illusion is complete! Yet it's also neverending... 😮

Important considerations

Really examine the use case for a marquee. They can be incredibly distracting and disorienting when implemented poorly.

Use them sparingly. Overloading a page with a bunch of auto-scrolling areas is never a good time.
Marquee content should be purely decorative. Leave out important page copy and focusable elements.
Animation speeds should be slow. Content scrolling by super fast can be nauseating even for those that don't have reduced-motion enabled.
Respect reduced-motion preferences. If set, best bet would be to completely disable auto-scrolling.

Welcome to the demo zone

Here are a couple of CodePen ideas I had thrown together while experimenting with marquee animations. The logo wall is especially fun, introducing reverse animations and the ability to toggle the axis for a vertical marquee.

Explore more resources

Layout Breakouts with CSS Grid

2022-10-07T00:00:00Z

A post about the layout you're looking at right now

The previous structure of this page layout was virtually the same, the foundation of it expertly defined in the article Full-Bleed Layout Using CSS Grid by Josh Comeau. It's a technique I've used on many projects. I've even blogged about it previously in Horizontal Scrolling in a Centered Max-Width Container.

What I'm documenting here is an extension of the full-bleed CSS Grid layout. In the last version of my site, selected elements – images, code blocks, quotes – were made wider than the page content area using negative margins. It worked well! For this next iteration, I explored applying these breakout offsets using CSS grid and named grid lines.

Layout setup

Below are the styles applied to the main content container, defining the grid display and its columns template:

.content {
  --gap: clamp(1rem, 6vw, 3rem);
  --full: minmax(var(--gap), 1fr);
  --content: min(50ch, 100% - var(--gap) * 2);
  --popout: minmax(0, 2rem);
  --feature: minmax(0, 5rem);

  display: grid;
  grid-template-columns:
    [full-start] var(--full)
    [feature-start] var(--feature)
    [popout-start] var(--popout)
    [content-start] var(--content) [content-end]
    var(--popout) [popout-end]
    var(--feature) [feature-end]
    var(--full) [full-end];
}

In the grid-template-columns declaration, column areas are represented by keywords wrapped in square brackets suffixed with -start and -end. These keywords are set as grid-column values on elements residing in this container.

Starting at the edge for an example: [full-start] and [full-end] represent the full-bleed. Any child element containing grid-column: full; will span its parent's available horizontal space.

Each grid line is accompanied by a CSS variable of the same name, which supplies the inline size or width of the column. Outside of the center column block (the content area) that same variable is used after the -start and before the -end positions so their sizes match on either side. Continuing with the full keyword example, these values are [full-start] var(--full) and var(--full) [full-end].

I like to imagine each keyword's area blooms out from the center. popout grows out of content, feature from popout, then full blossoms all the way to the edge. The horizontal space each keyword covers is the sum of values between its -start and -end points.

As a way to visualize this grid, I've created a fresh CodePen demo below. Click the "show grid lines" checkbox and resize the browser window to get a sense of how the layout expands and collapses.

Open CodePen demo

In the CSS tab of that demo, we can see how these grid areas are being applied. The first ruleset, .content > *, matches all direct children of the container, setting them to the center content area. Cascading rulesets then revise grid-column with their respective keyword values.

.content > * {
  grid-column: content;
}
.popout {
  grid-column: popout;
}
.feature {
  grid-column: feature;
}
.full {
  grid-column: full;
}

Having fun with sizing functions

Much of the real magic here is through the use of minmax(). It permits the flexible structure of this layout, elements breaking free on larger viewports and collapsing back in when less space is available. Or, as MDN and the CSS Spec describe it:

The minmax() CSS function defines a size range greater than or equal to min and less than or equal to max

Let's revisit the CSS variables declared at the top of the ruleset. I'll explain how this all works in harmony.

--gap: clamp(1rem, 6vw, 3rem);
--full: minmax(var(--gap), 1fr);
--content: min(50ch, 100% - var(--gap) * 2);
--popout: minmax(0, 2rem);
--feature: minmax(0, 5rem);

--gap represents a gutter size for the left and right sides of the page. This value leans into the clamp() function for more fluid, flexible sizing.
--full stretches an element so that it spans the entire horizontal space. By setting --gap as the min value, it also takes on the role of visible page gutters for smaller screens.
--content acts as the main content area. The min() function sets the max-width of this column. Once the available space falls below this value, it then switches to 100% while also subtracting the left and right gutter sizes.
--popout and --feature extend elements beyond the content area by 2rem and 5rem respectively. As the available horizontal area tightens, these values collapse down to nothing, aligning elements with the main content space on smaller screens.

Losing floats

Alex Carpenter's tweet exposes a limitation in this layout pattern: we lose the ability to float elements. For example, we wouldn't be able to float an image to the left and wrap text around it. The full-bleed solution from the CSS-Tricks article Full Width Containers in Limited Width Parents is handy in this situation.

Breakout session

That wraps things up! The potential of this concept doesn't stop here. How might you extend or refactor? Drop me a note on Twitter with your awesome layout ideas. 🙌

This article was updated on October 12th, 2022 to include the "Losing Floats" section.

Helpful resources

Creating Time

2023-01-20T00:00:00Z

For my birthday, my partner put together the sweetest, most thoughtful surprise I could ever imagine. She recognized that I had been in a complete creative rut the previous year. I'd complain that I work too much, play too little. I'm too tired. Way too busy. This, that, and the other thing is blocking my time. Sometimes I would straight up conclude that I'm just not good at anything—a collaboration between imposter syndrome and plateauing.

I'd often sink into the couch after a long day instead of logging time towards hobbies or creative projects. All day screen time had frazzled my mind. But then I'd follow up with more of it, doomscrolling on my phone or gazing at the television. Not a lot was being accomplished outside of work hours.

While I did play my guitar a good amount, I never completed any song arrangements. Last year I convinced myself to blog more, my goal set on writing a post every month or at least six articles in 2022. I acheived the latter, which I'm proud of, but maybe, maybe, I could have put more effort into my original milestone of twelve posts.

Anyway, returning to where I began: On my birthday, my partner reveals that she booked a house where we would be staying with some close friends and family. To sprinkle on even more excitement, the property she booked includes a music studio with a drumkit ready for rockin’. I haven't been able to sit behind the drums for several years (blame the pandemic, me moving around a bunch, drums simply being too loud to play in a condo, etc.) so this news was absolutely thrilling.

The people brought together for this getaway were selected based on a few magical moments throughout my life's musical journey. I have reminisced about week-long writing/recording sessions, staying up all night arranging tracks, playing take after take to get it right, and never letting exhaustion from the work day stop me. My partner understands how music lifts my spirit. Her gathering these folks for three nights of jamming was the greatest way to kick off a new year.

I don't necessarily desire to chase new year resolutions. However, this music trip felt like a solid step towards—forgive me for saying it—changing my tune. I'm going to refocus my time and play more. I'll complete that song arrangement I've left fragmented. I'll write brand new ones. I'll make things out of clay, build with legos, draw, write, and take better care of my creative brain. All the while, I will remind myself that it's okay to be in a creative rut from time to time.

Along with this week's jam sessions, I've also started reading The Artist’s Way by Julia Cameron. It's only week one, but I've been writing three pages each morning, pouring out stream of consciousness via pen on paper. The idea is to connect the mind and body, writing longhand to declutter brain space before starting the day. Doesn't matter what I'm jotting down. Just write.

Once I really embraced these morning pages, I discovered that I feel accomplished, calm, and clear-headed. Other discoveries: My hand cramps up very quickly and my handwriting looks like garbage.

It doesn't matter.

This is not for anyone to read. It's not even something I plan to reflect back on. I'm looking forward to filling every page in that notebook and then promptly tossing it in the trash, moving on to the next one.

So what's next? Here's are some things I would like to be doing more, starting right now:

Finish song arrangements and record that music.
Explore the amazing realm of guitar pedals.
Make stop-motion claymation videos.
Write the music for those videos.
Sketch while I watch television.
Read more books—physical copies preferred.
Stretch when I wake up. Like for at least five minutes.
Discover a new hobby. Something different to awaken my creative brain.
Dance. If I want to.

CSS Grid Gap Behavior with Hidden Elements

2023-02-14T00:00:00Z

I was recently prototyping a component layout that included a way to toggle the visibility of sibling elements inside a grid display. What tripped me up was, while these elements were hidden, all of the container's gap gutters remained, leaving undesired extra visual spacing. I expected these gutters to collapse. The reason they stick around is related to explicitly defining grid templates.

Template or auto layout?

What are the differences between grid-template-* and grid-auto-* when declared for columns or rows in a grid layout? Ire Aderinokun has a fantastic article that thoroughly explains these distinctions and I recommend giving it a read. I'll try to quickly summarize: grid-template-* sets explicit column and row tracks, while grid-auto-* creates implicit track patterns.

The following excerpt in the "How grid-auto works" section from the article stood out to me:

Unlike the grid-template-* properties, the grid-auto-* properties only accept a single length value.

After some experimentation and confirming through examples from the Syntax section in the grid-auto-rows MDN web docs, I found that multiple track-size values can be used as well. Let's try an example to create a layout commonly referred to as the pancake stack. Its value of auto 1fr auto will either:

explicitly size and position only the first three rows when used in grid-template-rows
act as a pattern to implicitly size each group of three rows in grid-auto-rows

Visualize the gap

In the CodePen demo below, tick on the "Hide elements" checkbox to assign display: none on all but the first two elements in both grid containers.

Open CodePen demo

So what's happening here? When collapsed, the grid-template-rows container is slightly taller than its grid-auto-rows counterpart because of the extra space appearing beneath the remaining visible elements. Recall that rows are explicitly set with grid-template-rows. In this situation, the gap gutters still apply even when elements are hidden or removed from the container.

I ended up moving forward with grid-auto-rows for my component's layout needs. You can see a stripped down version of it in the CodePen below. The classic small screen navigation!

Open CodePen demo

A template solution

If using grid-template-* is preferred or necessary, the solution is to override the property value to match the expected visual result. The above demo could even get by on a single ruleset that applies the template only when the menu is open:

.nav.is-open {
  grid-template-rows: auto 1fr auto;
}

This same solution can also work for grid-template-areas. While it leads to writing more code, it self-documents really nicely.

.nav {
  grid-template-areas: "logo toggle";
}

.nav.is-open {
  grid-template-areas:
    "logo toggle"
    "menu menu"
    "cta  cta";
}

.nav .logo {
  grid-area: logo;
}
.nav .toggle {
  grid-area: toggle;
}
.nav .menu {
  grid-area: menu;
}
.nav .cta {
  grid-area: cta;
}

Helpful resources

Sticky Page Header Shadow on Scroll

2023-04-02T00:00:00Z

We've seen it plenty of times around the web where a website's page header follows us as we scroll down the page. CSS makes doing this a breeze with sticky positioning:

.page-header {
  position: sticky;
  top: 0;
}

What if we desired something a little bit extra, like applying a box-shadow to the sticky header as soon as the page is scrolled? I thought it was worth sharing one solution that has worked well for me to accomplish this goal. Check out the following CodePen demo. As soon as the page is scrolled, a shadow fades in below the header.

Open CodePen demo

An element that I've decidedly dubbed an "intercept"—naming is hard and this felt right in the moment—is created and inserted above the page header at the top of the page. If we open the browser dev tools and inspect the DOM, we'll find:

 <div data-observer-intercept></div>
 <header id="page-header">
  //...
 </header>

The Intersection Observer API is being used to observe when the intercept is no longer appearing in the visible viewport area which happens as soon as the page scrolls. So when the intercept is not intersecting, a class is applied to the header element.

const observer = new IntersectionObserver(([entry]) => {
  header.classList.toggle("active", !entry.isIntersecting);
});

observer.observe(intercept);

Inspecting the DOM again, we'll catch the active class name on the page header element toggling on and off as we scroll down and back up.

Delay that shadow

It's also possible to wait on when the shadow should appear by offsetting the intercept element. Try editing the above demo on CodePen. In the CSS panel add the following ruleset:

[data-observer-intercept] {
  position: absolute;
  top: 300px;
}

This will push the intercept down from the top of the page by 300 pixels. When scrolling the page again, notice that the shadow doesn't appear right away, waiting until the page has been scrolled passed the offset value.

CSS scroll-driven animations

Updated on October 20th, 2023: Here's another CodePen demo that leans into CSS scroll-driven animations. Try it out in a browser that supports this feature.

Open CodePen demo

I've been justifiably excited about browsers beginning to adopt this API, which I had written about in this blog post. It's not quite the same as using an intersection observer: The observer toggles a class selector that triggers an animation for the declared duration of time whereas this version links the fade progress to the page scroll position. I find that the latter feels more natural. If a browser doesn't yet support the feature, the styles gracefully degrade to a persistent static shadow.

Have questions? Other ways to handle this? I'd love to hear about it! Reach out to me on Mastodon with your ideas.

Full-bleed Table Scrolling on Narrow Viewports

2023-05-20T00:00:00Z

I found the following to be a rather decent solution for having HTML tables overflow the inline edges of smaller/tighter/narrow viewports. Try resizing the width of the browser window if viewing this page on a larger screen.

Open CodePen demo

Notice that the table overflows beyond the edge of the window. This can be acheived by wrapping the table element with another element.

<figure class="wrapper">
  <table>
    <!-- ... -->
  </table>
</figure>

On this wrapper, a combination of inline padding and negative margins create an offset that matches the page gutter size—that space to the left and right of the main content area. Here's a simplified example of those styles:

body {
  --page-gutter: clamp(1rem, 4vw, 2rem);
  padding-inline: var(--page-gutter);
}

.wrapper {
  margin-inline: calc(var(--page-gutter) * -1);
  padding-inline: var(--page-gutter);
}

clamp() is used to create fluid padding. The gutter size shrinks as the viewport gets narrower. Unfamiliar with how this CSS function works? Check out the docs on MDN.

The inline margin will pull the table wrapper to the viewport edge. Then inline padding pushes the table back into position so that it's once again aligned with the page content. Here's all the CSS necessary for horizontal scrolling and wrapper repositioning:

.wrapper {
  display: flex;
  overscroll-behavior-x: contain;
  overflow-x: auto;
  margin-inline: calc(var(--page-gutter) * -1);
  padding-inline: var(--page-gutter);
}

Setting display: flex on the wrapper element fixes a tiny issue in Safari (version 16.4 at the time of writing) where the inline padding at the end appears collapsed.

That's it! There are a handful of ways to display tables on smaller screens. I like that this solution requires very little code and doesn't rely on breakpoint changes. How might you solve this differently? Let's discuss!

CSS Custom Property Fallbacks in Shorthand Values

2023-07-14T00:00:00Z

CSS Custom Properties are incredibly versatile and have become especially useful as customizable props in common layout and component style patterns. Here's an example derived from the SmolCSS site:

.grid {
  --min: 15ch;
  --gap: 1rem;

  display: grid;
  gap: var(--gap);
  grid-template-columns: repeat(auto-fit, minmax(min(100%, var(--min)), 1fr));
}

The --gap and --min custom property values can be customized by declaring new values for those properties, whether it's through inline styles or a custom CSS ruleset:

<!-- inline style -->
<ul class="grid" style="--gap: 2rem">
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

<!-- custom ruleset -->
<style>
  .super-cool-list {
    --gap: 2rem;
  }
</style>
<ul class="super-cool-list grid">
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

Remember! The super-cool-list styles needs to be declared after the grid ruleset in the stylesheet. Otherwise the default --gap value inside grid would win with higher precedence. I'm a fan of using CSS cascade layers where layout primitives like grid would reside in a lower priority layer than component-specific styles.

I absolutely love this concept of altering layouts through exposed props like the example above. But what if we desired the ability to provide independent values for the horizontal and vertical spacing between each item? This is where a key feature of CSS custom properties comes into play: fallback values. In the revised version of the above code snippet, The --gap value declared at the start of the ruleset becomes the fallback—or default value—for two new variables.

.grid {
  --min: 15ch;
  --gap: 1rem;
  --row-gap: initial;
  --column-gap: initial;

  display: grid;
  gap: var(--row-gap, var(--gap)) var(--column-gap, var(--gap));
  grid-template-columns: repeat(auto-fit, minmax(min(100%, var(--min)), 1fr));
}

The gap property is shorthand for row-gap and column-gap respectively. With these values now split, we can pass in an override value to either axis.

<ul class="grid" style="--row-gap: 2rem">
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

The gap spacing between each row of items will now be 2rem while the columns stick to the default --gap size of 1rem.

Guaranteed-invalid values

--row-gap and --column-gap are both set to the initial keyword because it's a guaranteed-invalid value in custom properties. This means that these two custom property values will become invalid at computed-value time and revert to a fallback if one is available. I think this concept is summed up nicely in a snippet from this article:

[...] rather than being passed along to set background: initial or color: initial, the custom property becomes undefined, and we fallback to the next value in our stack [...]

In the example above, since --row-gap and --column-gap are undefined through the initial keyword, the fallback --gap value is applied.

Why not only use fallbacks?

Custom properties can have more than one fallback value—a concept Miriam Suzanne refers to as custom property "stacks" in this article, which I love. It's also where I discovered how initial works in custom properties as mentioned above.

So then if custom properties can have multiple fallback values, could we instead write our CSS like this?

.grid {
  display: grid;
  gap: var(--row-gap, var(--gap, 1rem)) var(--column-gap, var(--gap, 1rem));
  grid-template-columns: repeat(auto-fit, minmax(min(100%, var(--min, 15ch)), 1fr));
}

This works as one would expect. However, keep in mind that on the occasion there is a nested element that uses the grid selector, that element would inherit the --gap set on the parent.

<ul class="grid" style="--gap: 2rem">
  <li>Item 1</li>
  <li>Item 2</li>
  <li>
    Item 3
    <!-- This <ul> will also have a 2rem gap -->
    <ul class="grid">
      <li>Item 1</li>
      <li>Item 2</li>
      <li>Item 3</li>
    </ul>
  </li>
</ul>

By setting --gap at the top of the grid ruleset, the nested element's gap value will reset to that declared default. I personally prefer this. I can imagine headaches may come from having a very deeply (hopefully not too deep!) nested element where the gap value is different than the presumed default. It wouldn't be immediately clear, especially in a componentized codebase.

Inheritance is a good thing

This content has been revised on July 15th after a valid argument was made on my Mastodon post sharing the article in favor of inheriting ancestor custom property values:

Isn’t inheritance of custom properties a good thing? I thought that’s how they’re meant to be used. Setting a custom property once on an outer container, and then it inherits to all the nested components. I’m not sure that intentionally breaking this system is a good idea.

Excellent point, and agreed: Inheritance of custom properties is a good thing. This has certainly given me some pause on my preferred approach. I had imagined layout primitives such as the grid example would set ideal default values every time the selector is applied. Instead, when inheriting properties on a nested element, we would then have to add a "reset" value to revert it back, which arguably may be the optimal method.

<ul class="grid" style="--gap: 2rem">
  <li>Item 1</li>
  <li>Item 2</li>
  <li>
    Item 3
    <!-- Revert the value on this element -->
    <ul class="grid" style="--gap: 1rem">
      <li>Item 1</li>
      <li>Item 2</li>
      <li>Item 3</li>
    </ul>
  </li>
</ul>

What do you think? Please feel free to join us on the Mastodon thread with your opinions and feedback. Also, check out this CodePen if you'd like to experiment with the different methods described here.

Helpful resources

Every Layout has been a key staple in my layout style diet and I highly recommend going through all of it if you haven't already.
SmolCSS is a fantastic, robust collection of modern layout and component snippets. A must-bookmark for many revisits.
Using Custom Property “Stacks” to Tame the Cascade—a special thanks to Miriam's article for introducing me to some amazing, new (to me) custom property concepts.

Starting Exploration of Scroll-driven Animations in CSS

2023-08-21T00:00:00Z

CSS Scroll-driven Animations has recently made its debut on the main stage in the latest versions of Chrome and Edge. Before this module became available, linking an element's animation to a scroll position was only possible through JavaScript. I've been (and still am) a huge fan of GSAP ScrollTrigger as one way to achieve such an effect. I never imagined it would become a reality in CSS, but this new API lets us hook right into CSS animation @keyframes and scrub through the animation progress as we scroll the page.

My article will share demos and some early learnings about scroll-driven animations. If it's all new to you as well, I urge you to read Animate elements on scroll with Scroll-driven animations by Bramus and Michelle Barker's Scroll progress animations in CSS. They are both excellent deep dives into this new spec and helped me get a handle on how it works.

I had the chance to noodle around with both timeline types introduced in the Scroll-driven Animations spec:

Scroll Progress Timeline is connected to the scroll position of a scroll container along an axis.
View Progress Timeline links a timeline to the relative position of an element within a scroll container.

When getting started, these progress visualizer tools were immensely helpful. They were frequently referenced while I tinkered on scroll timeline animation ideas.

Experiment #1: Photo figures

I turned to a recent CodePen Challenge to begin my exploration, which leans into View Progress Timeline features. When scrolling the page in the Photo figures CodePen demo, notice that the heading text follows down as it fades out, the first three Polaroid-style photos have a "develop" effect, and the last stack of photos shuffle between themselves.

Your browser cannot play the provided video file.

Scrolling through the Photo figures CodePen demo

To make this happen, the way we write animation @keyframes hasn't changed. Instead, when applying that animation to an element, we introduce two new properties: animation-timeline and animation-range. Here's the simplified HTML for each "developing" photo as an example:

<figure>
  <div>
    <img class="develop-photo" />
  </div>
  <figcaption></figcaption>
</figure>

And the CSS for its scroll-driven animation:

figure {
  view-timeline-name: --photo;
}

.develop-photo {
  animation: linear develop both;
  animation-timeline: --photo;
  animation-range: entry 30% cover 40%;
}

@keyframes develop {
  from {
    filter: blur(30px);
    scale: 1.1;
    opacity: 0;
  }
  to {
    filter: blur(0);
    scale: 1;
    opacity: 1;
  }
}

When applying animations to the heading and shuffling photos, declaring animation-timeline: view() with an animation-range were the magic ingredients to enable scrubbing through animation progress on scroll. The view() function binds the animation to the element as it appears in the viewport on the block axis. This function takes two parameters:

The <axis> on which the timeline progresses.
A <view-timeline-inset> that adjusts the position of the box where the element is considered visible.

Since the default values are block and auto respectively, they can be omitted here.

Back to the example code above, I initially attemped to use the view() function on the "developing" photos but had no success. It seems that wrapping the img inside a div may be the reason—I believe that the overflow: hidden rule on the div now makes it the nearest scroll container for the img element. To get this photo animation working, setting view-timeline-name on the parent figure and then referencing it via animation-timeline ended up being the solution.

As for my chosen animation-range values? That was the result of much experimentation, playing with different combinations. I'm still getting the hang of it, but the Ranges and Progress Animation Visualizer Tool proved to be a crucial guide on my journey.

Additional notes

When working with these new animation properties, there are a few important bits to keep in mind:

animation-timeline is not part of the animation shorthand, so it must be declared separately. Also, be sure to have it appear after the animation declaration because that shorthand will reset any animation longhand value, including animation-timeline.
An animation-duration value in seconds won't affect a scroll progress timeline at all—always set it to auto. Since auto is the default value for this property, it can be omitted.
The both value represents the animation-fill-mode. This ensures the animation follows the @keyframes rules fowards and backwards, animating in both directions on the timeline.

Experiment #2: Weather app prototype

What excites me the most about scroll-driven animations is that it provides us the power to pull off some native-specific animation techniques directly in CSS. For example: the iOS weather app has been part of my daily ritual for quite some time. A lot of the app's animations are perfect for Scroll Progress Timeline! Check out my Weather app prototype on CodePen.

Your browser cannot play the provided video file.

Scrolling through the Weather app prototype on CodePen

As explained in the previous demo, the animation-range property seems to be very versatile. I've only just scratched the surface of what it can do. In my first attempt to set an animation-range on the intro text fades, I used percentage values. Unfortunately, those animations would become slightly misaligned as the scroll container changed in height. In retrospect, that makes sense but, at the time, I had not realized that any <length-percentage> is a valid animation-range value. Once I switched from percentages to rem units, my animations lined up as expected, regardless of the scroll container height.

Scroll-driven for more

Something that I dig about both of these demos? The scroll timeline magic acts as a progressive enhancement. That won't always be the case, but it's awesome to see that both demos work as expected without it.

It has been such a thrill being introduced to the delight that is CSS Scroll-driven Animations. With this and View Transitions API on the horizon, it seems that simulating native app animation behaviors on the web is upon us. Maybe we'll soon see the end of companies constantly nudging us to download their native apps while we're browing their web app? Maybe they'll let us navigate around their home on the web as we intended without interruption?

Dream big.

Helpful resources

Scrollspy Navigation Web Component

2023-10-07T00:00:00Z

Just here for the code and demos? Check out the scrollspy-nav repository on GitHub and its corresponding demo page.

The backstory

A "scrollspy" is a method of tracking which link in a menu is active based on a relevant section of information being visible in the viewport. Typically, the menu position is fixed to the browser window and the active link is indicated with some additional styling. I'm not 100% sure, but it might have started as a Bootstrap plugin. There have been a number of other versions and variations to follow.

This particular scrollspy-nav component had more specific needs, so allow me to break it all down:

A page contains sections of content, each with a unique id attribute.
There is a horizontal menu list of page anchor links. When a link is clicked, it jumps the page down to a related section of content.
When a section passes a certain threshold in the viewport, it becomes "active" along with its anchor link counterpart. It uses the Intersection Observer API to keep track of the active section.
A change in the active section updates the position of a marker element in the menu. The marker animates from the previous active anchor link to the next, resizing itself to the dimensions of the current link's inline size.
If a menu item is obscured in the viewport overflow horizontally, when it becomes active it will be scrolled fully into view.

I had messed around with this general idea some time ago, but a recent project design brought me back to those old experiments. This is my attempt at turning the concept into a web component and I thought I'd share the results with you all. The project hasn't been packaged on npm or anything because it's still, in my opinion, a work in progress. I've always been keen on web components but I am quite fresh in sharing my own.

What's in a name?

Deciding on what to call this component was tough—naming things is perpetually difficult. I settled on scrollspy-nav for conciseness, but I debated and refactored for a bunch of different names:

sticky-scrollspy-nav
scrollspy-section-menu
animated-marker-nav
marker-menu
scrollspy-navigation-with-sweet-animated-marker

That last one isn't true.

WebC

The first iteration of this was built as a WebC component since my project happened to be using 11ty and WebC. This allowed me to combine the script and style elements into a single file, then let 11ty and WebC bundle them to their designated buckets in my page layout. Sticking to that vibe, I have included a scrollspy-nav.webc file in the repo. All it does is pull in the css and js files. When the custom element is used on a page, the component code is then bundled appropriately.

Styling

This is where I'd really love to hear feedback from all the web component makers and advocates out there.

I opted to keep all the base styles in a separate css file. Most of the layout styles are necessary, although some of the gap spacing and margins are a bit opinionated. While I have tried moving the styles into a shadow DOM, I wasn't quite sure how I'd apply styling to nested selectors. Passing styles to the host and the slotted ul can be done:

:host {}
::slotted(ul) {}

But targeting any nested elements of the unordered list won't work. At least not from what I've tried. Regardless, I prefer the styles detached from the script so that they still get applied if javascript happens to be disabled in the browser.

For style overrides, this component provides a handful of --scrollspy-nav-* CSS custom properties. The demo page showcases a couple examples where the marker position, duration, easing, and style are altered with author-selected values.

FLIP the marker

In my previous experiments, the marker element was inserted as a direct descendant of the scrollspy-nav element. At first, everything looked great. The marker animated smoothly as the active link changed. However, this presented a couple issues. Most notably, when resizing the browser window, the marker would lose its positioning visually as the menu started overflowing the parent container.

So I thought: Maybe I could listen to a resize event and reposition it? That felt hacky and it might lead to other problems. What about appending the element to the active anchor link? That fixes the positioning woes, but how would I animate the marker from the previous active link to the next while keeping the animation smooth and performant?

It then finally dawned on me: I had forgotten about the wonderful FLIP (First, Last, Invert, Play) technique! I had even written about it before in Animating with the Flip Plugin for GSAP and, while Animating Layouts with the FLIP Technique on CSS-Tricks is now over six years old, it's still perfectly relevant to the topic.

For the marker animation, I capture the width and position of the previous (first) and new (last) active links, update layout so that the marker is now appended to the new element, get the delta between the two link positions (invert), and then run the animation (play) from the previous position to the new one. The resulting animateMarker method can be reviewed in the component script.

Adjusting for overflow

One last piece to call out is how the component handles active items hidden outside of the visible viewport area. Check out the demo page in a narrow viewport size. A hidden or partially hidden active link will slide fully into view by calling the scrollTo method on the menu and scrolling it along the X axis by setting the distance to the left option value.

Thoughts?

I'll wrap things up here. There are still plenty of UX enhancements to explore. Clearer indication that the menu scrolls horizontally and layout considerations in different writing modes are some that come immediately to mind. I'd love to hear what you like (or don't like) and how this component could be improved. Reach out to me on Mastodon and let's talk web components.

Site Rebuild, Here We Go!

2023-11-22T00:00:00Z

There are still a few bits to work out, but why wait any longer? The latest version of my site is here and it has been rebuilt from the ground up. I'm feeling pretty good about it and invite you all to celebrate the magic with me! ✨

Inspiration

While playing Super Mario Wonder, I found myself intrigued by the title screen transitions before each level. The skewed text atop its grid background pattern looked sleek yet playful. I began tinkering with some ideas and eventually came up with the blog post heading style seen above. At that point, I decided it was time to go for a full site rebuild.

Some more details

I plan to dive into some site features in future blog posts, but here's a quick list of all the exciting parts. Feel free to dig around the site repo as well.

I rebuilt from scratch. I stuck with 11ty but this time leaned 100% into WebC for templating.
There are some pretty neat (to me!) web components to be discovered in this project. Both of the following were built to progressively enhance the experience.
- The <scroll-pen> extends the homepage CodePen collection's keyboard interactions, adds video previews that can be disabled, introduces input range slider control, and the ability to toggle the skew.
- The <theme-machine> is what you might guess: A total package for changing the site appearance and adjusting theme colors.
The homepage includes a few dynamic stats about the latest site deployment date, what the weather was like during that time, and the latest track I had been jamming to on Spotify.
I've been messing around with scroll-driven animations in CSS a lot and why not be a little extra? When using a supported browser on a wide enough viewport, notice that a progress timer appears on blog posts. The progress ring fills itself up as the page is scrolled.
My eleventy config is feeling more organized than ever. It was very much inspired by Lene Saile's Organizing the Eleventy config file article.

It's very early in the morning as I write this. I know I'm forgetting so many of the finer details but I couldn't wait to launch. There is still much for me to clean up and tinker on, but the time feels right to go public. Toot at me on Mastodon and tell me what you think!

..."Toot at me" may not be the best way to word that.

We can :has it all

2023-12-19T00:00:00Z

The functional :has() CSS pseudo class is now shipping in all evergreen browsers! 🎉

With the release of Firefox 121.0, I'm excited to see that my semi-dusty :has() demos are finally realizing their full potential in Firefox. The amount of opportunity unlocked with this selector seems nearly infinite. It can simplify some of the more complex CSS selectors and hacks used in the past. It also opens the door to replacing JavaScript solutions that weren't yet possible to achieve with only CSS.

This post is merely a celebration of :has() browser support and shares a quick dive into some of my previous experiments. At the end of this article are helpful resources that do an amazing job explaining how the selector works and the unbelieveable power it gives us.

Themes, layouts, and filters

This first demo showcases how :has() can be used to set a dark mode, change the layout, and toggle the visibility of elements. All of it can be achieved through a combination of the :has() and :checked selectors.

Open CodePen demo

To pull off this primitive filtering technique, each card has a data-category attribute. When a filter option is selected, only the cards with that particular category will remain visible. Check out the following HTML example:

<article class="card" data-category="bakery">
  <!-- card contents -->
</article>
<article class="card" data-category="taquería">
  <!-- card contents -->
</article>
<article class="card" data-category="café">
  <!-- card contents -->
</article>

If the bakery filter option is selected, then the second and third cards would be hidden. Here's the CSS that hides all non-bakery cards:

body:has([name="filter"][value="bakery"]:checked) .card:not([data-category="bakery"]) {
  display: none;
}

[name="filter"] can be omitted from the selector above given the current circumstances. As things get more complex, however, there could be value overlaps that cause unintended results. This explicitness does raise specificity, but it can be reduced by using a :where() selector if preferred. Semi-related: The truth about CSS selector performance is a good read!

Using :has() to alter layout and filter collections of elements is incredibly powerful. Although, let's understand that there are important accessibility considerations to make here. Don't do something like this in production without ensuring all folks are enabled with a proper experience.

Skate or theme!

In the next demo, the select dropdown acts as a progressive enhancement. The skateboard's theme will update based on the option selected. The following is a simplified example:

:root {
  --color: black;
}

body:has([value="lightning"]:checked) {
  --color: yellow;
}

body:has([value="holiday"]:checked) {
  --color: green;
}

Open CodePen demo

This project has always been one of my personal favorites. It brings me a fair amount of joy seeing it working fully in Firefox.

Helpful resources

Web Component

2023-12-22T00:00:00Z

There are very rare occasions that I want <details> element disclosure widget-style funtionality but would like to have the <summary> element detached or live outside of it's related <details> container. This commonly stems from designs that may, for example, expect a toggle button to appear inline with other controls or content. Here's my attempt at a Web Component to handle that pattern.

The gist of this component is to enhance an HTML <button> with the ability to toggle an element's visibility anywhere on a page. Simply wrap a button element with this component and supply a target-id attribute that matches the id of any page element.

<script type="module" src="target-toggler.js"></script>

<target-toggler target-id="more-info">
  <button>Show more info</button>
</target-toggler>

<section>A special announcement</section>

<section id="more-info">
  <!-- some additional information -->
</section>

In the above example, a hidden attribute will be added to the targeted more-info element. Now the button toggle can control the visibility of that piece of content. Want that content to be visible by default? Add a target-visible attribute.

<target-toggler target-id="more-info" target-visible>
  <button>Show more info</button>
</target-toggler>

Be sure to check out the demo page for examples of this component in action.

Improvements

Want to weigh in? Add a new issue to the repo and share your ideas! I highly value any community feedback on how to improve this implementation.

Helpful resources

Click Spark

2024-01-02T00:00:00Z

Last week I had made this fun little experiment. When clicking or tapping on the page, sparks (of joy) fly out from the mouse cursor/tap position. It started with me just messing around a bit in CodePen, but after sharing and getting a few friendly nudges on my Mastodon post, this fun little experiment evolved into the <click-spark> Web Component which is now available in a GitHub repo.

Try it out in the CodePen demo below.

Open CodePen demo

The spark color can be modified by setting a color value to the --click-spark-color custom property:

<click-spark style="--click-spark-color: hotpink"></click-spark>

Updated on July 26th, 2024 — The update below was a bit silly of me in retrospect. I'm going to leave it for the sake of keeping a rich history. I've pushed a new release that will instead contain the click sparks to the parent element. I believe this is a much cleaner implementation than what I initially attempted. Check out pull request #3 if you'd like to dig into the details.

Updated on January 5th, 2023 — I had been thinking about a case where I'd like to have click sparks, but only when clicking on particular elements. I've updated the code so that an active-on attribute can be set on the custom element to target a comma-separated list of selectors. If any of the selectors match, let the sparks fly. Here's a CodePen demo of the following example.

<click-spark active-on=".send-sparks, #i-love-sparks, [data-sparks]"></click-spark>

Have your sparks your way. ✨

Using External Links as GitHub Issue Template Options

2024-01-18T00:00:00Z

I've been down the road of configuring custom issue templates on GitHub repos before. It even seems like there have been some nice improvements to help make creating them even easier. Thanks for setting me up with a reasonable bug report template to start from so I don't have to build one from scratch. 🐛

However, teams may rely on a variety of other tools—Jira, Asana, Linear, an Excel spreadsheet (Kidding! But maybe?)—to manage a backlog of tasks. I'd prefer teammates not add new issues on the repo only to then recreate those items in some other workflow. It would be great if folks could be guided to the right place and avoid double entry.

There is a solution for this! It's new to me, so in the spirit of "today I learned", here's a quick tip for us to share.

Creating custom config

We can configure the template chooser with external links and even lock down the ability to open new issues on the repo. To do this, we create a config.yml file in the repo's .github/ISSUE_TEMPLATE directory.

The .github/ISSUE_TEMPLATE directory may not exist yet if templates have not been configured for the repo. If it needs to be manually created, the path should start at the root of the project.

blank_issues_enabled: false
contact_links:
  - name: 🐛 Bug Report
    url: [link to create bug report]
    about: Please file a bug report in our team's app of choice.
  - name: 💡 Feature Request
    url: [link to create feature request]
    about: Have some great ideas to improve our site or this codebase? Open a new feature request in our team's app of choice.

The screenshot below shows how these items will render on the "issue chooser" page. The config explicitly sets only the two options, both linking to their respective places where new tasks can be added to the team's backlog.

The blank_issues_enabled: false line in the config code hides the "open a blank issue" hyperlink that normally appears below these custom options. Without this line, folks would still have the ability to add a new issue on the repo.

With all of this in order, the repo remains free of user-entered issues, reducing some friction and redundancy. As an aside: I'm not 100% certain, but I'd wager that automated bot issues would still appear in the repo's issue queue.

CSS Scroll-triggered Animations with Style Queries

2024-01-27T00:00:00Z

Topping my CSS wishlist in 2024 are scroll-driven animations and style queries. At the time of writing this post, both lack full support but I've got fingers crossed they become available in all evergreen browsers not too long from now. I had done some exploration of scroll-driven animations but have not yet spent much time with style queries beyond reading and daydreaming about the amazing possibilities they'll unlock.

Discovery zone

I happened upon a CodePen by Jhey Tompkins that kicked off my curiosity. In that demo, as the page is scrolled, animations are triggered that smoothly highlight passages of text within the copy. It's all powered by CSS. That's incredible! I've achieved this effect in past demos using GSAP ScrollTrigger and the Intersection Observer API. How is this same concept accomplished with only CSS?

Diving into Jhey's code, we find a --highlighted custom property set to 0. Using scroll-driven animations, the value is updated to 1 as the mark element reaches the end of its animation-range. That value is passed into a calc() function that transitions a background-position property to create the highlighting effect.

This scroll-driven animation mimics intersection observer functionality. In fact, if we inspect the JS panel in the CodePen editor, we'll find that Jhey provides an intersection observer fallback for browsers that don't support CSS view progress timelines.

Scroll-driven animations and style queries join forces

That demo got me jazzed. What else might be possible with this bonafied CSS trick? Could we also trigger a @keyframes animation sequence? I've tested and scrapped a handful of ideas, deciding that it may not be feasible in scroll-driven animations. At least not without a little help from a new friend.

Style queries give us the ability to supply styling based on the value of a parent CSS custom property. Ahmad Shadeed's Style Queries deep dive demonstrates this in a variety of ways. I ran with Jhey's view progress timeline approach, "toggling" a custom property value in a @keyframes ruleset, then added a style query that triggered an animation on a child element.

How about that—it works! 🎉 Or rather, it works in browsers that support both style queries and scroll-driven animations. When unsupported, the demo falls back to displaying the text without the animations.

Open CodePen demo

The magic is in the following CSS code. It has been stripped back from the demo CSS to focus on the trigger animation specifics.

.box {
  animation: trigger steps(1) both;
  animation-timeline: view();
  animation-range: entry 80% contain 40%;
}

@container style(--animate: true) {
  .text { 
    /* animate! */
  }
}

@keyframes trigger {
  to {
    --animate: true;
  }
}

Note that only the animation-range end value is relevant for the trigger. Declaring animation-range-end: contain 40% instead would also work here. However, the demo includes the start value to explicitly set where the fade animation starts on the same element.

Once the .box element reaches the end of the animation-range, the trigger animation runs instantly, sets --animate: true on the element, then kicks off the elastic popup and background gradient transition on its child .text element. If the page is scrolled back up, the text recedes back to its starting position.

Additional thoughts

I find this fascinating. Modern CSS continues to deliver fresh delight. However, keep in mind that the CodePen demo works well here because the animated elements are hidden outside of the viewport on initial page load. We'd see the text animate on load if it were visible on screen, which may not be ideal. There are a few ways to handle supressing animation playback on load using JavaScript but I'd love to have this control through a CSS rule.

Another thought I had, which Bramus asks the reader in the intro of his article about scroll-driven animations:

[...] what if you want a scroll-driven animation to stay on its endframe once it was entirely played?

Play through one and done? Sounds like an excellent option. Unfortunately, this cannot be done in CSS but Bramus created a set of scroll-driven animation utilities which includes a way to run a scroll-driven animation only once.

Have any feedback or other ideas? Come and join the conversation on Mastodon.

Updated on January 29th, 2024: Bramus shared with me his own experiment with this concept from last year. The article does an excellent job explaining how it works and I recommend checking it out. Our conclusions on this seem to be the same.

This was a fun experiment to do. However, it’s only an experiment and to me makes the case that we still need proper Scroll-Triggered Animations in the future – maybe something to work on for scroll-animations-2? 😉

Now there's a sequel I would be excited to see. 👀

The Fifty-Fifty Split and Overflow

2024-02-19T00:00:00Z

The fifty-fifty split—or 50/50 for a dash of brevity—is a classic layout pattern where two elements occupy the same amount of inline space inside a row. These two elements will stack once it becomes too narrow to properly display them side by side. Both flexbox and CSS grid can accommodate this pattern.

I had recently shared a demo on CodePen built with this layout pattern, but the component in the demo contains an extra feature: The content of one section overflows and can be scrolled. Try it out by scrolling the section sandwiched between the "header" and "footer" elements.

Open CodePen demo

Let's find out how it all works. We'll jump into flexbox and grid versions of the 50/50 layout as well as how to handle overflow scrolling.

The flexbox 50/50

In the 50/50 flexbox layout demo, the flex-basis value represents how tight the section elements within the container can get before wrapping. flex-grow: 1 insists these sections grow beyond their flex-basis value to equally fill the inline space. Once the container becomes too narrow, the two sections will stack.

.fifty-fifty {
  display: flex;
  flex-wrap: wrap;
}

.fifty-fifty > * {
  flex-grow: 1;
  flex-basis: 250px;
}

In the CodePen demos, we'll find a --min-inline-size variable is utilized. I've removed it from these article code blocks to keep them simple. The reason for having it? It acts as a configuration property for the .fifty-fifty selector. When necessary, we can set a custom value to it and override how tight the sections get before they stack. Otherwise, it'll use the fallback value.

The grid 50/50

This same layout can be achieved with CSS grid as we'll discover in the 50/50 grid layout demo.

A columns template is declared to represent the two sections.
auto-fit expands the columns so that they evenly fill the parent container.
A minmax() function provides the minimum width for when the sections should stack once the parent container becomes too narrow.

.fifty-fifty {
  display: grid;
  grid-template-columns: repeat(
    auto-fit,
    minmax(250px, 1fr)
  );
}

Scrolling overflow content

Imagine a design requirement in which one of the sections within the 50/50 is scrollable. The intrinsic height of the non-scrolling side should instruct the overall height of the parent container. Problem is, we can't just declare a static height value because the content in the non-scrolling section could change. Maybe the text is translated by the user. Maybe the font size is increased for readability.

This seems tricky to pull off, but both the flexbox and grid patterns can accommodate such a feature. The code blocks below contain the essential HTML and CSS for the grid version. We can also get a look at how both versions work in this CodePen demo.

<article class="fifty-fifty">
  <section>
    <!-- this content controls overall height -->
  </section>
  <section class="scroll-container">
    <!-- overflowing section content -->
  </section>
</article>

.fifty-fifty {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
  grid-auto-rows: 1fr;
}

.scroll-container {
  contain: size;
  overflow-y: auto;
}

My original take on this has been massively improved after some feedback from Roma Komarov. I totally slept on the contain property! After setting the contain: size rule, I can drop my previous iteration which had an additional nested element with absolute positioning applied. This simplifies both the template and styles. Thank you, Roma! 👏

Now, when the sections are side by side, the height of the fifty-fifty container is based on the size of the non-scrolling section.

Visually collapsed when stacked

For either layout, it is important to apply a minimum height on the scrollable section. Otherwise, when the sections stack, the scrolling section would disappear visually. Although, if we use CSS grid, we get an extra twist of magic: the grid-auto-rows property. Instead of setting a static "magic number" minimum height, grid-auto-rows: 1fr can be declared. What makes this an attractive alternative is that, whether stacked or split, the two sections are always the same size. In other words, the scrollable section height will consistently mirror the height of the non-scrolling section.

Where it all started

The CodePen demo introduced at the beginning of the article has its rules organized another way. Since there are distinct border styles applied depending on whether the sections are stacked or split, we'll find that a media query ruleset handles the layout breakpoint instead. When the browser viewport is larger than the min-width in the query, each section is explicitly set to 1fr to distribute their inline sizes evenly. The code below focuses on those specifics.

.container {
  display: grid;
  grid-auto-rows: 1fr;
}

.details {
  border-block-start: var(--border);
}

@media (min-width: 40rem) {
  .container {
    grid-template-columns: 1fr 1fr;
  }

  .details {
    border-block-start: unset;
    border-inline-start: var(--border);
  }
}

If we desired more modular control than a media query can provide, we could consider using a container query to manage these styles. A solid enhancement to add when it becomes necessary.

Helpful resources

Someone Great

2024-03-13T00:00:00Z

Where to start? The grief is heavy and far too real. I barely slept last night. The brain fog is thick but finding the words and placing them here may provide some catharsis.

I lost someone great. Oscar was so much bigger than most folks will ever understand. His love, not just for my partner and I, but for all walks of life was unconditional. His level of patience and kindness is aspirational. I've never met someone like him. I reflect fondly on the memories of him, some of my best years being filled with his presence every single day.

Oscar was an avid US traveler, bouncing back and forth between the coasts. He spent much of his life right outside NYC being a friend of the people. I often dubbed him the mayor of downtown Jersey City. Countless times when Oscar and I went out for a stroll together passersby would gush with joy, interacting with Oscar as if nobody else existed. He walked proud, eyes beaming, perpetually present in the moment.

It was also in Jersey City where my partner and I became great friends. It was where we fell in love. Oscar was integral to our story. We'd trek all over the city with him, hanging around the local coffee shop, strolling along the waterfront, sprawling out in the grass of Liberty State Park. Our conversations were natural, meaningful, and incredibly deep. Oscar was there with us, always attentive, reacting with his calming stare and gentle grin. At the beginning of our relationship, his approval meant everything. Oscar made me feel accepted.

When the pandemic lockdowns started, Oscar insisted we get outdoors for socially-distanced walks, leading us around an exceptionally quiet city. Being with him helped maintain our sanity during such a difficult experience. We spent a majority of our time quarantined in a small studio apartment, but Oscar was there urging us to keep our cool, letting us know it was going to be alright. His warm aura would fill the room. We felt it. In that challenging time, we felt at peace. We felt joy.

When travel began to return, lockdown restrictions being lifted, we made a decision to spend our days on the opposite coast. Once we got there, Oscar needed no time to adjust. He immediately embraced his golden years, escaping the harsh Northeast winters and heavy springtime rain for the endless sunny beaches of southern California. It brought my partner and I so much delight seeing his excitement. The new sites, sounds, the smells—everything was so fresh and welcome. We'd head down to the beach where Oscar would stretch across the sand and soak up the sun. He would smile back at us. Everything felt right.

At home, Oscar would watch intently as we cooked meals. When the doorbell rang, he'd jump up to greet guests with glee. I'd play the acoustic guitar and Oscar would settle nearby to listen, often drifting off to sleep. He never said it, but I'm pretty confident he enjoyed hearing me play. I tell myself that anyway.

Late at night, the three of us would snuggle up on the couch and watch television. Oscar was typically first to leave for bed. If it were getting too late, he'd sometimes peek his head back into the room. His stare seemed to say, "It's bedtime, you two, come along!" Then he'd stalk off as quickly as he appeared. In retrospect, he was probably right as we woke up groggy the next morning.

I'd like to continue but I've reached a breaking point emotionally. My eyes are starting to swell. There is so much wonder around Oscar, so many stories to share. He elevated the mood of anyone that met him. On a personal level, he made me feel important and loved in times I felt small or invisible. There was not and never will be anyone that matches his unique disposition. He was our emotional companion and a beautiful friend.

I love you, Oscar. You are forever missed.

Detect JavaScript Support in CSS

2024-04-20T00:00:00Z

I had been aware of the scripting CSS media feature but I was still under the impression that cross-browser support was lacking. What a pleasant surprise to discover that it has been available in all modern browsers as of December 2023 according to caniuse.com. With this feature, we can provide alternative CSS rules depending on whether or not JavaScript is available in the user's browser. It can also help reduce flashes of unstyled content or undesirable layout shifts.

Before we dive in: As exciting as this feature is, I've learned that there are a couple unfortunate gotchas. I've amended the article with an issues section below.

Usage

We can progressively enhance our styles:

@media (scripting: enabled) {
  .my-element {
    /* enhanced styles if JS is available */
  }
}

Or we can gracefully fall back to some alternate styles:

@media (scripting: none) {
  .my-element {
    /* fallback styles when JS is not supported */
  }
}

There's also an initial-only value, which is for scripting that is enabled during page load but not after. The Media Queries Level 5 W3C Working Draft includes a couple cases where it can be useful.

Examples are printed pages, or pre-rendering network proxies that render a page on a server and send a nearly-static version of the page to the user.

I don't personally imagine using initial-only much, if ever. Although, I'd be interested to find more specific examples of it in practice.

The time before the query

Before this feature, one approach for detecting JavaScript support was by setting a custom selector on the opening html tag—a common one seen in the wild is the no-js class name. If JavaScript is supported and enabled, it removes that selector just prior to rendering page content. When JavaScript is disabled, we can supply alternative styles that adapt to the experience.

<html class="no-js">
  <!-- page content -->
</html>

.no-js .my-element {
  /* styles when JS is disabled */
}

Is this real life?

Imagine a new web campaign is on the cusp of going live and it's time to connect with all the key stakeholders. Everything looks great, most of the team satisfied with the result, but then suddenly some hip marketer in the meeting emphatically requests a complex intro animation on the hero component when the page loads. They gesture wildly as they ask for the main headline to fade in, shrink away as if it were being pulled back on a sling shot, and then... at this point they make an explosion noise with their mouth. "Make it pop!" they decree a mere 24 hours before launch.

Woof. Better get started.

To handle the complexity of this work, we might reach for an animation library such as GSAP. But what does the user see when JavaScript is not available, not to mention if a user's prefers reduced motion setting is enabled? We'll need to consider an alternate version of the hero without all that swooping and scaling.

This media query unlocks the ability to provide CSS rules that are a better fit to the user's experience. In the CodePen demo below, if we disable JavaScript, we'll find that the animation is skipped and the static headline is displayed.

Open CodePen demo

Watch that flash

To really make the intro animation feel smooth on page load, the demo relies on the scripting media query to hide the headline with CSS. By doing so, we won't catch a flash of unstyled text before the GSAP animation is loaded. Also, we only want to hide the headline if JavaScript is available, otherwise it would be hidden for users when it's disabled.

In the following video, watch what happens when the headline is not hidden on page load. The text flashing is even more glaring when throttling on a slower network.

Your browser cannot play the provided video file.

In the video, the headline is no longer hidden on page load to share that pesky flash of unstyled text. When emulating slower network speeds, the issue becomes even more egregious.

Combining queries

In the CSS tab of the demo, notice that the media queries are combined to check both scripting and reduced-motion conditions.

@media (scripting: enabled) and (prefers-reduced-motion: no-preference) {
  /* JS available and motion OK */
}

@media (scripting: none), (prefers-reduced-motion) {
  /* JS disabled or reduced motion enabled */
}

Each condition can surely have exclusive styles if the desired outcome calls for it, but it's nice that we can combine them where there's overlap in rulesets.

Issues

Updated on April 21st, 2024 - After publishing this post, some feedback surfaced explaining where this media feature unexpectedly fails.

It does not behave as anticipated when a browser extension such as NoScript or uBlock Origin is used to disable page scripts. scripting: enabled still matches even though the extension has JavaScript turned off.
If a script gets blocked or fails to load, a fallback would need to be handled via JavaScript. In the demo above, the fallback would need to tap into the demo's scripting: none media query ruleset so that the static version of the hero is displayed.

Tremendous thanks to Sara, Šime, and Vadim for sharing!

Helpful resources

Penguin!

2024-05-06T00:00:00Z

My partner and I finally finished our epic three-part claymation saga. It's our first attempt at creating stop-motion videos with clay and it truly is a lot of work for such a short result. That claymation episode of Parks and Recreation is a little too real. I won't compare our movie to Avatar though.

Regardless, we had a blast doing it. Making art with our hands brings a different style of satisfaction. Anyway, I'll keep this post short and get to it. Enjoy!

https://www.youtube.com/watch?v=3mUdINzprdI

Notes on handling events in Web Components

2024-07-27T00:00:00Z

My click-spark web component was a fun, silly project at best. Yet I've seen it's had some love since being shared. So why not publish it as an npm package? No better time than the present, some say.

I had done a major refactor before publishing, the most notable was that the spark would now be contained to the custom element's parent node. After announcing the updates in a Mastodon post, I soon received a PR with some quality feedback including a more advantageous way to handle the parent click event using the handleEvent() method.

The click-spark click

Let's dive into a "before and after" for handling the click event on this component.

In both examples, notice that the parent node is being stored in a variable when connectedCallback runs. This ensures that the click event is properly removed from the parent since it's not available by the time disconnectedCallback is invoked as FND's comment explains.

In the "before" approach, the event handler is stored in a variable so that it's cleared from the parent node whenever the click-spark element is removed from the DOM.

constructor() {
  this.clickEvent = this.handleClick.bind(this);
}

connectedCallback() {
  this._parent = this.parentNode;
  this._parent.addEventListener("click", this.clickEvent);
}

disconnectedCallback() {
  this._parent.removeEventListener("click", this.clickEvent);
  delete this._parent;
}

handleClick() {
  // Run code on click
}

Switching to handleEvent() removes the need to store the event handler. Passing this into the event listener will run the component's handleEvent() method every time we click.

constructor() {
  // No longer need to store the callback
}

connectedCallback() {
  this._parent = this.parentNode;
  this._parent.addEventListener("click", this);
}

disconnectedCallback() {
  this._parent.removeEventListener("click", this);
  delete this._parent;
}

handleEvent(e) {
  // Run code on click
}

Helpful resources

Chris Ferdinandi's article, The handleEvent() method is the absolute best way to handle events in Web Components is an excellent read on why handleEvent() is a top choice for architecting event listeners in Web Components. He also shares insight from Andrea Giammarchi's DOM handleEvent: a cross-platform standard since year 2000 article which contains solid techniques for handling multiple event types.

Rather than me regurgitating, I recommend jumping into both of those articles to get a proper grasp on handleEvent().

Updated on July 29th, 2024 — FND published Garbage Collection for Event Listeners about event listener cleanup after an element is removed from the DOM. The included demo is a nice touch. One interesting footnote that stood out to me: moving the element to a new location in the DOM will invoke disconnectedCallback before invoking connectedCallback again.

Center Items in First Row with CSS Grid

2024-08-19T00:00:00Z

Imagine the following section on a website:

A collection of elements, like a series of cards with marketing information, are presented in a grid display.
The elements are arranged in rows of three.
When there are an odd number of elements left over, they will be center-aligned horizontally.

There are a few ways to accomplish styling such a layout. Controlling Leftover Grid Items with Pseudo-selectors by Michelle Barker shares a clever CSS Grid solution. But here's a twist: What if the centered odd number of elements should appear in the first row instead of the last?

I've included a CodePen demo at the end of this article if you'd like to jump ahead. Otherwise, continue on a journey of style discovery.

Grid Stacks

Is it a trapezoid grid? Brick grid? Grid pyramid? Pyragrid? For the sake of this article, I ultimately picked a more generic name, calling it Grid Stack. Here's how we'll build a Grid Stack that contains five cards displayed in a three-column grid.

.grid-stack {
  display: grid;
  grid-template-columns: repeat(6, 1fr);

  > * {
    grid-column-end: span 2;
  }

  > :first-child {
    grid-column-start: 2;
  }
}

CSS nesting is being used here, which is newly supported across major browsers. Not feeling ready for that yet? We can move the nested rules into their own top-level rulesets. They just need to start with the parent selector name, i.e. .grid-stack > * { }

The parent grid-stack container produces a template with six columns. Notice that the grid-template-columns repeat count is double the amount of columns we want visually present in each row. Each child element will then span across two columns instead of one. Finally, the first child element is aligned to the start of the second column. The result is a visually centered top row.

Grid lines (enabled in dev tools) help show where each child element is positioned on the grid.

Variations

So far, the styles we've created only apply when there are five cards positioned across three columns. We may want different variations depending on our designs. Three cards displayed in two columns? Seven cards in four? Let's tweak the above ruleset to utilize a CSS variable for the grid-template-columns repeat count. Recall that this value should be twice the amount of expected columns.

.grid-stack {
  display: grid;
  grid-template-columns: repeat(calc(var(--columns) * 2), 1fr);

  > * {
    grid-column-end: span 2;
  }

  > :first-child {
    grid-column-start: 2;
  }
}

The --columns value gets doubled as it passes through the CSS calc() function. Now we're able to define the preferred amount of columns directly on the parent container.

<div class="grid-stack" style="--columns: 2"></div>
<div class="grid-stack" style="--columns: 3"></div>
<div class="grid-stack" style="--columns: 4"></div>

Demo

Open CodePen demo

Bonus! Pyramid stacks

In the above demo, you may have discovered some configurations for the Grid Stack that result in a pyramid-style stack. Maybe now we can call it a pyragrid? Still not sure about that one... Anyway, to achieve this layout involves a few extra ingredients. We'll need to adjust the grid-column-start position of the first element in each row. Let's jump right to the last example with the grid-stack-15 selector:

.grid-stack-15 {
  --columns: 5;

  > :first-child {
    grid-column-start: 5;
  }

  > :nth-child(2) {
    grid-column-start: 4;
  }

  > :nth-child(4) {
    grid-column-start: 3;
  }

  > :nth-child(7) {
    grid-column-start: 2;
  }
}

This calls for a five-column grid visually, so it sets --columns: 5. Recall that this value gets doubled and outputs a template of ten columns.
We'll nudge the first item in each row with grid-column-start. The top row element's start position is equal to the --column value. Subsequent rules will decrease this value by 1.

It's surely possible to develop a Sass or PostCSS function that could dynamically generate this CSS output but that seemed a bit overkill for the demo. As an added bonus, check out Temani Afif's Stack Overflow answer that styles elements in a pyramid using float and shape-outside. Very cool!

Limitations

Each layout variation expects a specific odd-number of child elements to be rendered. I have explored ways of automatically adjusting the layout based on the element count but there were too many edge cases to consider. It created more problems than it solved. Additionally, while these layouts work nicely on a wider viewport, it may not fare as well where less space is available. A media or container query ruleset can ensure our content adapts appropriately, but it certainly couldn't be a one-size-fits-all conditional set of styles.

From the community

Updated on September 5th — Kevin Powell reached out on Mastodon and shared a CodePen Example that uses :has(:nth-child():last-child) to result in this layout. I certainly dig the approach! Keep in mind that the same aforementioned limitations still apply.

CSS @property and the New Style

2024-09-02T00:00:00Z

The @property at-rule recently gained support across all modern browsers, unlocking the ability to explicitly define a syntax, initial value, and inheritance for CSS custom properties. It seems like forever ago that CSS Houdini and its CSS Properties and Values API were initially introduced. I experimented sparingly over time, reading articles that danced around the concepts, but I had barely scratched the surface of what @property could offer. The ensuing demo explores what's possible in the next generation of CSS.

Calls to action

Ever seen those sleek, attention-seeking, shiny call-to-action webpage elements? Waves of sites across the web, especially the ones marketing services and software urging for you to "Upgrade your account" or "Sign up today," have discovered the look and latched on. I'm not here to knock it and admittedly think it's kind of fresh. I thought I'd give that style a try myself. Check out the result in the CodePen below.

Open CodePen demo

There's a ton to unpack in this demo. Let's start with that shine looping around the button. Toggle open the demo's CSS panel to find a collection of @property rules related to those custom properties that need to animate. Here's the one defined for the --gradient-angle:

@property --gradient-angle {
  syntax: "<angle>";
  initial-value: 0deg;
  inherits: false;
}

The @property rule communicates to the browser that <angle> is the allowed syntax for this custom property and its initial value is 0deg. This enables the browser to smoothly transition from 0deg to 360deg and output a rotating gradient.

@keyframes rotate-gradient {
  to { --gradient-angle: 360deg; }
}

.rotate-gradient {
  background: conic-gradient(from var(--gradient-angle), transparent, black);
  animation: rotate-gradient 10s linear infinite;
}

I put together a simple gradient spin demo to focus on the handful of lines necessary to render this concept.

Open CodePen demo

We can achieve the shiny animated border effect by evolving this code a bit. We'll introduce a linear-gradient as the first value of the element's background property and set a background-origin to each value.

The origin of the linear-gradient is set to padding-box. This prevents the gradient from spilling into the border area.
The conic-gradient origin is set to border-box. This gradient overflows into the space created by the border width.
To reveal the rotating conic-gradient, a single-pixel transparent border is added.

.border-gradient {
  background: 
    linear-gradient(black, black) padding-box,
    conic-gradient(from var(--gradient-angle), transparent 25%, white, transparent 50%) border-box;
  border: 1px solid transparent;
}

In the CSS panel of the simple gradient spin demo, uncomment the .border-gradient ruleset to reveal the shiny animated border. Looking pretty slick! For more examples, I've included a bunch of animated gradient border articles in the resources section at the end of the post.

Silky smooth hover transitions

A few special ingredients help facilitate a buttery smooth gradient transition when the element is hovered. Let's dig into its background values:

.shiny-cta {
  background: 
    linear-gradient(var(--shiny-cta-bg), var(--shiny-cta-bg)) padding-box,
    conic-gradient(
        from calc(var(--gradient-angle) - var(--gradient-angle-offset)),
        transparent,
        var(--shiny-cta-highlight) var(--gradient-percent),
        var(--gradient-shine) calc(var(--gradient-percent) * 2),
        var(--shiny-cta-highlight) calc(var(--gradient-percent) * 3),
        transparent calc(var(--gradient-percent) * 4)
      )
      border-box;
}

Each custom property that needs to animate has a syntax declared in its @property definition so that the browser can interpolate between corresponding value changes and transition them seamlessly. The size of the shiny area is determined by the --gradient-percent value. On hover, a higher percentage lengthens the shine. The --gradient-angle-offset value is used to readjust the gradient angle so that the shine doesn't rubber band back and forth on hover.

Your browser cannot play the provided video file.

Demonstrating the transition behavior without the angle offset value

I had to fine-tune the percent and offset values until the shine length and transition felt optically aligned. Finally, the --gradient-shine brightness gets toned down to blend more seamlessly with the adjacent highlight colors.

Slow it on down

This CSS tip to slow down a rotation on hover truly blew my mind. In the tip's example code, the same rotate animation is declared twice. The second one is reversed and paused, its duration divided in half. When the element is hovered, animation-play-state: running overrides the paused value and slows the rotation to half speed. The mind-blowing part, at least to me, is that the animation speeds back up at the current position when the element is no longer hovered. No snapping back to a start position, no extra wrapper elements necessary. That is one heck of a tip.

The call-to-action animations rely on this method to slow them down when the button is hovered. This technique keeps all the rotations and movements in sync as they change speed.

Tiny shiny dots

Looking even closer, we'll discover pinhole-sized dots shimmering inside the button as the shiny border passes near them. To render this dot pattern, a radial-gradient background is created.

.shiny-cta::before {
  --position: 2px;
  --space: calc(var(--position) * 2);
  background: radial-gradient(
      circle at var(--position) var(--position),
      white calc(var(--position) / 4),
      transparent 0
    )
    padding-box;
  background-size: var(--space) var(--space);
  background-repeat: space;
}

Remember that --gradient-angle custom property? It has returned! But this time, it's being used in a conic-gradient mask that reveals parts of the dot pattern as it rotates. The gradient angle is offset by 45 degrees to align it perfectly with the shiny border rotation.

.shiny-cta::before {
  mask-image: conic-gradient(
    from calc(var(--gradient-angle) + 45deg),
    black,
    transparent 10% 90%,
    black
  );
}

For one last touch of magic, a gradient containing the highlight color is added to the ::after pseudo element, spinning in unison with the shine area. These highlights flowing through the button add a pleasant, welcoming ambience that was previously missing.

Enhancing the hover colors

The hover styles looked decent. But they didn't seem totally finished. I felt the desire to enhance. Create more depth. Make it pop, as they say.

The button's ::before and ::after pseudo elements were already in use so I wrapped the button text in a span element. A blurred box-shadow containing the highlight color is applied to one of its pseudo elements which is then expanded to fill the button dimensions. On hover, the pseudo element slowly scales up and down, evoking a vibe similar to relaxed breathing. Paired with the spinning highlight color inside the button, the effect finally resonated with me. This intricately designed call-to-action button felt complete.

In with the new style

Many of the above techniques would have been nearly impossible only a short time ago. Explicitly defining custom properties unlocks a great big world of opportunity. I'm especially eager to see how @property will be utilized in large-scale applications and design systems. Providing Type Definitions for CSS with @property by Stephanie Eckles as well as Adam Argyle's Type safe CSS design systems with @property are just a couple glimpses into a really promising future for publishing our CSS.

Helpful resources

Web Components for Password Input Enhancements

2024-09-20T00:00:00Z

So there I was, experimenting with HTML password inputs and Web Components. I'm not sure why the idea even came up but it quickly snowballed into a curious expedition. The result from the journey was a set of custom elements that provide extra functionality and information about the text being typed into a password input field. I shared my CodePen demo in a Mastodon post and soon after decided to push these scripts up to a GitHub repo.

Open CodePen demo

Get started

The repo includes two Web Component scripts. They operate independent of one another. I recommend reading through the repo documentation but here's a rundown of what's included.

<password-rules> adds an input event listener to capture when a list of rules (password length, includes an uppercase letter, etc.) are matched as the user is typing in their new password.
<password-toggle> shows and hides the password input value on click.

To get started, add the scripts to a project and include them on the page.

<script type="module" src="path/to/password-rules.js"></script>
<script type="module" src="path/to/password-toggle.js"></script>

Below is an example of using both custom elements with a password input.

<label for="new-password">Password</label>
<input type="password" id="new-password" />
<div id="status" aria-live="polite"></div>

<password-toggle data-input-id="new-password" data-status-id="status">
  <button type="button">Toggle password visibility</button>
</password-toggle>

<password-rules data-input-id="new-password" data-rules=".{9}, [A-Z], .*\d">
  <ul>
    <li data-rule-index="0">Longer than 8 characters</li>
    <li data-rule-index="1">Includes an uppercase letter</li>
    <li data-rule-index="2">Includes a number</li>
  </ul>
</password-rules>

Password toggle

password-toggle expects a button element to be inside it. This button will be augmented with the ability to toggle the visibility of the input field's value.

When the toggle button is clicked, the "status" element containing the aria-live attribute will send a notification to screen readers that the password value is currently visible or hidden. For instance, when clicking for the first time, the string "Password is visible" is inserted into the container and announced by a screen reader.

We can also style the toggle button when it enters its pressed or "visible password" state. In the CodePen demo, this is how the eye icon (aye aye!) is being swapped.

button svg:last-of-type {
  display: none;
}

button[aria-pressed="true"] {
  svg:first-of-type {
    display: none;
  }
  svg:last-of-type {
    display: block;
  }
}

Targeting the [aria-pressed] attribute selector ensures that our styles stay in sync with their accessibility counterpart. It also means that we don't need to manage a semantic attribute value as well as some generic class selector like "is-active". Ben Myers shares great knowledge on this subject in Style with stateful, semantic selectors. A must-have in the bookmarks 🏆

Password rules

The password-rules element is passed a comma-separated list of regular expression strings, each related to a specific rule. We also have the option to connect any child element to a rule by passing the index of that string to a data-rule-index attribute. The placement or type of element doesn't matter as long as it's contained within the password-rules.

Here's an alternate version to drive that point home:

<password-rules data-input-id="new-password" data-rules=".{8}, [A-Z], .*\d">
  <div class="one-column" data-rule-index="0">
    Longer than 8 characters
  </div>
  <div class="two-columns">
    <span data-rule-index="2">Includes a number</span>
    <span data-rule-index="1">Includes an uppercase letter</span>
  </div>
</password-rules>

Check it off

When a rule is met that matches the data-rule-index value on an element, an is-match class gets added to the element. The demo styles use this selector to add a checkmark emoji when present.

.password-rules__checklist .is-match::before {
  content: "✅";
}

score/total

The current password "score" and rules "total" are passed to the custom element as data attributes and CSS variables. The score value updates as rules are met. This allows us to do some fancy things like change the colors in a score meter and present the current tally. All of it done with CSS.

/** Incrementally adjust background colors */
password-rules[data-score="1"] .password-rules__meter :first-child,
password-rules[data-score="2"] .password-rules__meter :nth-child(-n + 2),
password-rules[data-score="3"] .password-rules__meter :nth-child(-n + 3),
password-rules[data-score="4"] .password-rules__meter :nth-child(-n + 4) {
  background-color: dodgerblue;
}

/** When all rules are met, swap to a new color for each meter element */
password-rules[data-score="5"] .password-rules__meter :nth-child(-n + 5) {
  background-color: mediumseagreen;
}

CSS variables are passed into a CSS counter() to render the current score and total.

.password-rules__score::before {
  counter-reset: score var(--score, 0) total var(--total, 5);
  content: counter(score) "/" counter(total);
}

I added fallback values to the CSS variables when I realized that the --total value, specifically, renders as 0 on page load and doesn't update until we begin typing in the input field. I did discover that we could skip the fallback by registering the custom property. This ensures the total is correctly reflected when the component initializes. But, to be honest, this feels unnecessary when the fallback here will suffice.

@property --total {
  syntax: "<number>";
  initial-value: 0;
  inherits: true;
}

If this @property stuff is unfamiliar, Stephanie Eckles has got you covered in Providing Type Definitions for CSS with @property. Another one to bookmark! I've also recently spent time with this newly supported at-rule in CSS @property and the New Style.

Progressively enhanced for the win

I believe this tells a fairly nice progressive enhancement story. Without JavaScript, the password input still works as expected. But when these scripts run, users get additional feedback and interactivity. Developers get access to extra selectors that can be useful for styling state changes. And listen, I get it–there are better ways to handle client-side form validation, but this was a fun exploration nonetheless.

The Pixel Canvas Shimmer Effect

2024-12-03T00:00:00Z

I recently stumbled on a super cool, well-executed hover effect from the clerk.com website where a bloom of tiny pixels light up, their glow staggering from the center to the edges of its container. With some available free time over this Thanksgiving break, I hacked together my own version of a pixel canvas background shimmer. It quickly evolved into a pixel-canvas Web Component that can be enjoyed in the demo below. The component script and demo code have also been pushed up to a GitHub repo.

Open CodePen demo

Usage

Include the component script and then insert a pixel-canvas custom element inside the container it should fill.

<script type="module" src="pixel-canvas.js"></script>

<div class="container">
  <pixel-canvas></pixel-canvas>
  <!-- other elements -->
</div>

The pixel-canvas stretches to the edges of the parent container. When the parent is hovered, glimmering pixel fun ensues.

Options

The custom element has a few optional attributes available to customize the effect. Check out the CodePen demo's html panel to see how each variation is made.

data-colors takes a comma separated list of color values.
data-gap sets the amount of space between each pixel.
data-speed controls the general duration of the shimmer. This value is slightly randomized on each pixel that, in my opinion, adds a little more character.
data-no-focus is a boolean attribute that tells the Web Component to not run its animation whenever sibling elements are focused. The animation runs on sibling focus by default.

There's likely more testing and tweaking necessary before I'd consider using this anywhere, but my goal was to run with this inspiration simply for the joy of coding. What a mesmerizing concept. I tip my hat to the creative engineers over at Clerk.

The Shape of Runs to Come

2024-12-08T00:00:00Z

Over the last few months or so, I have been fairly consistent with getting outside for Sunday morning runs. A series of lower body issues had prevented me from doing so for many years, but it was an exercise I had enjoyed back then. It took time to rebuild that habit and muscle but I finally bested the behavior of doing so begrudgingly.

Back in the day (what a weird phrase to say, how old am I?) I would purchase digital copies of full albums. I'd use my run time to digest the songs in the order the artist intended. Admittedly, I've become a lazy listener now, relying on streaming services to surface playlists that I mindlessly select to get going. I want to be better than that, but that's a story for another time.

These days, my mood for music on runs can vary: Some sessions I'll pop in headphones and throw on some tunes, other times I head out free of devices (besides a watch to track all those sweet, sweaty workout stats) and simply take in the city noise.

Before I headed out for my journey this morning, a friend shared a track from an album of song covers in tribute to The Refused's The Shape Of Punk To Come. The original is a treasured classic, a staple LP from my younger years, and I can still remember the feeling of the first time it struck my ears. Its magic is reconjured every time I hear it. When that reverb-soaked feedback starts on Worms of the Senses / Faculties of the Skull, my heart rate begins to ascend. The anticipation builds, my entire body well aware of the explosion of sound imminent. As my run began, I wasn't sure if I had goosebumps from the morning chill or the wall of noise about to ensue. My legs were already pumping. I was fully present, listening intently, ready for the blast. The sound abruptly detonated sending me rocketing down the street towards the rising sun.

My current running goal is 4-in-40, traversing four miles under forty minutes. I'm certainly no Prefontaine, but it's a fair enough objective for my age and ability. I'll typically finish my journey in that duration or slightly spill over the forty-minute mark. Today was different. Listening to The Shape Of Punk To Come sent me cruising an extra quarter mile beyond the four before my workout ended. The unstoppable energy from that album is truly pure runner's fuel.

There's certainly some layer of nostalgia, my younger spirit awakened and reignited by thrashing guitars and frantic rhythms, but many elements and themes on this record were so innovative at the time it was released. New Noise is a prime example that executes the following feeling flawlessly: Build anticipation, increase the energy level, and then right as the song seems prepped to blast off, switch to something unexpected. In this case, the guitars drop out to make way for some syncopated celestial synths layered over a soft drum rhythm. The energy sits in a holding pattern, unsure whether it should burst or cool down, when suddenly—

Can I scream?!

Oh my goodness, yes. Yes you can. I quickly morphed into a runner decades younger. I had erupted, my entire being barreling full speed ahead. The midpoint of this track pulls out the same sequence of build up, drop off, and teasing just long enough before unleashing another loud burst of noise, driving to its explosive outro. As the song wraps up, "The New Beat!" is howled repeatedly to a cheering crowd that, I would imagine, had not been standing still.

I definitely needed a long stretch after this run.

Scrolling Rails and Button Controls

2024-12-23T00:00:00Z

Once again, here I am, hackin' away on horizontal scroll ideas. This iteration starts with a custom HTML tag. All the necessities for scroll overflow, scroll snapping, and row layout are handled with CSS. Then, as a little progressive enhancement treat, button elements are connected that scroll the previous or next set of items into view when clicked.

Behold! The holy grail of scrolling rails... the scrolly-rail!

Open CodePen demo

I'm being quite facetious about the "holy grail" part, if that's not clear. 😅 This is an initial try on an idea I'll likely experiment more with. I've shared some thoughts on potential future improvements at the end of the post. On top of that, after I began experimenting, I discovered the possibility of CSS Carousels. If those scroll enhancing features become a cross browser standard, then we'll be able to generate scroll buttons and more, all with CSS. That's a lot of power.

With all of that out of the way, let's explore!

The HTML

Wrap any collection of items with the custom tag:

<scrolly-rail>
  <ul>
    <li>1</li>
    <li>2</li>
    <li>3</li>
    <!-- and so on-->
  </ul>
</scrolly-rail>

While it is possible to have items without a wrapper element, if the custom element script runs and button controls are connected, sentinel elements are inserted at the start and end bounds of the scroll container. Wrapping the items makes controlling spacing between them much easier, avoiding any undesired gaps appearing due to these sentinels. We'll discover what the sentinels are for later in the post.

The CSS

Here are the main styles for the component:

scrolly-rail {
  display: flex;
  overflow-x: auto;
  overscroll-behavior-x: contain;
  scroll-snap-type: x mandatory;

  @media (prefers-reduced-motion: no-preference) {
    scroll-behavior: smooth;
  }
}

When JavaScript is enabled, sentinel elements are inserted before and after the unordered list (ul) element in the HTML example above. Flexbox ensures that the sentinels are positioned on either side of the element. We'll find out why later in this post.
Containing the overscroll behavior will prevent us accidentally triggering browser navigation when scrolling beyond either edge of the scrolly-rail container.
scroll-snap-type enforces mandatory scroll snapping.
Smooth scrolling behavior applies when items scroll into view on button click, or if interactive elements (links, buttons, etc.) inside items overflowing the visible scroll area are focused.

Any wrapper element, such as the example ul, will need a flex display to position items in a single row and introduce gap spacing if desired. Then scroll-snap-align: start is applied to each item. This aligns the targeted snap item to the inline start of the component's scroll snap area. In the HTML example, this would apply to the li elements.

scrolly-rail ul {
  display: flex;
  gap: 1rem;
}

scrolly-rail li {
  scroll-snap-align: start;
}

As mentioned earlier, this is everything our component needs for layout, inline scrolling, and scroll snapping. Note that the CodePen demo takes it a step further with some additional padding and margin styles (check out the demo CSS panel). If we'd like to wire up previous/next controls, we'll need to include the custom element script in our HTML.

The custom element script

Add the script file on the page.

<script type="module" src="scrolly-rail.js"></script>

To connect the previous/next button elements, give each an id value and add these values to the data-control-* attributes on the custom tag.

<scrolly-rail
  data-control-previous="btn-previous"
  data-control-next="btn-next"
>
  <!-- ... -->
</scrolly-rail>

<button id="btn-previous" class="btn-scrolly-rail">Previous</button>
<button id="btn-next" class="btn-scrolly-rail">Next</button>

Now clicking these buttons will pull the previous or next set of items into view. The amount of items to scroll by is based on how many are fully visible in the scroll container. For example, if we see three visible items, clicking the "next" button will scroll the subsequent three items into view.

Observing inline scroll bounds

Let's review the demo's top component. As we begin to scroll to the right, the "previous" button appears. Scrolling to the component's end causes the "next" button to disappear. Similarly we can see the bottom component's buttons fade when their respective scroll bound is reached.

Recall the sentinels discussed earlier in this post? With a little help from the Intersection Observer API, the component watches for either sentinel intersecting the visible scroll area, indicating that we've reached a boundary. When this happens, a data-bound attribute is toggled on the corresponding button element. This presents an opportunity to alter styles and provide additional visual feedback.

.btn-scrolly-rail {
  /** default styles */
}

.btn-scrolly-rail[data-bound] {
  /* styles to apply to button at boundary */
}

Future improvements

I'd love to hear from the community most specifically on improving the accessibility story here. Here are some general notes:

I debated if button clicks should pass feedback to screen readers such as "Scrolled next three items into view" or "Reached scroll boundary" but felt unsure if that created unforeseen confusion.
For items that contain interactive elements: If a new set of items scroll into view and a user tabs into the item list, should the initial focusable element start at the snap target? This could pair well with navigating the list using keyboard arrow keys.
Is it worth authoring intersecting sentinel "enter/leave" events that we can listen for? Something like: Scroll bound reached? Do a thing. Leaving scroll bound? Revert the thing we just did or do another thing. Side note: prevent these events from firing when the component script initializes.
How might this code get refactored once scroll snap events are widely available? I imagine we could check for when the first or last element becomes the snap target to handle toggling data-bound attributes. Then we can remove Intersection Observer functionality.

And if any folks have other scroll component solutions to share, please reach out or open an issue on the repo.

Some Things About Keyframes

2024-12-30T00:00:00Z

Whether you've barely scratched the surface of keyframe animations in CSS or fancy yourself a seasoned pro, I suggest reading An Interactive Guide to Keyframe Animations. Josh (as always) does an impeccable deep dive that includes interactive demos for multi-step animations, loops, setting dynamic values, and more.

This is a quick post pointing out some other minor particulars:

Duplicate keyframe properties
The order of keyframe rules
Custom timing function (easing) values at specific keyframes

Duplicate keyframe properties

Imagine an "appearance" animation where an element slides down, scales up, and changes color. The starting 0% keyframe sets the element's y-axis offset position and scales down the size. When the animation is triggered, the element glides up from the offset to its central position for the full duration of the animation. About halfway through, the element's size begins scaling back up and the background color changes. At first, we might be tempted to duplicate the background-color and scale properties in both 0% and 50% keyframe blocks.

@keyframes animate {
  0% {
    background-color: red;
    scale: 0.5;
    translate: 0 100%;
  }
  50% {
    background-color: red;
    scale: 0.5;
  }
  100% {
    background-color: green;
    scale: 1;
    translate: 0 0;
  }
}

Although this functions correctly, it requires us to manage the same property declarations in two locations. Instead of repeating, we can share them in a comma-separated ruleset.

@keyframes animate {
  0% {
    translate: 0 100%;
  }
  0%, 50% {
    background-color: red;
    scale: 0.5;
  }
  100% {
    background-color: green;
    scale: 1;
    translate: 0 0;
  }
}

Keyframe rules order

Another semi-interesting quirk is that we can rearrange the keyframe order.

@keyframes animate {
  0% {
    translate: 0 100%;
  }
  100% {
    background-color: green;
    scale: 1;
    translate: 0 0;
  }
  /* Set and hold values until halfway through animation */
  0%, 50% {
    background-color: red;
    scale: 0.5;
  }
}

Just for kicks, here is a version that swaps 0% and 100% for their corresponding from and to keyword values.

@keyframes animate {
  from {
    translate: 0 100%;
  }
  to {
    background-color: green;
    scale: 1;
    translate: 0 0;
  }
  /* Set and hold values until halfway through animation */
  from, 50% {
    background-color: red;
    scale: 0.5;
  }
}

The "Resolving Duplicates" section from the MDN docs mentions that @keyframes rules do not cascade, which explains why this order still returns the expected animation. Customizing the order could be useful for grouping property changes within a @keyframes block as an animation becomes more complex.

That same section of the MDN docs also points out that cascading does occur when multiple keyframes define the same percentage values. So, in the following @keyframes block, the second translate declaration overrides the first.

@keyframes animate {
  to {
    translate: 0 100%;
    rotate: 1turn;
  }
  to {
    translate: 0 -100%;
  }
}

Keyframe-specific easing

Under "Timing functions for keyframes" from the CSS Animations Level 1 spec, we discover that easing can be adjusted within a keyframe ruleset.

A keyframe style rule may also declare the timing function that is to be used as the animation moves to the next keyframe.

Toggle open the CSS panel in the ensuing CodePen demo and look for the @keyframes block. Inside one of the percentages, a custom easing is applied using the linear() CSS function to give each element some wobble as it lands.

Open CodePen demo

I think that looks quite nice! Adding keyframe-specific easing brings an extra layer of polish and vitality to our animations. One minor snag, though: We can't set a CSS variable as an animation-timing-function value. This unfortunately means we're unable to access shared custom easing values, say from a library or design system.

:root {
  --easeOutCubic: cubic-bezier(0.33, 1, 0.68, 1);
}

@keyframes {
  50% {
    animation-timing-function: var(--easeOutCubic);
  }
}

Helpful resources

Blog Questions Challenge

2025-03-25T00:00:00Z

Hey there.

It has been a minute since my last post. I was semi-recently tagged by Zach Leatherman to (optionally) participate in this year's Blog Questions Challenge. I had planned on doing it then. But life really hit hard as we entered this year and it has not let up. Energy dedicated to my personal webspace has been non-existent. I am tired. Hopefully this post can help shake off some of the rust, bring me back to writing and sharing with you lovely folks.

I won't be tagging anyone to do this challenge. However, if you're inspired to write your own after reading mine, I'd love for you to share it with me.

Why did you start blogging in the first place?

Blogging has always been a part of my web experience. Earliest I can remember is building my band a GeoCities website back in high school. I'd share short passages about new song ideas, how last night's show went, stuff like that. I also briefly had a Xanga blog running. My memory is totally faded on what exactly I wrote in there—I'm not eager to dig up high school feelings either—but fairly certain all of those entries are just lost digital history. Having an "online journal" was such a fresh idea at the time. Sharing felt more natural and real before the social media platforms took over. [blows raspberry] I've completely dated myself and probably sound like "old man yells at cloud" right now.

Anyway, I pretty much stopped blogging for a while after high school. I turned my efforts back to pen on paper, keeping journals of lyrics, thoughts, and feelings mostly to myself. My dev-focused blogging that you may be familiar with really only spans the last decade, give or take a couple years.

What platform are you using to manage your blog and why?

At the moment and the foreseeable future, I'm using 11ty. I published a short post about migrating my site to 11ty back in 2021. I still feel the same sentiments and still admire those same people. And many new community friends as well!

Have you blogged on other platforms before?

I've definitely used WordPress but I can't remember what the heck I was even blogging about during that time. Then I switched to just writing posts directly in HTML files and FTP'ing them up to some server somewhere. Pretty silly in retrospect, but boy did I feel alive.

How do you write your posts?

Always via laptop, never on my phone. I manage posts in markdown files, push them up to a GitHub repo and let that automatically redeploy my site on Netlify. Editing content is done in VSCode. I've debated switching to some lightweight CMS, connecting to Notion or Obsidian, but why introduce any more complexity and mess with what works fine for me?

When do you feel most inspired to write?

Typically I'll write up a post about something new I discovered while on my wild coding escapades, whether it's solving an issue at work or exploring new web features in my free time. If I have trouble finding solutions to my particular problem on the world wide net, I'm even more inclined to post about it. Most of my ideas are pursued on weekends, but I've had some early morning or late night weekday sessions.

What I'm trying to say is that anytime is a good time for blogging. It's like pizza when it's on a bagel.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

It depends. If I had been writing for a long period of time, I find it best to take a breather before publishing. When I feel ready, I'll post and share with a small group for feedback, find grammatical errors. Then I eventually add it to whatever social channels feel right. Used to be Twitter, but straight up screw that garbage temple. I'll likely post on Bluesky, toot on Mastodon. Other times I'll slap a new post on this site and not share it on any socials. Let the RSS feeds do their magic.

What's your favorite post on your blog?

I don't know if I have a favorite. Can I love them all equally? Well, besides that CSS Marquee one. Damn that blog post for becoming so popular.

Any future plans for your blog?

Once things settle down in life, I think I'll be ready for a redesign. I had a blast building the current version inspired by Super Mario Wonder. Until then? More blogging. It won't be super soon, but I do have a few zesty article ideas percolating in this old, tired brain.

Transition to the Other Side with Container Query Units

2025-10-11T00:00:00Z

Managing the position of an element as it travels across the length of its parent container can be tricky. Assuming they both have dynamic, responsive dimensions, we might rely on JS to check the width and/or height of each element and do some calculations for a proper end result. The classic FLIP technique has proven to be a solid solution in the past. For a modern approach, the View Transition API can also work well here.

I now realize there's a much simpler approach using container query units and a dash of CSS wizardry.

The demo

Select the container query units option if it's not already, then click and hold the container to witness the magic. Try changing the element dimensions or resizing the parent container using its handle on the bottom right.

Open CodePen demo

Jump down to the solution if you'd like to get right into it. Otherwise, join me on a transformative journey to this final result.

Transition exploration

The following CSS will transition an element smoothly to the right when its parent container is pressed:

.element {
  transition: transform 200ms ease-out;
}

.parent:active .element {
  transform: translateX(100%);
}

Individual transform properties are also available and well supported in modern browsers. I tend to use them more frequently when writing simple transforms like this. In the demo, we'll find the translate property is being transitioned. Let's update the above code example to something similar:

.element {
  transition: translate 200ms ease-out;
}

.parent:active .element {
  translate: 100%;
}

Keep in mind that there's a pre-defined order for independent transform properties. Stefan's article explains the fundamental differences between transform functions and individual transforms. Not an issue with our current examples, but something to remember when multiple individual transforms are being applied.

Check out the demo with x checked and the percentage option selected. When we click and hold the container, the element transitions the width of itself to the right. We can see that this percentage is based on the element's dimensions. While handy, it doesn't achieve our goal of moving the element all the way to the opposite side.

Explicit dimensions

If we knew the exact dimensions of the parent container, we could declare a calc() function where the element's full percentage is subtracted from the explicit parent size.

.parent {
  width: 300px;
}

.element {
  transition: translate 200ms ease-out;
}

.parent:active .element {
  translate: calc(300px - 100%);
}

It works, but it's uncommon to have explicit dimensions declared like that. Our elements need to be flexible and responsive in any context. What can we do instead?

Position properties

Properties like top and left are available to us. Could we transition the element by doing something like this?

.element {
  position: relative;
  left: 0;
  transition: 200ms ease-out;
  transition-property: translate, left;
}

.parent:active .element {
  left: 100%;
  translate: -100%;
}

Seems that we can, at least in the context of the demo. However, animating position properties has a negative impact on layout and creates performance issues. The browser works harder to recalculate element positions, repaint pixels, and then composite the result. This inevitably leads to janky or sluggish animations. GPU-accelerated properties such as transform and translate avoid triggering repaints so animations run buttery-smooth and fluid.

Fair enough. We'll focus on moving the element using transform properties. It's time to reveal the strongest solution.

The solution

In the demo's controls, check that container query units is selected. Click and hold the container. Watch as the element smoothly transitions to the opposite side of the parent container. Try changing the element dimensions using the sliders, or resize the parent with the resize handle on its bottom right. It still works!

Here's the gist when we only need to transition to the opposite side of the parent horizontally.

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

.element {
  transition: translate 200ms ease-out;
}

.parent:active .element {
  translate: calc(100cqi - 100%);
}

If we want to transition vertically or in both directions, we'll need the size value for our container-type so that containment is applied to the block and inline directions. The example below translates the element along the y-axis.

.parent {
  container-type: size;
}

.element {
  transition: translate 200ms ease-out;
}

.parent:active .element {
  translate: 0 calc(100cqb - 100%);
}

By setting a container-type on the parent, the element is able to access the parent size via container query length units:

1cqi is 1% of the inline size.
1cqb is 1% of the block size.

Notice that we're using logical properties instead of physical ones. If this isn't familiar territory, I recommend Ahmad's excellent Digging Into CSS Logical Properties article to learn more.

100cqi is the full inline size of the parent container. We can recall from earlier that a transform percentage reflects the element's dimensions. Once we subtract 100% from that container query unit, the element can gracefully transition to its proper position on the opposite side of the container.

Take a moment to enjoy the wonder and magic that is modern CSS.