Adam Argyle on web.dev

CSS Subgrid

2023-09-28T00:00:00Z

CSS grid is a very powerful layout engine, but the row and column tracks created on a parent grid can only be used to position direct children of the grid container. Any author defined named grid areas and lines were lost on any other element than a direct child. With subgrid, track sizing, templates and names can be shared with nested grids. This article explains how it works.

Before subgrid, content was often hand tailored to avoid ragged layouts like this one.

After subgrid, aligning the variably sized content is possible.

Browser support

Chrome 114, Behind a flag
Firefox 71, Supported 71
Edge 114, Behind a flag
Safari 16, Supported 16

Source

Subgrid basics #

Here is a straightforward use case introducing the basics of CSS subgrid. A grid is defined with two named columns, the first is 20ch wide and the second is "the rest" of the space 1fr. The column names aren't required but they're great for illustrative and educational purposes.

.grid {
  display: grid;
  gap: 1rem;
  grid-template-columns: [column-1] 20ch [column-2] 1fr;
}

Then, a child of that grid, spans those two columns, is set as a grid container, and adopts the columns of its parent by setting grid-template-columns to subgrid.

.grid > .subgrid {
  grid-column: span 2;

  display: grid;
  grid-template-columns: subgrid; /* 20ch 1fr */
}

https://codepen.io/web-dot-dev/pen/NWezjXv

That's it, a parent grid's columns have been effectively passed down a level to a subgrid. This subgrid can now assign children to either of those columns.

Challenge! Repeat the same demo but do it for grid-template-rows.

Designers often work with shared grids, drawing lines over an entire design, aligning any element they want to it. Now web developers can too! This exact workflow can now be achieved, plus many more.

From macro grid to finished design. Grid named areas are created upfront and later components are placed as desired.

Implementing the most common designer grid workflow can provide excellent insights into the capabilities, workflows, and potentials of subgrid.

Here's a screenshot taken from Chrome DevTools of a mobile page layout macro grid. The lines have names and there are clear areas for component placement.

The following CSS creates this grid, with named rows and columns for the device layout. Each row and column has a size.

.device {
    display: grid;
    grid-template-rows:
      [system-status] 3.5rem
      [primary-nav] 3rem
      [primary-header] 4rem
      [main] auto
      [footer] 4rem
      [system-gestures] 2rem
    ;
    grid-template-columns: [fullbleed-start] 1rem [main-start] auto [main-end] 1rem [fullbleed-end];
}

Some additional styles give the following design.

Inside this parent, are various nested elements. The design requires a full width image under the nav and header rows. The furthest left and right column line names are fullbleed-start and fullbleed-end. Naming grid lines this way enables children to align to each simultaneously with the placement shorthand of fullbleed. It’s very convenient as you’ll soon see.

With the overall device layout created with nice named rows and columns, use subgrid to pass the well named rows and columns to nested grid layouts. This is that subgrid magic moment. The device layout passes the named rows and columns to the app container, which then passes it on to every one of its children.

.device > .app,
.app > * {
    display: grid;
    grid: subgrid / subgrid;

    /* same as */
    grid-template-rows: subgrid;
    grid-template-columns: subgrid;
}

CSS subgrid is a value used in place of a list of grid tracks. The rows and columns the element is spanning from its parent, are now the same rows and columns it offers. This makes the line names from the .device grid available to children of .app, instead of only .app. Elements inside of .app were not able to reference the grid tracks created by .device before subgrid.

With this all defined, the nested image is now able to go full bleed in the layout thanks to subgrid. No negative values or tricks, instead a nice one-liner that says “my layout spans from fullbleed-start to fullbleed-end.”

.app > main img {
    grid-area: fullbleed;
}

https://codepen.io/web-dot-dev/pen/WNLyjzX

There you have it, a macro grid like designers use, implemented in CSS. This concept can scale and grow with you as needed.

Checking for support #

Progressive enhancement with CSS and subgrid is familiar and straightforward. Use @supports and inside the parenthesis ask the browser if it understands subgrid as a value for template columns or rows. The following example checks if the grid-template-columns property supports the subgrid keyword, which if true, means that subgrid can be used

@supports (grid-template-columns: subgrid) {
  /* safe to enhance to */
}

See the Pen Pen KKrJPZQ by web-dot-dev on Codepen

Devtools #

Chrome, Edge, Firefox and Safari all have great CSS grid DevTools, and Chrome, Edge and Firefox have specific tools for helping with subgrid. Chrome announced their tools in 115 while Firefox has had them for a year or more.

The subgrid badge acts like the grid badge but visually distinguishes which grids are subgrids and which aren’t.

Resources #

This list is a compilation of subgrid articles, demos and overall inspiration for getting started. If you’re looking for the next step for your subgrid education, have fun exploring all these great resources!

Adapting typography to user preferences with CSS

2023-07-27T00:00:00Z

Bringing the user into the design process has been an exciting time for users, designers and developers. Users can land on your experience and seamlessly begin consuming content, their preferences richly integrated into the design result.

This blog post explores using CSS media queries with a variable font to tailor the reading experience even further. Font grade and weight can be customized with font-variation-settings, allowing microtuning given various preferences and contexts, like a preference for dark mode or high contrast. We can take these preferences and tailor a variable font for that user experience.

Dark mode gets a slightly reduced gradation.
High contrast gets a bolder font.
Low contrast gets a thinner font.

https://codepen.io/argyleink/pen/mdQrqvj

Follow along to understand each portion of the CSS and variable font that enable this meaningful moment!

Getting setup #

To help focus on the CSS and font variation setting values, but also give us something to read and see, here's the markup you can use to preview the work:

<h1>Variable font weight based on contrast preference</h1>

<p>
  Lorem ipsum dolor sit amet consectetur adipisicing elit.
  Officia, quod? Quidem, nemo aliquam, magnam rerum distinctio
  itaque nisi nam, cupiditate dolorum ad sint. Soluta nemo
  labore aliquid ex, dicta corporis.
</p>

Without adding any CSS, the font size is already adaptive to user preferences. Here's a video from another demo showing how setting font-size in pixels will squash any user preferences, and why you should set your font size in rems:

Lastly, to center and support the demo, a little CSS:

@layer demo.support {
  body {
    display: grid;
    place-content: center;
    padding: var(--size-5);
    gap: var(--size-5);
  }

  h1 {
    text-wrap: balance;
  }
}

This demo setup lets you begin testing and implementing this neat typography UX feature.

Loading the Roboto Flex variable font #

The adaptive strategy depends on a variable font with meaningful axes for customization, specifically you need GRAD and wght. The target adaptive user preferences in this article are for color scheme and contrast, both of which will tailor these axes to match the user's desired preference.

Load the variable font using the @font-face API of CSS:

@font-face {
  font-family: "Roboto Flex";
  src: url('https://assets.codepen.io/2585/RobotoFlex') format('truetype');
}

Next, apply the font to some content. The following CSS applies it to everything:

@layer demo.support {
  body {
    font-family: Roboto Flex;
  }
}

CSS custom properties and media queries for the win #

With the font loaded, you can query for user preferences and adapt the variable font settings to match.

Settings when there's no preferences (default) #

The following initial styles will be the default styles, or another way to look at it, the styles for users without any preferences.

@layer demo {
  body {
    --base-weight: 400;
    --base-grade: 0;

    font-variation-settings:
      "wght" var(--base-weight),
      "GRAD" var(--base-grade)
    ;
  }
}

Settings when the preference is for high contrast #

For users who have indicated a preference for high contrast in their system settings, increase the --base-weight value from 400 to 700:

@layer demo {
  @media (prefers-contrast: more) {
    body {
      --base-weight: 700;
    }
  }
}

Now there's more contrast while reading.

Settings when the preference is for low contrast #

For users who have indicated a preference for low contrast in their system settings, decrease the --base-weight value from 400 to 200:

@layer demo {
  @media (prefers-contrast: less) {
    body {
      --base-weight: 200;
    }
  }
}

Now there's less contrast while reading.

Settings when the preference is for dark mode #

@layer demo {
  @media (prefers-color-scheme: dark) {
    body {
      --base-grade: -25;
    }
  }
}

Now the perceptual differences of light on dark vs dark on light have been accounted for.

All together now #

@layer demo {
  body {
    --base-weight: 400;
    --base-grade: 0;

    font-variation-settings:
      "wght" var(--base-weight),
      "GRAD" var(--base-grade)
    ;
  }

  @media (prefers-contrast: more) {
    body {
      --base-weight: 700;
    }
  }

  @media (prefers-contrast: less) {
    body {
      --base-weight: 200;
    }
  }

  @media (prefers-color-scheme: dark) {
    body {
      --base-grade: -25;
    }
  }
}

Or, for fun, all together with CSS nesting:

@layer demo {
  body {
    --base-weight: 400;
    --base-grade: 0;

    font-variation-settings:
      "wght" var(--base-weight),
      "GRAD" var(--base-grade)
    ;

    @media (prefers-contrast: more)     { --base-weight: 700 }
    @media (prefers-contrast: less)     { --base-weight: 200 }
    @media (prefers-color-scheme: dark) { --base-grade: -25 }
  }
}

The result is a reading experience that adapts the font to match the user's preferences. Full source code is available below in the Codepen.

See the Pen Pen rNQZMzo by web-dot-dev on Codepen

6 CSS snippets every front-end developer should know in 2023

2023-03-15T00:00:00Z

I believe every front-end developer should know how to use container queries, create a scroll snap experience, avoid position: absolute with grid, swiftly hammer out a circle, use cascade layers, and reach more with less via logical properties. Here's a quick overview of each of those expectations.

1. A container query #

The top requested CSS feature for 10 years straight, is now stable across browsers and available for you to use for width queries in 2023.

.panel {
  container: layers-panel / inline-size;
}

.card {
  padding: 1rem;
}

@container layers-panel (min-width: 20rem) {
  .card {
    padding: 2rem;
  }
}

See the Pen Pen OJovdLN by web-dot-dev on Codepen

@container

Browser support

Chrome 105, Supported 105
Firefox 110, Supported 110
Edge 105, Supported 105
Safari 16, Supported 16

Source

container

Browser support

Chrome 105, Supported 105
Firefox 110, Supported 110
Edge 105, Supported 105
Safari 16, Supported 16

Source

2. Scroll snap #

Well orchestrated scroll experiences set your experience apart from the rest, and scroll snap is the perfect way to match system scroll UX while providing meaningful stopping points.

.snaps {
  overflow-x: scroll;
  scroll-snap-type: x mandatory;
  overscroll-behavior-x: contain;
}

.snap-target {
  scroll-snap-align: center;
}

.snap-force-stop {
  scroll-snap-stop: always;
}

See the Pen Pen QWVmYLv by web-dot-dev on Codepen

Learn more about the potential of this CSS feature in this huge and inspiring Codepen collection of around 25 demos.

scroll-snap-type

Browser support

Chrome 69, Supported 69
Firefox 99, Supported 99
Edge 79, Supported 79
Safari 11, Supported 11

Source

scroll-snap-align

Browser support

Chrome 69, Supported 69
Firefox 68, Supported 68
Edge 79, Supported 79
Safari 11, Supported 11

Source

scroll-snap-stop

Browser support

Chrome 75, Supported 75
Firefox 103, Supported 103
Edge 79, Supported 79
Safari 15, Supported 15

Source

overscroll-behavior

Browser support

Chrome 63, Supported 63
Firefox 59, Supported 59
Edge 18, Supported 18
Safari 16, Supported 16

Source

3. Grid pile #

Avoid position absolute with a single cell CSS grid. Once they're piled on top of each other, use justify and align properties to position them.

.pile {
  display: grid;
  place-content: center;
}

.pile > * {
  grid-area: 1/1;
}

See the Pen Pen MWqVLgQ by web-dot-dev on Codepen

grid

Browser support

Chrome 57, Supported 57
Firefox 52, Supported 52
Edge 16, Supported 16
Safari 10.1, Supported 10.1

Source

4. Quick circle #

There are lots of ways to make circles in CSS, but this is definitely the most minimal.

.circle {
  inline-size: 25ch;
  aspect-ratio: 1;
  border-radius: 50%;
}

See the Pen Pen rNZdPBK by web-dot-dev on Codepen

aspect-ratio

Browser support

Chrome 88, Supported 88
Firefox 89, Supported 89
Edge 88, Supported 88
Safari 15, Supported 15

Source

5. Control variants with @layer #

Cascade layers can help insert variants discovered or created later, into the right place in the cascade with the original set of variants.

/* file buttons.css */
@layer components.buttons {
  .btn.primary {
    …
  }
}

Then, in some entirely different file, loaded at some other random time, append a new variant to the button layer as if it was there with the rest of them this whole time.

/* file video-player.css */
@layer components.buttons {
  .btn.player-icon {
    …
  }
}

See the Pen Pen LYJdqPv by web-dot-dev on Codepen

@layer

Browser support

Chrome 99, Supported 99
Firefox 97, Supported 97
Edge 99, Supported 99
Safari 15.4, Supported 15.4

Source

6. Memorize less and reach more with logical properties #

Memorize this one new box model and never have to worry about changing left and right padding or margin for international writing modes and document directions again. Adjust your styles from physical properties to logical ones like padding-inline, margin-inline, inset-inline, and now the browser will do the adjusting work.

button {
  padding-inline: 2ch;
  padding-block: 1ch;
}

article > p {
  text-align: start;
  margin-block: 2ch;
}

.something::before {
  inset-inline: auto 0;
}

See the Pen Pen mdGxvdJ by web-dot-dev on Codepen

padding-inline

Browser support

Chrome 87, Supported 87
Firefox 66, Supported 66
Edge 87, Supported 87
Safari 14.1, Supported 14.1

Source

margin-block

Browser support

Chrome 87, Supported 87
Firefox 66, Supported 66
Edge 87, Supported 87
Safari 14.1, Supported 14.1

Source

inset-inline

Browser support

Chrome 87, Supported 87
Firefox 63, Supported 63
Edge 87, Supported 87
Safari 14.1, Supported 14.1

Source

Example codelab

2023-01-17T00:00:00Z

The codelab layout supports the full range of markdown elements/blocks as demonstrated in the example post.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Diam sollicitudin tempor id eu nisl nunc. Interdum velit euismod in pellentesque. Enim facilisis gravida neque convallis a. Amet mattis vulputate enim nulla aliquet porttitor lacus luctus.

Adding a codelab #

Add a new page using the codelab layout: layout: codelab
Create a glitch project and add the slug to the frontmatter: glitch: grizzly-planet-bite
The project will surface as seen on the right.

Building a tooltip component

2022-10-25T00:00:00Z

In this post I want to share my thoughts on how to build a color-adaptive and accessible <tool-tip> custom element. Try the demo and view the source!

A tooltip is shown working across a variety of examples and color schemes

If you prefer video, here's a YouTube version of this post:

Overview #

A tooltip is a non-modal, non-blocking, non-interactive overlay containing supplemental information to user interfaces. It is hidden by default and becomes unhidden when an associated element is hovered or focused. A tooltip can't be selected or interacted with directly. Tooltips are not replacements for labels or other high value information, a user should be able to fully complete their task without a tooltip.

Do: always label your inputs.
Don't: rely on tooltips instead of labels

Like many components, there are varying descriptions of what a tooltip is, for example in MDN, WAI ARIA, Sarah Higley, and Inclusive Components. I like the separation between tooltips and toggletips. A tooltip should contain non-interactive supplemental information, while a toggletip can contain interactivity and important information. The primary reason for the divide is accessibility, how are users expected to navigate to the popup and have access to the information and buttons within. Toggletips get complex quickly.

Here's a video of a toggletip from the Designcember site; an overlay with interactivity that a user can pin open and explore, then close with light dismiss or the escape key:

This GUI Challenge went the route of a tooltip, looking to do almost everything with CSS, and here's how to build it.

Markup #

I chose to use a custom element <tool-tip>. Authors don't need to make custom elements into web components if they don't want to. The browser will treat <foo-bar> just like a <div>. You could think of a custom element like a classname with less specificity. There's no JavaScript involved.

<tool-tip>A tooltip</tool-tip>

This is like a div with some text inside. We can tie into the accessibility tree of capable screen readers by adding [role="tooltip"].

<tool-tip role="tooltip">A tooltip</tool-tip>

Now, to screen readers, it's recognized as a tooltip. See in the following example how the first link element has a recognized tooltip element in its tree and the second does not? The second one doesn't have the role. In the styles section we'll improve upon this tree view.

Next we need the tooltip to not be focusable. If a screen reader doesn't understand the tooltip role it will allow users to focus the <tool-tip> to read the contents, and the user experience doesn't need this. Screen readers will append the content to the parent element and as such, it doesn't need focus to be made accessible. Here we can use inert to ensure no users will accidentally find this tooltip content in their tab flow:

<tool-tip inert role="tooltip">A tooltip</tool-tip>

I then chose to use attributes as the interface to specify the position of the tooltip. By default all the <tool-tip>s will assume a "top" position, but the position can be customized on an element by adding tip-position:

<tool-tip role="tooltip" tip-position="right ">A tooltip</tool-tip>

I tend to use attributes instead of classes for things like this so that the <tool-tip> can't have multiple positions assigned to it at the same time. There can be only one or none.

Finally, place <tool-tip> elements inside of the element you wish to provide a tooltip for. Here I share the alt text with sighted users by placing an image and a <tool-tip> inside of a <picture> element:

<picture>
  <img alt="The GUI Challenges skull logo" width="100" src="...">
  <tool-tip role="tooltip" tip-position="bottom">
    The <b>GUI Challenges</b> skull logo
  </tool-tip>
</picture>

Here I place a <tool-tip> inside of an <abbr> element:

<p>
  The <abbr>HTML <tool-tip role="tooltip" tip-position="top">Hyper Text Markup Language</tool-tip></abbr> abbr element.
</p>

Accessibility #

Since I've chosen to build tooltips and not toggletips, this section is much simpler. First, let me outline what our desired user experience:

In constrained spaces or cluttered interfaces, hide supplemental messages.
When a user hovers, focuses or uses touch to interact with an element, reveal the message.
When hover, focus or touch ends, hide the message again.
Lastly, ensure any motion is reduced if a user has specified a preference for reduced motion.

Our goal is on demand supplemental messaging. A sighted mouse or keyboard user can hover to reveal the message, reading it with their eyes. A non-sighted screen reader user can focus to reveal the message, audibly receiving it through their tool.

Screenshot of MacOS VoiceOver reading a link with a tooltip

In the previous section we covered the accessibility tree, the tooltip role and inert, what's left is to test it and verify the user experience appropriately reveals the tooltip message to the user. Upon testing, it's unclear as to which part of the audible message is a tooltip. It can be seen while debugging in the accessibility tree too, the link text of "top" is run together, without hesitation, with "Look, tooltips!". The screen reader doesn't break or identify the text as tooltip content.

Add a screen reader only pseudo-element to the <tool-tip> and we can add our own prompt text for non-sighted users.

&::before {
  content: "; Has tooltip: ";
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(50%);
  height: 1px;
  width: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
}

Below you can see the updated accessibility tree, which now has a semicolon after the link text and a prompt for the tooltip "Has tooltip: ".

Now, when a screen reader user focuses the link, it says "top" and takes a small pause, then announces "has tooltip: look, tooltips". This gives a screen reader user a couple nice UX hints. The hesitation gives a nice separation between the link text and the tooltip. Plus, when "has tooltip" is announced, a screen reader user can easily cancel it if they've already heard it before. It's very reminiscent to hovering and unhovering quickly, as you've already seen the supplemental message. This felt like nice UX parity.

Styles #

The <tool-tip> element will be a child of the element it's representing supplemental messaging for, so let's first start with the essentials for the overlay effect. Take it out of document flow with position absolute:

tool-tip {
  position: absolute;
  z-index: 1;
}

If the parent is not a stacking context, the tooltip will position itself to the nearest one that is, which isn't what we want. There's a new selector on the block that can help, :has():

Browser support

Chrome 105, Supported 105
Firefox 103, Behind a flag
Edge 105, Supported 105
Safari 15.4, Supported 15.4

Source

:has(> tool-tip) {
  position: relative;
}

Don't worry too much about the browser support. First, remember these tooltips are supplementary. If they don't work it should be fine. Second, in the JavaScript section we'll deploy a script to polyfill the functionality we need for browsers without :has() support.

Next, let's make the tooltips non-interactive so they don’t steal pointer events from their parent element:

tool-tip {
  …
  pointer-events: none;
  user-select: none;
}

Then, hide the tooltip with opacity so we can transition the tooltip with a crossfade:

tool-tip {
  opacity: 0;
}

:has(> tool-tip):is(:hover, :focus-visible, :active) > tool-tip {
  opacity: 1;
}

:is() and :has() do the heavy lifting here, making tool-tip containing parent elements aware of user interactivity as to toggle the visibility of a child tooltip. Mouse users can hover, keyboard and screen reader users can focus, and touch users can tap.

With the show and hide overlay working for sighted users, it's time to add some styles for theming, positioning and adding the triangle shape to the bubble. The following styles begin using custom properties, building upon where we are so far but also adding shadows, typography and colors so it looks like a floating tooltip:

tool-tip {
  --_p-inline: 1.5ch;
  --_p-block: .75ch;
  --_triangle-size: 7px;
  --_bg: hsl(0 0% 20%);
  --_shadow-alpha: 50%;

  --_bottom-tip: conic-gradient(from -30deg at bottom, rgba(0,0,0,0), #000 1deg 60deg, rgba(0,0,0,0) 61deg) bottom / 100% 50% no-repeat;
  --_top-tip: conic-gradient(from 150deg at top, rgba(0,0,0,0), #000 1deg 60deg, rgba(0,0,0,0) 61deg) top / 100% 50% no-repeat;
  --_right-tip: conic-gradient(from -120deg at right, rgba(0,0,0,0), #000 1deg 60deg, rgba(0,0,0,0) 61deg) right / 50% 100% no-repeat;
  --_left-tip: conic-gradient(from 60deg at left, rgba(0,0,0,0), #000 1deg 60deg, rgba(0,0,0,0) 61deg) left / 50% 100% no-repeat;

  pointer-events: none;
  user-select: none;

  opacity: 0;
  transform: translateX(var(--_x, 0)) translateY(var(--_y, 0));
  transition: opacity .2s ease, transform .2s ease;

  position: absolute;
  z-index: 1;
  inline-size: max-content;
  max-inline-size: 25ch;
  text-align: start;
  font-size: 1rem;
  font-weight: normal;
  line-height: normal;
  line-height: initial;
  padding: var(--_p-block) var(--_p-inline);
  margin: 0;
  border-radius: 5px;
  background: var(--_bg);
  color: CanvasText;
  will-change: filter;
  filter:
    drop-shadow(0 3px 3px hsl(0 0% 0% / var(--_shadow-alpha)))
    drop-shadow(0 12px 12px hsl(0 0% 0% / var(--_shadow-alpha)));
}

/* create a stacking context for elements with > tool-tips */
:has(> tool-tip) {
  position: relative;
}

/* when those parent elements have focus, hover, etc */
:has(> tool-tip):is(:hover, :focus-visible, :active) > tool-tip {
  opacity: 1;
  transition-delay: 200ms;
}

/* prepend some prose for screen readers only */
tool-tip::before {
  content: "; Has tooltip: ";
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(50%);
  height: 1px;
  width: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
}

/* tooltip shape is a pseudo element so we can cast a shadow */
tool-tip::after {
  content: "";
  background: var(--_bg);
  position: absolute;
  z-index: -1;
  inset: 0;
  mask: var(--_tip);
}

/* top tooltip styles */
tool-tip:is(
  [tip-position="top"],
  [tip-position="block-start"],
  :not([tip-position]),
  [tip-position="bottom"],
  [tip-position="block-end"]
) {
  text-align: center;
}

Theme adjustments #

The tooltip only has a few colors to manage as the text color is inherited from the page via the system keyword CanvasText. Also, since we've made custom properties to store the values, we can update only those custom properties and let the theme handle the rest:

@media (prefers-color-scheme: light) {
  tool-tip {
    --_bg: white;
    --_shadow-alpha: 15%;
  }
}

For the light theme, we adapt the background to white and make the shadows much less strong by adjusting their opacity.

Right to left #

In order to support right to left reading modes, a custom property will store the value of the document direction into a value of -1 or 1 respectively.

tool-tip {
  --isRTL: -1;
}

tool-tip:dir(rtl) {
  --isRTL: 1;
}

This can be used to assist in positioning the tooltip:

tool-tip[tip-position="top"]) {
  --_x: calc(50% * var(--isRTL));
}

As well as assist in where the triangle is:

tool-tip[tip-position="right"]::after {
  --_tip: var(--_left-tip);
}

tool-tip[tip-position="right"]:dir(rtl)::after {
  --_tip: var(--_right-tip);
}

Lastly, can also be used for logical transforms on translateX():

--_x: calc(var(--isRTL) * -3px * -1);

Position the tooltip logically with the inset-block or inset-inline properties to handle both the physical and logical tooltip positions. The following code shows how each of the four positions are styled for both left-to-right and right-to-left directions.

Top and block-start alignment #

tool-tip:is([tip-position="top"], [tip-position="block-start"], :not([tip-position])) {
  inset-inline-start: 50%;
  inset-block-end: calc(100% + var(--_p-block) + var(--_triangle-size));
  --_x: calc(50% * var(--isRTL));
}

tool-tip:is([tip-position="top"], [tip-position="block-start"], :not([tip-position]))::after {
  --_tip: var(--_bottom-tip);
  inset-block-end: calc(var(--_triangle-size) * -1);
  border-block-end: var(--_triangle-size) solid transparent;
}

Right and inline-end alignment #

tool-tip:is([tip-position="right"], [tip-position="inline-end"]) {
  inset-inline-start: calc(100% + var(--_p-inline) + var(--_triangle-size));
  inset-block-end: 50%;
  --_y: 50%;
}

tool-tip:is([tip-position="right"], [tip-position="inline-end"])::after {
  --_tip: var(--_left-tip);
  inset-inline-start: calc(var(--_triangle-size) * -1);
  border-inline-start: var(--_triangle-size) solid transparent;
}

tool-tip:is([tip-position="right"], [tip-position="inline-end"]):dir(rtl)::after {
  --_tip: var(--_right-tip);
}

Bottom and block-end alignment #

tool-tip:is([tip-position="bottom"], [tip-position="block-end"]) {
  inset-inline-start: 50%;
  inset-block-start: calc(100% + var(--_p-block) + var(--_triangle-size));
  --_x: calc(50% * var(--isRTL));
}

tool-tip:is([tip-position="bottom"], [tip-position="block-end"])::after {
  --_tip: var(--_top-tip);
  inset-block-start: calc(var(--_triangle-size) * -1);
  border-block-start: var(--_triangle-size) solid transparent;
}

Left and inline-start alignment #

tool-tip:is([tip-position="left"], [tip-position="inline-start"]) {
  inset-inline-end: calc(100% + var(--_p-inline) + var(--_triangle-size));
  inset-block-end: 50%;
  --_y: 50%;
}

tool-tip:is([tip-position="left"], [tip-position="inline-start"])::after {
  --_tip: var(--_right-tip);
  inset-inline-end: calc(var(--_triangle-size) * -1);
  border-inline-end: var(--_triangle-size) solid transparent;
}

tool-tip:is([tip-position="left"], [tip-position="inline-start"]):dir(rtl)::after {
  --_tip: var(--_left-tip);
}

Animation #

So far we've only toggled the visibility of the tooltip. In this section we'll first animate opacity for all users, as it's a generally safe reduced motion transition. Then we'll animate the transform position so the tooltip appears to slide out from the parent element.

A safe and meaningful default transition #

Style the tooltip element to transition opacity and transform, like this:

tool-tip {
  opacity: 0;
  transform: translateX(var(--_x, 0)) translateY(var(--_y, 0));
  transition: opacity .2s ease, transform .2s ease;
}

:has(> tool-tip):is(:hover, :focus-visible, :active) > tool-tip {
  opacity: 1;
  transition-delay: 200ms;
}

Adding motion to the transition #

For each of the sides a tooltip can appear on, if the user is ok with motion, slightly position the translateX property by giving it a small distance to travel from:

@media (prefers-reduced-motion: no-preference) {
  :has(> tool-tip:is([tip-position="top"], [tip-position="block-start"], :not([tip-position]))):not(:hover):not(:focus-visible):not(:active) tool-tip {
    --_y: 3px;
  }

  :has(> tool-tip:is([tip-position="right"], [tip-position="inline-end"])):not(:hover):not(:focus-visible):not(:active) tool-tip {
    --_x: -3px;
  }

  :has(> tool-tip:is([tip-position="bottom"], [tip-position="block-end"])):not(:hover):not(:focus-visible):not(:active) tool-tip {
    --_y: -3px;
  }

  :has(> tool-tip:is([tip-position="left"], [tip-position="inline-start"])):not(:hover):not(:focus-visible):not(:active) tool-tip {
    --_x: 3px;
  }
}

Notice this is setting the "out" state, as the "in" state is at translateX(0).

JavaScript #

In my opinion, the JavaScript is optional. This is because none of these tooltips should be required reading to accomplish a task in your UI. So if the tooltips completely fail, it should be no big deal. This also means we can treat the tooltips as progressively enhanced. Eventually all browsers will support :has() and this script can completely go away.

The polyfill script does two things, and does so only if the browser doesn't support :has(). First, check for :has() support:

if (!CSS.supports('selector(:has(*))')) {
  // do work
}

Next, find the parent elements of <tool-tip>s and give them a classname to work with:

if (!CSS.supports('selector(:has(*))')) {
  document.querySelectorAll('tool-tip').forEach(tooltip =>
    tooltip.parentNode.classList.add('has_tool-tip'))
}

Next, inject a set of styles that use that classname, simulating the :has() selector for the exact same behavior:

if (!CSS.supports('selector(:has(*))')) {
  document.querySelectorAll('tool-tip').forEach(tooltip =>
    tooltip.parentNode.classList.add('has_tool-tip'))

  let styles = document.createElement('style')
  styles.textContent = `
    .has_tool-tip {
      position: relative;
    }
    .has_tool-tip:is(:hover, :focus-visible, :active) > tool-tip {
      opacity: 1;
      transition-delay: 200ms;
    }
  `
  document.head.appendChild(styles)
}

That's it, now all browsers will happily show the tooltips if :has() is not supported.

Conclusion #

Now that you know how I did it, how would you‽ 🙂 I'm really looking forward to the popup API for making toggletips easier, top layer for no z-index battles, and the anchor API for positioning things in the window better. Until then, I'll be making tooltips.

Let's diversify our approaches and learn all the ways to build on the web.

Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Nothing to see here yet.

Resources #

Source code on Github

Building a floating action button (FAB) component

2022-10-06T00:00:00Z

In this post I want to share my thoughts on how to build color-adaptive, responsive, and accessible FAB components. Try the demo and view the source!

If you prefer video, here's a YouTube version of this post:

Overview #

FABs are more common on mobile than desktop, but they're prevalent in both scenarios. They keep primary actions in view, making them convenient and omnipresent. This user experience style was made famous by Material UI and their suggestions for usage and placement can be found here.

Elements and styles #

The HTML for these controls involves a container element and a set of one or more buttons. The container positions the FABs within the viewport and manages a gap between the buttons. The buttons can be mini or default, giving some nice variety between primary and secondary actions.

FAB container #

This element can be a regular <div> but let's do our unsighted users a favor and tag it with some helpful attributes to explain the purpose and contents of this container.

FABs markup #

Start with a .fabs class for CSS to hook into for style, then add role="group" and aria-label so it's not just a generic container, it's named and purposeful.

<div class="fabs" role="group" aria-label="Floating action buttons">
  <!-- buttons will go here -->
</div>

FABs style #

In order for FABs to be convenient they stick within the viewport at all times. This is a great use case for position fixed. Within this viewport position I chose to use inset-block and inset-inline so the position will compliment the user's document mode, like right-to-left or left-to-right. Custom properties are also used to prevent repetition and ensure equal distance from the bottom and side edges of the viewport:

.fabs {
  --_viewport-margin: 2.5vmin;

  position: fixed;
  z-index: var(--layer-1);

  inset-block: auto var(--_viewport-margin);
  inset-inline: auto var(--_viewport-margin);
}

Next I give the container display flex and change its layout direction to column-reverse. This stacks the children on top of each other (column) and also reverses their visual order. This has the effect of making the first focusable element the bottom element instead of the top, which would be where focus goes normally per the HTML document. Reversing the visual order unites the experience for sighted users and keyboard users, as the styling of the primary action as larger than the mini buttons indicates to sighted users that it's a primary action, and keyboard users will focus it as the first item in the source.

.fabs {
  …

  display: flex;
  flex-direction: column-reverse;
  place-items: center;
  gap: var(--_viewport-margin);
}

Centering is handled with place-items, and gap adds space between any FAB buttons placed in the container.

FAB buttons #

Time to style some buttons to look like they're floating over top of everything.

Default FAB #

The first button to style is the default button. This will serve as the base for all the FAB buttons. Later we'll create a variant that achieves an alternative appearance while modifying as little of these base styles as possible.

FAB markup #

The <button> element is the right choice. We'll start with this as the base because it comes with great mouse, touch, and keyboard user experience. The most crucial aspect of this markup is to hide the icon from screenreader users with aria-hidden="true" and add the necessary label text to the <button> markup itself. When adding labels in these cases I also like adding a title so mouse users can get information about what the icon is hoping to communicate.

<button data-icon="plus" class="fab" title="Add new action" aria-label="Add new action">
  <svg aria-hidden="true" width="24" height="24" viewBox="0 0 24 24">...</svg>
</button>

FAB style #

First let's turn the button into a padded round button with a strong shadow, as these are the first defining features of the button:

.fab {
  --_size: 2rem;

  padding: calc(var(--_size) / 2);
  border-radius: var(--radius-round);
  aspect-ratio: 1;
  box-shadow: var(--shadow-4);
}

Next let's add color. We'll use a strategy we've used in GUI Challenges before. Create a clearly named set of custom properties that statically hold the light and dark colors, then an adaptive custom property that will be set to either the light or the dark variables depending on the user's system preference for colors:

.fab {
  …

  /* light button and button hover */
  --_light-bg: var(--pink-6);
  --_light-bg-hover: var(--pink-7);

  /* dark button and button hover */
  --_dark-bg: var(--pink-4);
  --_dark-bg-hover: var(--pink-3);

  /* adaptive variables set to light by default */
  --_bg: var(--_light-bg);

  /* static icon colors set to the adaptive foreground variable */
  --_light-fg: white;
  --_dark-fg: black;
  --_fg: var(--_light-fg);

  /* use the adaptive properties on some styles */
  background: var(--_bg);
  color: var(--_fg);

  &:is(:active, :hover, :focus-visible) {
    --_bg: var(--_light-bg-hover);

    @media (prefers-color-scheme: dark) {
      --_bg: var(--_dark-bg-hover);
    }
  }

  /* if users prefers dark, set adaptive props to dark */
  @media (prefers-color-scheme: dark) {
    --_bg: var(--_dark-bg);
    --_fg: var(--_dark-fg);
  }
}

Next add some styles to help the SVG icons fit the space.

.fab {
  …

  & > svg {
    inline-size: var(--_size);
    block-size: var(--_size);
    stroke-width: 3px;
  }
}

Last, remove the tap highlight from the button since we've added our own visual feedback for interaction:

.fab {
  -webkit-tap-highlight-color: transparent;
}

Mini FAB #

The goal of this section is to create a variant for the FAB button. By making some of the FABs smaller than the default action, we can promote the action the user performs the most often.

Mini FAB markup #

The HTML is the same as a FAB but we add a ".mini" class to give CSS a hook into the variant.

<button data-icon="heart" class="fab mini" title="Like action" aria-label="Like action">
  <svg aria-hidden="true" width="24" height="24" viewBox="0 0 24 24">...</svg>
</button>

Mini FAB style #

Thanks to usage of custom properties, the only change needed is an adjustment to the --_size variable.

.fab.mini {
  --_size: 1.25rem;
}

Accessibility #

The most important part to remember for accessibility with FABs is placement within the keyboard flow of the page. This demo only has the FABs, there's nothing to compete with in terms of keyboard order and flow, which means it doesn't have an opportunity to demonstrate a meaningful keyboard flow. In a scenario where there's competing elements for focus, I suggest thinking deeply about where in that flow should a user find themselves entering into the FAB button flow.

Keyboard interaction demonstration

Once the user has focused into the FAB container, we've already added role="group" and aria-label="floating action buttons" which inform screen reader users about the contents of what they have focused. Strategically I've placed the default FAB first, so that users find the primary action first. I then use flex-direction: column-reverse; to visually order the primary button on the bottom, close to the users fingers for easy access. This is a nice win because the default button is visually prominent and also first for keyboard users, giving them very similar experiences.

Lastly, don't forget to hide your icons from screen reader users and ensure you provide them with a label for the button so it's not a mystery. This has been done in the HTML already with aria-hidden="true" on the <svg> and aria-label="Some action" on the <button>s.

Animation #

Various types of animation can be added to enhance the user experience. Like in other GUI Challenges, we'll set up a couple of custom properties to hold the intent of a reduced motion experience and a full motion experience. By default the styles will assume the user wants reduced motion, then using the prefers-reduced-motion media query swap the transition value to full motion.

A reduced motion strategy with custom properties #

Three custom properties are created in the following CSS: --_motion-reduced, --_motion-ok, and --_transition. The first two hold appropriate transitions given the user's preference, and the last variable --_transition will be set to either --_motion-reduced or --_motion-ok respectively.

.fab {
  /* box-shadow and background-color can safely be transitioned for reduced motion users */
  --_motion-reduced:
    box-shadow .2s var(--ease-3),
    background-color .3s var(--ease-3);

  /* add transform and outline-offset for users ok with motion */
  --_motion-ok:
    var(--_motion-reduced),
    transform .2s var(--ease-3),
    outline-offset 145ms var(--ease-2);

  /* default the transition styles to reduced motion */
  --_transition: var(--_motion-reduced);

  /* set the transition to our adaptive transition custom property*/
  transition: var(--_transition);

  /* if motion is ok, update the adaptive prop to the respective transition prop */
  @media (prefers-reduced-motion: no-preference) {
    --_transition: var(--_motion-ok);
  }
}

With the above in place, changes to box-shadow, background-color, transform and outline-offset can be transitioned, giving the user nice UI feedback that their interaction has been received.

Next, add a little bit more flair to the :active state by adjusting translateYa little bit, this gives the button a nice pressed effect:

.fab {
  …

  &:active {
    @media (prefers-reduced-motion: no-preference) {
      transform: translateY(2%);
    }
  }
}

Then lastly, transition any changes to the SVG icons in the buttons:

.fab {
  …

  &[data-icon="plus"]:hover > svg {
    transform: rotateZ(.25turn);
  }

  & > svg {
    @media (prefers-reduced-motion: no-preference) {
      will-change: transform;
      transition: transform .5s var(--ease-squish-3);
    }
  }
}

Conclusion #

Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web.

Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Nothing to see here yet.

Resources #

Source code on Github

Testing Web Design Color Contrast

2022-09-22T00:00:00Z

Say you have some text on a light background, like this:

While all of the examples may be readable to you, this isn't the case for everyone.

Accessible color contrast is a practice that ensures text is readable for everyone. Sometimes testing contrast is easy and sometimes it's really hard. By the end of this post you'll have three new tools and techniques for inspecting, correcting, and verifying your web design contrast so you can tackle the hardest scenarios.

WCAG and color contrast #

W3C’s Web Accessibility Initiative provides strategies, standards, and resources to ensure that the internet is accessible for as many people as possible. The guidelines that underpin these standards are called the Web Content Accessibility Guidelines, or WCAG. The latest stable version, WCAG 2.1, covers an important accessibility requirement: minimum contrast.

The relationship between two colors in WCAG 2.1 is described by their contrast ratio—that is, the number you get when you compare the luminance of two colors. Luminance is a way of describing how close a color is to black (0%) or white (100%). WCAG defines some rules and calculation algorithms around what that contrast ratio needs to be in order for the web to be accessible. There are known issues with this calculation, though. Eventually an even more reliable way will be adopted, but, currently, WCAG is the best we have.

What are the rules? #

	AA	AAA
Body text (< 24px)	4.5	7
Large text (> 24px)	3	4.5
UI (icons, graphs, etc.)	3	not defined

A higher contrast ratio is scored with a higher number, like 4.5 or 7 instead of 3. To get more familiar with the scoring table, check out Polypane's Contrast Checker.

Which of these color pairings do you feel contrast more?

Testing contrast between colors #

So, now that we know what we’re looking for, how do we test this? Here are three free tools to assist you in inspecting, correcting and measuring your web site's contrast. The strengths and weaknesses of each will be outlined so you can confidently test the accessibility of your site’s colors and content in a multitude of ways.

Pika
A MacOS app, uniquely capable of showing the contrast of any colors on the entire screen, colors on gradients, colors with transparency, and more. Intent is explicit, users manually choose the pixels to compare. A tiny bit less automated with a huge feature gain.
VisBug
A cross browser extension, uniquely able to show more than one contrast overlay at a time, but like DevTools, sometimes isn't able to detect intent.
Chrome DevTools
DevTools is built into Chrome and is packed with various ways to inspect, correct, and debug color issues, but has shortcomings when inspecting gradients and semi-transparent colors, and sometimes isn't able to detect intent.

Pika (macOS application) #

If DevTools or VisBug can't assess the contrast properly, like when you need to test a color outside the browser, or when transparency or gradients are involved, then Pika is here to save the day. Pika has access to every pixel on the screen because it's a system tool and not a web tool.

Download Pika

This also means the UX for using Pika is different to DevTools or VisBug. DevTools and VisBug do their best to show the text and background colors from the browser DOM, while the colors Pika compares are chosen manually from any point on screen. This gives Pika more control, and opens up some additional use cases:

Comparing any two colors regardless of whether or not they’re in the browser—if you can see it on your screen, you can test it.
Comparing colors with transparency.
Comparing colors within gradients.
Comparing colors that are using blend modes, like mix-blend-mode in CSS.

Comparing any two colors #

Compare text to a background color:

Compare stroke and fill colors of vector graphics:

Comparing colors with transparency #

Compare text color to a variety of background sample pixels. Here, the lightest gray from the frosted glass effect is used as the background comparison color.

Comparing colors with gradients #

Compare text on a gradient or on an image. Here the L from "Lasso" is compared against the light blue of the image:

VisBug #

VisBug is a FireBug inspired tool for designers and developers to visually inspect, debug, and play with their website design. It's meant to have a lower barrier to entry than the Chrome DevTools by emulating the UI and UX of the design tools that folks have come to know and love to use.

Try VisBug or install on Chrome, Firefox, Edge, Brave or Safari.

One of its tool offerings is the Accessibility Inspect tool.

Inspect across browsers (and even on mobile) #

Once the Accessibility Inspect tool has been clicked, anything the user points to, or keyboard navigates to, will have its accessibility information reported in the tooltip. This tooltip includes color comparisons between discovered foreground and background colors.

Inspect one or many #

DevTools can either look at a single color pairing or get a report of all of your color pairings in the page, but VisBug offers a nice middle ground by allowing multiple color pairings. Click an element and the tooltip will stay put. Hold Shift and continue clicking other elements and all of the tooltips will stay put:

This is especially important for component based design, where multiple parts of a component need to pass contrast ratio scores. This method allows seeing all of those component parts at once. Also great for design reviews.

Chrome DevTools #

If you have Chrome installed then you're already equipped with many contrast testing tools:

The Chrome DevTools color picker #

In the Chrome DevTools Styles pane of the Elements panel, color values will have a little visual square color swatch next to them. When this swatch is clicked you'll see the color picker tool. If possible, the middle of the tool will show the contrast of the color against a foreground or background.

In the following example, the color picker is opened for a custom property color value. The contrast ratio score is reported as 15.79 and has two green check marks, indicating the score passes AA and AAA WCAG 2.1 requirements:

Color Picker autocorrection #

Seeing the score while picking colors is handy, but Chrome DevTools has an additional feature for autocorrection. When the color picker reports a failed accessible color contrast score it can be expanded to reveal the AA and AAA score targets, plus an eye dropper tool. Next to AA and AAA are swatches and a refresh icon that when clicked will find the nearest passing color for you:

If you're not picky about colors, the auto correction feature is a great way to meet accessibility guidelines and not work too hard to get the task done.

The element selection tool has a special feature during page hover that reports general font, color, and accessibility information. The element selection tool is the icon on the left in the following screenshot. It’s the box with an arrow cursor over the bottom right corner. It can also be selected using the hotkey Control+Shift+C (or Command+Shift+C on MacOS).

Once activated, the icon will turn blue, and pointing to anything in the page will show the following quick inspect tooltip:

Instead of the color picker tool, which requires you to find the color swatch in the Styles pane, this tool lets you simply point around the page to see contrast scores. Like the color picker, it can only show one contrast score at a time.

Bump bump 'til you pass 🎶 #

I often inspect a color pairing with this quick inspect tool and find it just short of passing the required ratio. Instead of using the autocorrection feature of the color picker (because I'm picky) I nudge color channels in the CSS and watch until I pass the ratio I need. I call this process "bump bump til you pass" because I'm bumping color channel numbers until they pass WCAG 2.1.

The steps are as follows, and must be done in the exact order:

Set keyboard focus inside a color in the Styles panel.
Activate the inspect element tool with the keyboard shortcut Control+Shift+C (or Command+Shift+C on MacOS).
Point over a target.
Press up/down on the keyboard to change the numbers in the color value.

This works because the CSS style value still has your keyboard focus, while the mouse is allowing you to point over a target. Make sure not to click your target or focus will move from the color value area and not let you nudge values anymore until refocused.

CSS overview #

Up to this point, Chrome DevTools has provided ways to look at one color pairing at a time, but the CSS Overview can crawl your entire page and present all the inaccessible pairings at once:

Read more about this feature in this post CSS Overview: Identify potential CSS improvements or watch Jecelyn Yeen on YouTube in their series DevTools Tips teach you how to Identify potential CSS improvements with the CSS Overview panel.

Lighthouse #

Lighthouse is another auditing tool in Chrome DevTools. It can crawl your page and report inaccessible color pairings. It features tiny screenshots of each color pairing for you to review, passing and failing. Any failing combinations will negatively impact your Lighthouse score.

Here's what those results can look like:

The JS console #

Maybe all the tools listed so far just aren’t where you are. Maybe where you are (all day) is JavaScript. Here's an experiment to try. The Issues pane of the console can constantly report any color contrast accessibility issues as you build. Enable the feature in Settings > Experiments, as shown in the following:

Then open the Issue pane and see if it's made any discoveries. If it does, they can look like this:

Colorblind emulation #

While on the topic of color contrast and ensuring accessible color pairings, it's worth pointing out the vision deficiencies emulation tool. This will change the colors or appearance of your design to demonstrate the results of different varieties of color blindness, giving you the opportunity to modify your design so that color isn't the only way the UX is communicating to a user.

It's not a safe accessibility practice to exclusively use color to depict information, like red for bad and green for good. Some folks don't see greens or reds the same and this emulation tool will help you experience and remember that.

Color contrast system preference emulation #

More and more, users are changing their contrast settings in their operating system, giving them the ability to ask for less or more contrast personalization in their UI. CSS can tap into this setting, just as it can with light or dark theme preferences. Chrome DevTools offers the ability to emulate this preference so designs can test and adapt to the user request without toggling the setting from the system.

Try WCAG 3.0 APCA #

Another experiment to try is testing your color pairings with the experimental APCA color ratio scoring system. Enabled through Settings > Experiments, it replaces the WCAG 2.1 ratio system with a newer and improved contrast checker algorithm, letting you preview its results as the proposal works towards a standard.

Once enabled, use the point inspect tooltip or the color picker to see the color pairing score and see if it passes:

Conclusion #

Color contrast is an important piece of the puzzle for accessibility on the web, and adhering to it makes the web more usable for the greatest number of people in the most varied situations. Hopefully these three tools help you feel empowered to make great color choices.

Building a crooked grid illusion

2022-08-24T00:00:00Z

In this post we're going to have a little bit of fun! There must be 100 ways to achieve this optical illusion, and I'm only going to share with you my thoughts, but encourage you to try your style. Try the demo and view the source.

If you prefer video, here's a YouTube version of this post:

Overview #

The name of this illusion is the Cafe Wall Illusion. There's no crooked lines to be found anywhere, but our eyes perceive slants. It may be hard to believe, but rebuilding it will definitely help you see through the illusion.

Markup #

The HTML for this is straightforward rows and columns. The <body> is the container with <div class="row"> for children. Each row contains five <div class="square"> elements.

<div class="row">
  <div class="square"></div>
  <div class="square"></div>
  <div class="square"></div>
  <div class="square"></div>
  <div class="square"></div>
</div>
…

Styles #

I chose CSS grid because it seemed fitting given the presentation style of rows, and it also features justify-content which seemed like a good way to offset row children.

Body styles #

Starting with the body styles, I used display: grid and grid-auto-rows to provide the row layouts. The calc() you see for the row sizes takes into account the border on each row, and helps the effect fit the full viewport.

body {
  display: grid;
  grid-auto-rows: calc(20vh - 4px);
  gap: 4px;
  background: gray;
  margin: 0;
}

Row styles #

Here I chose grid again, but instead of creating rows with it I used grid-auto-flow: column to change the direction to columns. I then define column sizes and add a little inline padding to the row, so boxes don't run into the viewport edge. Then I target certain rows and justify the content to either center or end, creating that offset that fuels the illusion.

.row {
  display: grid;
  grid-auto-flow: column;
  grid-auto-columns: 9vw;
  padding-inline: 4vw;
  gap: 10vw;
  background: white;
}

.row:nth-child(even) {
  justify-content: center;
}

.row:nth-child(3n) {
  justify-content: end;
}

Square styles #

All that's left now is to change the squares color and add a border:

.square {
  border-inline: 4px solid gray;
  background: black;
}

Conclusion #

Now that you know how I did it, how would you?! 🙂 Floats? Flexbox? Gradient?!

Let's diversify our approaches and learn all the ways to build on the web.

Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Mark Boots with gradients: demo and code

New patterns

2022-07-29T00:00:00Z

I'm excited to share many new web.dev patterns! These additions are from the show GUI Challenges where I share my strategies on how to build various components and common interface needs, then collect user submissions for the same tasks and help us all grow our perspectives on how to solve them.

Turns out GUI Challenges fit nicely into patterns:

<h1 split-by="word" word-animation="hover">
  hover the words
</h1>

const span = (text, index) => {
  const node = document.createElement('span')

  node.textContent = text
  node.style.setProperty('--index', index)
  
  return node
}

export const byWord = text =>
  text.split(' ').map(span)

const {matches:motionOK} = window.matchMedia(
  '(prefers-reduced-motion: no-preference)'
)

if (motionOK) {
  const splitTargets = document.querySelectorAll('[split-by]')

  splitTargets.forEach(node => {
    let nodes = byWord(node.innerText)

    if (nodes)
      node.firstChild.replaceWith(...nodes)
  })
}

@media (prefers-reduced-motion:no-preference) {
  [word-animation] {
    display: inline-flex;
    flex-wrap: wrap;
    gap: 1ch
  }
}

@media (prefers-reduced-motion:no-preference) and (hover) {
  [word-animation=hover] {
    overflow: hidden;
    overflow: clip
  }

  [word-animation=hover]>span {
    transition: transform .3s ease;
    cursor: pointer
  }

  [word-animation=hover]>span:not(:hover) {
    transform: translateY(50%)
  }
}

Open demo

Now they can be embedded into posts (like above), aggregated for easy browsing and inspiration, and also have added new categories for other contributors to add their patterns to. Take a look around, take some code: it's all there for you.

Overview #

Three new pattern categories:

Plus, five new patterns added to the existing Layout patterns.

Components #

View the component patterns landing page or check each out individually:

Here's a preview of the split button pattern:

<div class="gui-split-button">
  <button>View Cart</button>
  <span class="gui-popup-button" aria-haspopup="true" aria-expanded="false" title="Open for more actions">
    <svg aria-hidden="true" viewBox="0 0 20 20">
      <path d="M5.293 7.293a1 1 0 011.414 0L10 10.586l3.293-3.293a1 1 0 111.414 1.414l-4 4a1 1 0 01-1.414 0l-4-4a1 1 0 010-1.414z" />
    </svg>
    <ul class="gui-popup">
      <li><button>
        <svg aria-hidden="true" viewBox="0 0 24 24">
          <path d="M3 3h2l.4 2M7 13h10l4-8H5.4M7 13L5.4 5M7 13l-2.293 2.293c-.63.63-.184 1.707.707 1.707H17m0 0a2 2 0 100 4 2 2 0 000-4zm-8 2a2 2 0 11-4 0 2 2 0 014 0z" />
        </svg>
        Checkout
      </button></li>
      <li><button>
        <svg aria-hidden="true" viewBox="0 0 24 24">
          <path d="M16 11V7a4 4 0 00-8 0v4M5 9h14l1 12H4L5 9z" />
        </svg>
        Quick Pay
      </button></li>
      <li><button>
        <svg aria-hidden="true" viewBox="0 0 24 24">
          <path d="M5 5a2 2 0 012-2h10a2 2 0 012 2v16l-7-3.5L5 21V5z" />
        </svg>
        Save for later
      </button></li>
    </ul>
  </span>
</div>

<div class="gui-split-button">
  <button>Send</button>
  <span class="gui-popup-button" aria-haspopup="true" aria-expanded="false" title="Open for more actions">
    <svg aria-hidden="true" viewBox="0 0 20 20">
      <path d="M5.293 7.293a1 1 0 011.414 0L10 10.586l3.293-3.293a1 1 0 111.414 1.414l-4 4a1 1 0 01-1.414 0l-4-4a1 1 0 010-1.414z" />
    </svg>
    <ul class="gui-popup">
      <li><button>
        <svg aria-hidden="true" viewBox="0 0 24 24">
          <path d="M8 7V3m8 4V3m-9 8h10M5 21h14a2 2 0 002-2V7a2 2 0 00-2-2H5a2 2 0 00-2 2v12a2 2 0 002 2z" />
        </svg>
        Schedule for later
      </button></li>
      <li><button>
        <svg aria-hidden="true" viewBox="0 0 24 24">
          <path d="M19 7l-.867 12.142A2 2 0 0116.138 21H7.862a2 2 0 01-1.995-1.858L5 7m5 4v6m4-6v6m1-10V4a1 1 0 00-1-1h-4a1 1 0 00-1 1v3M4 7h16" />
        </svg>
        Delete
      </button></li>
      <li><button>
        <svg aria-hidden="true" viewBox="0 0 24 24">
          <path d="M5 5a2 2 0 012-2h10a2 2 0 012 2v16l-7-3.5L5 21V5z" />
        </svg>
        Save draft
      </button></li>
    </ul>
  </span>
</div>

<div class="gui-split-button">
  <button>Squash</button>
  <span class="gui-popup-button" aria-haspopup="true" aria-expanded="false" title="Open for more actions">
    <svg aria-hidden="true" viewBox="0 0 20 20">
      <path d="M5.293 7.293a1 1 0 011.414 0L10 10.586l3.293-3.293a1 1 0 111.414 1.414l-4 4a1 1 0 01-1.414 0l-4-4a1 1 0 010-1.414z" />
    </svg>
    <ul class="gui-popup">
      <li><button>
        Create a merge commit
      </button></li>
      <li><button>
        Rebase
      </button></li>
    </ul>
  </span>
</div>

import $ from 'blingblingjs'
import {rovingIndex} from 'roving-ux'

const splitButtons = $('.gui-split-button')
const popupButtons = $('.gui-popup-button')

// popup activating roving index for it's buttons
popupButtons.forEach(element => 
  rovingIndex({
    element,
    target: 'button',
  }))

// support escape key
popupButtons.on('keyup', e => {
  if (e.code === 'Escape')
    e.target.blur()
})

popupButtons.on('focusin', e => {
  e.currentTarget.setAttribute('aria-expanded', true)
})

popupButtons.on('focusout', e => {
  e.currentTarget.setAttribute('aria-expanded', false)
})

// respond to any button interaction
splitButtons.on('click', event => {
  if (event.target.nodeName !== 'BUTTON') return
  console.info(event.target.innerText)
})

.gui-split-button {
  --theme:        hsl(220 75% 50%);
  --theme-hover:  hsl(220 75% 45%);
  --theme-active: hsl(220 75% 40%);
  --theme-text:   hsl(220 75% 25%);
  --theme-border: hsl(220 50% 75%);
  --ontheme:      hsl(220 90% 98%);
  --popupbg:      hsl(220 0% 100%);

  --border: 1px solid var(--theme-border);
  --radius: 6px;
  --in-speed: 500ms;
  --out-speed: 100ms;

  display: inline-flex;
  border-radius: var(--radius);
  background: var(--theme);
  color: var(--ontheme);
  fill: var(--ontheme);

  touch-action: manipulation;
  user-select: none;
  -webkit-tap-highlight-color: transparent;

  @media (--dark) {
    --theme:        hsl(220 50% 60%);
    --theme-hover:  hsl(220 50% 65%);
    --theme-active: hsl(220 75% 70%);
    --theme-text:   hsl(220 10% 85%);
    --theme-border: hsl(220 20% 70%);
    --ontheme:      hsl(220 90% 5%);
    --popupbg:      hsl(220 10% 30%);
  }

  & button {
    cursor: pointer;
    appearance: none;
    background: none;
    border: none;

    display: inline-flex;
    align-items: center;
    gap: 1ch;
    white-space: nowrap;

    font-family: inherit;
    font-size: inherit;
    font-weight: 500;

    padding-block: 1.25ch;
    padding-inline: 2.5ch;

    color: var(--ontheme);
    outline-color: var(--theme);
    outline-offset: -5px;

    &:is(:hover, :focus-visible) {
      background: var(--theme-hover);
      color: var(--ontheme);

      & > svg {
        stroke: currentColor;
        fill: none;
      }
    }

    &:active {
      background: var(--theme-active);
    }
  }

  & > button {
    border-radius: var(--radius) 0 0 var(--radius);

    @supports (border-start-start-radius: 1px) {
      border-end-start-radius: var(--radius);
      border-start-start-radius: var(--radius);
    }
  }

  @media (--light) {
    & > button,
    & button:is(:focus-visible, :hover) {
      text-shadow: 0 1px 0 var(--theme-active);
    }
    & > .gui-popup-button > svg,
    & button:is(:focus-visible, :hover) > svg {
      filter: drop-shadow(0 1px 0 var(--theme-active));
    }
  }
  
  & svg {
    inline-size: 2ch;
    box-sizing: content-box;
    stroke-linecap: round;
    stroke-linejoin: round;
    stroke-width: 2px;
  }
}

.gui-popup-button {
  inline-size: 4ch;
  cursor: pointer;
  position: relative;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  border-inline-start: var(--border);
  border-radius: 0 var(--radius) var(--radius) 0;

  @supports (border-start-start-radius: 1px) {
    border-inline-start: var(--border);
    border-start-end-radius: var(--radius);
    border-end-end-radius: var(--radius);
  }

  &:is(:hover,:focus-within) {
    background: var(--theme-hover);
  }

  /* fixes iOS trying to be helpful */
  &:focus {
    outline: none;
  }

  &:active {
    background: var(--theme-active);
  }
  
  &:focus-within {
    & > svg {
      transition-duration: var(--in-speed);
      transform: rotateZ(.5turn);
    }
    & > .gui-popup {
      transition-duration: var(--in-speed);
      opacity: 1;
      transform: translateY(0);
      pointer-events: auto;
    }
  }

  @media (--motionOK) {
    & > svg {
      transition: transform var(--out-speed) ease;
    }
    & > .gui-popup {
      transform: translateY(5px);

      transition: 
        opacity var(--out-speed) ease,
        transform var(--out-speed) ease;
    }
  }
}

.gui-popup {
  --shadow: 220 70% 15%;
  --shadow-strength: 1%;

  opacity: 0;
  pointer-events: none;

  position: absolute;
  inset-block-end: 80%;
  inset-inline-start: -1.5ch;
  
  list-style-type: none;
  background: var(--popupbg);
  color: var(--theme-text);
  padding-inline: 0;
  padding-block: .5ch;
  border-radius: var(--radius);
  overflow: hidden;
  display: flex;
  flex-direction: column;
  font-size: .9em;
  transition: opacity var(--out-speed) ease;

  box-shadow:
    0 -2px 5px 0 hsl(var(--shadow) / calc(var(--shadow-strength) + 5%)),
    0 1px 1px -2px hsl(var(--shadow) / calc(var(--shadow-strength) + 10%)),
    0 2px 2px -2px hsl(var(--shadow) / calc(var(--shadow-strength) + 12%)),
    0 5px 5px -2px hsl(var(--shadow) / calc(var(--shadow-strength) + 13%)),
    0 9px 9px -2px hsl(var(--shadow) / calc(var(--shadow-strength) + 14%)),
    0 16px 16px -2px hsl(var(--shadow) / calc(var(--shadow-strength) + 20%))
  ;

  /* fixes iOS trying to be helpful */
  &:focus {outline: none}

  @media (--dark) {
    --shadow-strength: 5%;
    --shadow: 220 3% 2%;

    & button:not(:focus-visible, :hover) {
      text-shadow: 0 1px 0 var(--ontheme);
    }

    & button:not(:focus-visible, :hover) > svg {
      filter: drop-shadow(0 1px 0 var(--ontheme));
    }
  }

  @media (width <= 400px) {
    inset-inline-start: -200%;
  }

  & svg {
    fill: var(--popupbg);
    stroke: var(--theme);

    @media (prefers-color-scheme: dark) {
      stroke: var(--theme-border);
    }
  }

  & button {
    color: var(--theme-text);
    width: 100%;
  }
}

Open demo

Animations #

View the animation patterns landing page or check each out individually:

Here's a preview of the animated letters pattern:

<h1 split-by="letter" letter-animation="breath">
  animated letters
</h1>

const span = (text, index) => {
  const node = document.createElement('span')

  node.textContent = text
  node.style.setProperty('--index', index)
  
  return node
}

const byLetter = text =>
  [...text].map(span)

const {matches:motionOK} = window.matchMedia(
  '(prefers-reduced-motion: no-preference)'
)

if (motionOK) {
  const splitTargets = document.querySelectorAll('[split-by]')

  splitTargets.forEach(node => {
    let nodes = byLetter(node.innerText)

    if (nodes)
      node.firstChild.replaceWith(...nodes)
  })
}

@keyframes breath {
  from {
    animation-timing-function: ease-out;
  }

  to {
    transform: scale(1.25) translateY(-5px) perspective(1px);
    text-shadow: 0 0 40px var(--glow-color);
    animation-timing-function: ease-in-out;
  }
}

@media (prefers-reduced-motion:no-preference) {
  [letter-animation] > span {
    display: inline-block;
    white-space: break-spaces;
  }

  [letter-animation=breath] {
    --glow-color: white;
  }

  [letter-animation=breath]>span {
    animation: breath 1.2s ease calc(var(--index) * 100 * 1ms) infinite alternate;
  }
}

@media (prefers-reduced-motion:no-preference) and (prefers-color-scheme: light) {
  [letter-animation=breath] {
    --glow-color: black;
  }
}

Open demo

Theming #

View the theming patterns landing page or check each out individually:

One pattern is for building a client side theme switch so users can indicate their preference without it being directly tied to their system preference. The other is for creating a theming design system with CSS custom properties.

Here's a preview of the color schemes pattern:

<header>
  <h3>Scheme</h3>
  <form id="theme-switcher">
    <div>
      <input checked type="radio" id="auto" name="theme" value="auto">
      <label for="auto">Auto</label>
    </div>
    <div>
      <input type="radio" id="light" name="theme" value="light">
      <label for="light">Light</label>
    </div>
    <div>
      <input type="radio" id="dark" name="theme" value="dark">
      <label for="dark">Dark</label>
    </div>
    <div>
      <input type="radio" id="dim" name="theme" value="dim">
      <label for="dim">Dim</label>
    </div>
  </form>
</header>

<main>
  <section>
    <div class="surface-samples">
      <div class="surface1 rad-shadow">1</div>
      <div class="surface2 rad-shadow">2</div>
      <div class="surface3 rad-shadow">3</div>
      <div class="surface4 rad-shadow">4</div>
    </div>
  </section>

  <section>
    <div class="text-samples">
      <h1 class="text1">
        <span class="swatch brand rad-shadow"></span>
        Brand
      </h1>
      <h1 class="text1">
        <span class="swatch text1 rad-shadow"></span>
        Text Color 1
      </h1>
      <h1 class="text2">
        <span class="swatch text2 rad-shadow"></span>
        Text Color 2
      </h1>
      <br>
      <p class="text1">Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
      <p class="text2">Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
    </div>
  </section>
</main>

const switcher = document.querySelector('#theme-switcher')
const doc = document.firstElementChild

switcher.addEventListener('input', e =>
  setTheme(e.target.value))

const setTheme = theme =>
  doc.setAttribute('color-scheme', theme)

* {
  /* brand foundation */
  --brand-hue: 200;
  --brand-saturation: 100%;
  --brand-lightness: 50%;

  /* light */
  --brand-light: hsl(var(--brand-hue) var(--brand-saturation) var(--brand-lightness));
  --text1-light: hsl(var(--brand-hue) var(--brand-saturation) 10%);
  --text2-light: hsl(var(--brand-hue) 30% 30%);
  --surface1-light: hsl(var(--brand-hue) 25% 90%);
  --surface2-light: hsl(var(--brand-hue) 20% 99%);
  --surface3-light: hsl(var(--brand-hue) 20% 92%);
  --surface4-light: hsl(var(--brand-hue) 20% 85%);
  --surface-shadow-light: var(--brand-hue) 10% 20%;
  --shadow-strength-light: .02;

  /* dark */
  --brand-dark: hsl(
    var(--brand-hue)
    calc(var(--brand-saturation) / 2)
    calc(var(--brand-lightness) / 1.5)
  );
  --text1-dark: hsl(var(--brand-hue) 15% 85%);
  --text2-dark: hsl(var(--brand-hue) 5% 65%);
  --surface1-dark: hsl(var(--brand-hue) 10% 10%);
  --surface2-dark: hsl(var(--brand-hue) 10% 15%);
  --surface3-dark: hsl(var(--brand-hue) 5%  20%);
  --surface4-dark: hsl(var(--brand-hue) 5% 25%);
  --surface-shadow-dark: var(--brand-hue) 50% 3%;
  --shadow-strength-dark: .8;

  /* dim */
  --brand-dim: hsl(
    var(--brand-hue)
    calc(var(--brand-saturation) / 1.25)
    calc(var(--brand-lightness) / 1.25)
  );
  --text1-dim: hsl(var(--brand-hue) 15% 75%);
  --text2-dim: hsl(var(--brand-hue) 10% 61%);
  --surface1-dim: hsl(var(--brand-hue) 10% 20%);
  --surface2-dim: hsl(var(--brand-hue) 10% 25%);
  --surface3-dim: hsl(var(--brand-hue) 5%  30%);
  --surface4-dim: hsl(var(--brand-hue) 5% 35%);
  --surface-shadow-dim: var(--brand-hue) 30% 13%;
  --shadow-strength-dim: .2;
}

:root {
  color-scheme: light;

  /* set defaults */
  --brand: var(--brand-light);
  --text1: var(--text1-light);
  --text2: var(--text2-light);
  --surface1: var(--surface1-light);
  --surface2: var(--surface2-light);
  --surface3: var(--surface3-light);
  --surface4: var(--surface4-light);
  --surface-shadow: var(--surface-shadow-light);
  --shadow-strength: var(--shadow-strength-light);
}

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

    --brand: var(--brand-dark);
    --text1: var(--text1-dark);
    --text2: var(--text2-dark);
    --surface1: var(--surface1-dark);
    --surface2: var(--surface2-dark);
    --surface3: var(--surface3-dark);
    --surface4: var(--surface4-dark);
    --surface-shadow: var(--surface-shadow-dark);
    --shadow-strength: var(--shadow-strength-dark);
  }
}

[color-scheme="light"] {
  color-scheme: light;

  --brand: var(--brand-light);
  --text1: var(--text1-light);
  --text2: var(--text2-light);
  --surface1: var(--surface1-light);
  --surface2: var(--surface2-light);
  --surface3: var(--surface3-light);
  --surface4: var(--surface4-light);
  --surface-shadow: var(--surface-shadow-light);
  --shadow-strength: var(--shadow-strength-light);
}

[color-scheme="dark"] {
  color-scheme: dark;

  --brand: var(--brand-dark);
  --text1: var(--text1-dark);
  --text2: var(--text2-dark);
  --surface1: var(--surface1-dark);
  --surface2: var(--surface2-dark);
  --surface3: var(--surface3-dark);
  --surface4: var(--surface4-dark);
  --surface-shadow: var(--surface-shadow-dark);
  --shadow-strength: var(--shadow-strength-dark);
}

[color-scheme="dim"] {
  color-scheme: dark;

  --brand: var(--brand-dim);
  --text1: var(--text1-dim);
  --text2: var(--text2-dim);
  --surface1: var(--surface1-dim);
  --surface2: var(--surface2-dim);
  --surface3: var(--surface3-dim);
  --surface4: var(--surface4-dim);
  --surface-shadow: var(--surface-shadow-dim);
  --shadow-strength: var(--shadow-strength-dim);
}

/* READY TO USE! */
.brand {
  color: var(--brand);
  background-color: var(--brand);
}

.surface1 {
  background-color: var(--surface1);
  color: var(--text2);
}

.surface2 {
  background-color: var(--surface2);
  color: var(--text2);
}

.surface3 {
  background-color: var(--surface3);
  color: var(--text1);
}

.surface4 {
  background-color: var(--surface4);
  color: var(--text1);
}

.text1 {
  color: var(--text1);
}

p.text1 {
  font-weight: 200;
}

.text2 {
  color: var(--text2);
}

Open demo

New layout patterns on centering #

View the layout patterns landing page or check each out individually:

Each demo features a grab handle to resize the container and a button to add a child to the layout. These, as explained in the article, are to help you feel the strengths and weaknesses of various centering techniques the web offers. Plus, they have fun names.

Here is the article determined "winner" of the centering exploration, the Gentle Flex:

<article class="gentle-flex">
  <h1>Gentle Flex</h1>
</article>

.gentle-flex {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  gap: 1ch;
}

Open demo

Wrap up #

I hope these new patterns help teach you new techniques, inspire you, provide insights into accessibility and overall keep you hyped on building UI. Stay tuned for more patterns as the Chrome Team continues adding to these collections.

Post hero images generated from George Francis' fantastic Codepen

Building a button component

2022-05-18T00:00:00Z

In this post I want to share my thoughts on how to build a color-adaptive, responsive, and accessible <button> element. Try the demo and view the source!

Buttons are interacted with via keyboard and mouse in the light and dark themes.

If you prefer video, here's a YouTube version of this post:

Overview #

Browser support

Chrome 1, Supported 1
Firefox 1, Supported 1
Edge 12, Supported 12
Safari ≤4, Supported ≤4

Source

The <button> element is built for user interaction. Its click event triggers from keyboard, mouse, touch, voice, and more, with smart rules about its timing. It also comes with some default styles in each browser, so you can use them directly without any customization. Use color-scheme to opt into browser-provided light and dark buttons too.

See the Pen Pen PoQqQaW by web-dot-dev on Codepen

There are also different types of buttons, each shown in the preceding Codepen embed. A <button> without a type will adapt to being within a <form>, changing to the submit type.

<!-- buttons -->
<button></button>
<button type="submit"></button>
<button type="button"></button>
<button type="reset"></button>

<!-- button state -->
<button disabled></button>

<!-- input buttons -->
<input type="button" />
<input type="file">

In this month's GUI Challenge, each button will get styles to help visually differentiate their intent. Reset buttons will have warning colors since they're destructive, and submit buttons will get blue accent text so they appear slightly more promoted than regular buttons.

Preview of the final set of all button types, shown in a form and not in a form, with nice additions for icon buttons and customized buttons

Buttons also have pseudo classes for CSS to use for styling. These classes provide CSS hooks into customizing the feel of the button: :hover for when a mouse is over the button, :active for when a mouse or keyboard is pressing, and :focus or :focus-visible for assisting in assistive technology styling.

button:hover {}
button:active {}
button:focus {}
button:focus-visible {}

Preview of the final set of all button types in the dark theme

Markup #

In addition to the button types provided by the HTML specification, I've added a button with an icon and a button with a custom class btn-custom.

<button>Default</button>
<input type="button" value="<input>"/>
<button>
  <svg viewBox="0 0 24 24" width="24" height="24" aria-hidden="true">
    <path d="..." />
  </svg>
  Icon
</button>
<button type="submit">Submit</button>
<button type="button">Type Button</button>
<button type="reset">Reset</button>
<button disabled>Disabled</button>
<button class="btn-custom">Custom</button>
<input type="file">

Then, for testing, each button is placed inside of a form. This way I can ensure styles are updated appropriately for the default button, which behaves as a submit button. I also switch the icon strategy, from inline SVG to a masked SVG, to ensure both work equally well.

<form>
  <button>Default</button>
  <input type="button" value="<input>"/>
  <button>Icon <span data-icon="cloud"></span></button>
  <button type="submit">Submit</button>
  <button type="button">Type Button</button>
  <button type="reset">Reset</button>
  <button disabled>Disabled</button>
  <button class="btn-custom btn-large" type="button">Large Custom</button>
  <input type="file">
</form>

The matrix of combinations is pretty overwhelming at this point. Between button types, pseudo-classes, and being in or out of a form, there are over 20 combinations of buttons. It’s a good thing CSS can help us articulate each of them clearly!

Accessibility #

Button elements are naturally accessible but there are a few common enhancements.

Hover and focus together #

I like to group :hover and :focus together with the :is() functional pseudo selector. This helps ensure my interfaces always consider keyboard and assistive technology styles.

button:is(:hover, :focus) {
  …
}

Try a demo!

Interactive focus ring #

I like to animate the focus ring for keyboard and assistive technology users. I accomplish this by animating the outline away from the button by 5px, but only when the button is not active. This creates an effect that makes the focus ring shrink back to the button size when pressed.

:where(button, input):where(:not(:active)):focus-visible {
  outline-offset: 5px;
}

Ensuring passing color contrast #

There are at least four different color combinations across light and dark that need consideration of color contrast: button, submit button, reset button, and disabled button. VisBug is used here to inspect and show all their scores at once:

Hiding icons from folks who can't see #

When creating an icon button, the icon should provide visual support to the button text. This also means the icon is not valuable to someone with sight loss. Fortunately the browser provides a way to hide items from screen-reader technology so people with sight loss aren't bothered with decorative button images:

<button>
  <svg … aria-hidden="true">...</svg>
  Icon Button
</button>

Chrome DevTools showing the accessibility tree for the button. The tree ignores the button image because it has aria-hidden set to true

Styles #

In this next section, I first establish a custom property system for managing the adaptive styles of the button. With those custom properties I can begin to select elements and customize their appearance.

An adaptive custom property strategy #

The custom property strategy used in this GUI Challenge is very similar to that used in building a color scheme. For an adaptive light and dark color system, a custom property for each theme is defined and named accordingly. Then a single custom property is used to hold the current value of the theme and is assigned to a CSS property. Later, the single custom property can be updated to a different value, then updating the button style.

button {
  --_bg-light: white;
  --_bg-dark: black;
  --_bg: var(--_bg-light);

  background-color: var(--_bg);
}

@media (prefers-color-scheme: dark) {
  button {
    --_bg: var(--_bg-dark);
  }
}

What I like is that the light and dark themes are declarative and clear. The indirection and abstraction are offloaded into the --_bg custom property, which is now the only "reactive" property; --_bg-light and --_bg-dark are static. It's also clear to read that the light theme is the default theme and dark is only applied conditionally.

Preparing for design consistency #

The shared selector #

The following selector is used to target all the various types of buttons and is a bit overwhelming at first. :where() is used so customizing the button requires no specificity. Buttons are often adapted for alternative scenarios and the :where() selector ensures that task is easy. Inside :where(), each button type is selected, including the ::file-selector-button, which can't be used inside of :is() or :where().

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"],
  input[type="file"]
),
:where(input[type="file"])::file-selector-button {
  …
}

All the custom properties will be scoped inside this selector. Time to review all the custom properties! There are quite a few custom properties used in this button. I'll describe each group as we go, then share the dark and reduced motion contexts at the end of the section.

Button accent color #

Submit buttons and icons are a great place for a pop of color:

--_accent-light: hsl(210 100% 40%);
--_accent-dark: hsl(210 50% 70%);
--_accent: var(--_accent-light);

Button text color #

Button text colors aren't white or black, they're darkened or lightened versions of --_accent using hsl() and sticking to the hue 210:

--_text-light: hsl(210 10% 30%);
--_text-dark: hsl(210 5% 95%);
--_text: var(--_text-light);

Button background color #

Button backgrounds follow the same hsl() pattern except for the light theme buttons—those are set to white so their surface makes them appear close to the user, or in front of other surfaces:

--_bg-light: hsl(0 0% 100%);
--_bg-dark: hsl(210 9% 31%);
--_bg: var(--_bg-light);

Button background well #

This background color is for making a surface appear behind other surfaces, useful for the background of the file input:

--_input-well-light: hsl(210 16% 87%);
--_input-well-dark: hsl(204 10% 10%);
--_input-well: var(--_input-well-light);

Button padding #

The spacing around the text in the button is done using the ch unit, a relative length to the font size. This becomes critical when large buttons are able to simply bump up the font-size and button scales proportionally:

--_padding-inline: 1.75ch;
--_padding-block: .75ch;

Button border #

The button border radius is stashed into a custom property so the file input can match the other buttons. The border colors follow the established adaptive color system:

--_border-radius: .5ch;

--_border-light: hsl(210 14% 89%);
--_border-dark: var(--_bg-dark);
--_border: var(--_border-light);

Button hover highlight effect #

These properties establish a size property for transitioning on interaction, and the highlight color follows the adaptive color system. We'll cover how these interact later in this post, but ultimately these are used for a box-shadow effect:

--_highlight-size: 0;

--_highlight-light: hsl(210 10% 71% / 25%);
--_highlight-dark: hsl(210 10% 5% / 25%);
--_highlight: var(--_highlight-light);

Button text shadow #

Each button has a subtle text shadow style. This helps the text sit on top of the button, improving legibility and adding a nice layer of presentation polish.

--_ink-shadow-light: 0 1px 0 var(--_border-light);
--_ink-shadow-dark: 0 1px 0 hsl(210 11% 15%);
--_ink-shadow: var(--_ink-shadow-light);

Button icon #

Icons are the size of two characters thanks to the relative length ch unit again, which will help the icon scale proportionally to the button text. The icon color leans on the --_accent-color for an adaptive and within-theme color.

--_icon-size: 2ch;
--_icon-color: var(--_accent);

Button shadow #

For shadows to properly adapt to light and dark, they need to both shift their color and opacity. Light theme shadows are best when they are subtle and tinted towards the surface color they overlay. Dark theme shadows need to be darker and more saturated so they can overlay darker surface colors.

--_shadow-color-light: 220 3% 15%;
--_shadow-color-dark: 220 40% 2%;
--_shadow-color: var(--_shadow-color-light);

--_shadow-strength-light: 1%;
--_shadow-strength-dark: 25%;
--_shadow-strength: var(--_shadow-strength-light);

With adaptive colors and strengths I can assemble two depths of shadows:

--_shadow-1: 0 1px 2px -1px hsl(var(--_shadow-color)/calc(var(--_shadow-strength) + 9%));

--_shadow-2: 
  0 3px 5px -2px hsl(var(--_shadow-color)/calc(var(--_shadow-strength) + 3%)),
  0 7px 14px -5px hsl(var(--_shadow-color)/calc(var(--_shadow-strength) + 5%));

Furthermore, to give the buttons a slightly 3D appearance, a 1px box-shadow creates the illusion:

--_shadow-depth-light: 0 1px var(--_border-light);
--_shadow-depth-dark: 0 1px var(--_bg-dark);
--_shadow-depth: var(--_shadow-depth-light);

Button transitions #

Following the pattern for adaptive colors, I create two static properties to hold the design system options:

--_transition-motion-reduce: ;
--_transition-motion-ok:
  box-shadow 145ms ease,
  outline-offset 145ms ease
;
--_transition: var(--_transition-motion-reduce);

All properties together in the selector #

All custom properties in a selector

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"],
  input[type="file"]
),
:where(input[type="file"])::file-selector-button {
  --_accent-light: hsl(210 100% 40%);
  --_accent-dark: hsl(210 50% 70%);
  --_accent: var(--_accent-light);

  --_text-light: hsl(210 10% 30%);
  --_text-dark: hsl(210 5% 95%);
  --_text: var(--_text-light);
  
  --_bg-light: hsl(0 0% 100%);
  --_bg-dark: hsl(210 9% 31%);
  --_bg: var(--_bg-light);

  --_input-well-light: hsl(210 16% 87%);
  --_input-well-dark: hsl(204 10% 10%);
  --_input-well: var(--_input-well-light);

  --_padding-inline: 1.75ch;
  --_padding-block: .75ch;
  
  --_border-radius: .5ch;
  --_border-light: hsl(210 14% 89%);
  --_border-dark: var(--_bg-dark);
  --_border: var(--_border-light);
  
  --_highlight-size: 0;
  --_highlight-light: hsl(210 10% 71% / 25%);
  --_highlight-dark: hsl(210 10% 5% / 25%);
  --_highlight: var(--_highlight-light);
  
  --_ink-shadow-light: 0 1px 0 hsl(210 14% 89%);
  --_ink-shadow-dark: 0 1px 0 hsl(210 11% 15%);
  --_ink-shadow: var(--_ink-shadow-light);
  
  --_icon-size: 2ch;
  --_icon-color-light: var(--_accent-light);
  --_icon-color-dark: var(--_accent-dark);
  --_icon-color: var(--accent, var(--_icon-color-light));

  --_shadow-color-light: 220 3% 15%;
  --_shadow-color-dark: 220 40% 2%;
  --_shadow-color: var(--_shadow-color-light);
  --_shadow-strength-light: 1%;
  --_shadow-strength-dark: 25%;
  --_shadow-strength: var(--_shadow-strength-light);
  --_shadow-1: 0 1px 2px -1px hsl(var(--_shadow-color)/calc(var(--_shadow-strength) + 9%));
  --_shadow-2: 
    0 3px 5px -2px hsl(var(--_shadow-color)/calc(var(--_shadow-strength) + 3%)),
    0 7px 14px -5px hsl(var(--_shadow-color)/calc(var(--_shadow-strength) + 5%))
  ;
  
  --_shadow-depth-light: hsl(210 14% 89%);
  --_shadow-depth-dark: var(--_bg-dark);
  --_shadow-depth: var(--_shadow-depth-light);

  --_transition-motion-reduce: ;
  --_transition-motion-ok:
    box-shadow 145ms ease,
    outline-offset 145ms ease
  ;
  --_transition: var(--_transition-motion-reduce);
}

Dark theme adaptations #

The value of the -light and -dark static props pattern becomes clear when the dark theme props are set:

@media (prefers-color-scheme: dark) {
  :where(
    button,
    input[type="button"],
    input[type="submit"],
    input[type="reset"],
    input[type="file"]
  ),
  :where(input[type="file"])::file-selector-button {
    --_bg: var(--_bg-dark);
    --_text: var(--_text-dark);
    --_border: var(--_border-dark);
    --_accent: var(--_accent-dark);
    --_highlight: var(--_highlight-dark);
    --_input-well: var(--_input-well-dark);
    --_ink-shadow: var(--_ink-shadow-dark);
    --_shadow-depth: var(--_shadow-depth-dark);
    --_shadow-color: var(--_shadow-color-dark);
    --_shadow-strength: var(--_shadow-strength-dark);
  }
}

Not only does this read well, but consumers of these custom buttons can use the bare props with confidence that they'll adapt appropriately to user preferences.

Reduced motion adaptations #

If motion is OK with this visiting user, assign --_transition to var(--_transition-motion-ok):

@media (prefers-reduced-motion: no-preference) {
  :where(
    button,
    input[type="button"],
    input[type="submit"],
    input[type="reset"],
    input[type="file"]
  ),
  :where(input[type="file"])::file-selector-button {
    --_transition: var(--_transition-motion-ok);
  }
}

A few shared styles #

Buttons and inputs need to have their fonts set to inherit so they match the rest of the page fonts; otherwise they'll be styled by the browser. This also applies to letter-spacing. Setting line-height to 1.5 sets the letter box size to give the text some space above and below:

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"],
  input[type="file"]
),
:where(input[type="file"])::file-selector-button {
  /* …CSS variables */

  font: inherit;
  letter-spacing: inherit;
  line-height: 1.5;
  border-radius: var(--_border-radius);
}

Styling buttons #

Selector adjustment #

The selector input[type="file"] is not the button part of the input, the pseudo-element ::file-selector-button is, so I've removed input[type="file"] from the list:

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"],
  input[type="file"]
),
:where(input[type="file"])::file-selector-button {
  
}

Cursor and touch adjustments #

First I style the cursor to the pointer style, which helps the button indicate to mouse users that it's interactive. Then I add touch-action: manipulation to make clicks not need to wait and observe a potential double click, making the buttons feel faster:

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"]
),
:where(input[type="file"])::file-selector-button {
  cursor: pointer;
  touch-action: manipulation;
}

Colors and borders #

Next I customize the font size, background, text, and border colors, using some of the adaptive custom properties established earlier:

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"]
),
:where(input[type="file"])::file-selector-button {
  …

  font-size: var(--_size, 1rem);
  font-weight: 700;
  background: var(--_bg);
  color: var(--_text);
  border: 2px solid var(--_border);
}

Shadows #

The buttons have some great techniques applied. The text-shadow is adaptive to light and dark, creating a pleasing subtle appearance of the button text sitting nicely on top of the background. For the box-shadow, three shadows are assigned. The first, --_shadow-2, is a regular box shadow. The second shadow is a trick to the eye that makes the button appear to be beveled up a little bit. The last shadow is for the hover highlight, initially at a size of 0, but it will be given a size later and transitioned so it appears to grow from the button.

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"]
),
:where(input[type="file"])::file-selector-button {
  …

  box-shadow: 
    var(--_shadow-2),
    var(--_shadow-depth),
    0 0 0 var(--_highlight-size) var(--_highlight)
  ;
  text-shadow: var(--_ink-shadow);
}

Layout #

I gave the button a flexbox layout, specifically an inline-flex layout that will fit its content. I then center the text, and vertically and horizontally align children to the center. This will help icons and other button elements to align properly.

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"]
),
:where(input[type="file"])::file-selector-button {
  …

  display: inline-flex;
  justify-content: center;
  align-items: center;
  text-align: center;
}

Spacing #

For button spacing, I used gap to keep siblings from touching and logical properties for padding so button spacing works for all text layouts.

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"]
),
:where(input[type="file"])::file-selector-button {
  …

  gap: 1ch;
  padding-block: var(--_padding-block);
  padding-inline: var(--_padding-inline);
}

Touch and mouse UX #

This next section is mostly for touch users on mobile devices. The first property, user-select, is for all users; it prevents text highlighting the button text. This is mostly noticeable on touch devices when a button is tapped and held and the operating system highlights the text of the button.

I've generally found this is not the user experience with buttons in built-in apps, so I disable it by setting user-select to none. Tap highlight colors (-webkit-tap-highlight-color) and operating system context menus (-webkit-touch-callout) are other very web-centric button features that aren't aligned with general button user expectations, so I remove them as well.

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"]
),
:where(input[type="file"])::file-selector-button {
  …

  user-select: none;
  -webkit-tap-highlight-color: transparent;
  -webkit-touch-callout: none;
}

Transitions #

The adaptive --_transition variable is assigned to the transition property:

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"]
),
:where(input[type="file"])::file-selector-button {
  …

  transition: var(--_transition);
}

Upon hover, while the user is not actively pressing, adjust the shadow highlight size to give it a nice focus appearance that appears to grow from within the button:

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"]
):where(:not(:active):hover) {
  --_highlight-size: .5rem;
}

Upon focus, increase the focus outline offset from the button, also giving it a nice focus appearance that appears to grow from within the button:

:where(button, input):where(:not(:active)):focus-visible {
  outline-offset: 5px;
}

Icons #

For handling icons, the selector has an added :where() selector for direct SVG children or elements with the custom attribute data-icon. The icon size is set with the custom property using inline and block logical properties. Stroke color is set, as well as a drop-shadow to match the text-shadow. flex-shrink is set to 0 so the icon is never squished. Lastly, I select lined icons and I assign those styles here with fill: none and round line caps and line joins:

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"]
) > :where(svg, [data-icon]) {
  block-size: var(--_icon-size);
  inline-size: var(--_icon-size);
  stroke: var(--_icon-color);
  filter: drop-shadow(var(--_ink-shadow));

  flex-shrink: 0;
  fill: none;
  stroke-linecap: round;
  stroke-linejoin: round;
}

Customizing submit buttons #

I wanted submit buttons to have a slightly promoted appearance, and I achieved this by making the text color of the buttons the accent color:

:where(
  [type="submit"], 
  form button:not([type],[disabled])
) {
  --_text: var(--_accent);
}

Customize reset buttons #

I wanted reset buttons to have some built-in warning signs to alert users of their potentially destructive behavior. I also chose to style the light theme button with more red accents than the dark theme. The customization is done by changing the appropriate light or dark underlying color, and the button will update the style:

:where([type="reset"]) {
  --_border-light: hsl(0 100% 83%);
  --_highlight-light: hsl(0 100% 89% / 20%);
  --_text-light: hsl(0 80% 50%);
  --_text-dark: hsl(0 100% 89%);
}

I also thought it'd be nice for the focus outline color to match the accent of red. The text color adapts a dark red to a light red. I make the outline color match this with the keyword currentColor:

:where([type="reset"]):focus-visible {
  outline-color: currentColor;
}

Customize disabled buttons #

It's all too common for disabled buttons to have poor color contrast during the attempt to subdue the disabled button so it appears less active. I tested each color set and made sure they passed, nudging the HSL lightness value until the score passed in DevTools or VisBug.

:where(
  button,
  input[type="button"],
  input[type="submit"],
  input[type="reset"]
)[disabled] {
  --_bg: none;
  --_text-light: hsl(210 7% 40%);
  --_text-dark: hsl(210 11% 71%);

  cursor: not-allowed;
  box-shadow: var(--_shadow-1);
}

Customizing file input buttons #

The file input button is a container for a span and a button. CSS is able to style the input container a little bit, as well as the nested button, but not the span. The container is given max-inline-size so it won't grow larger than it needs to, while inline-size: 100% will allow itself to shrink and fit containers smaller than it is. The background color is set to an adaptive color that is darker than other surfaces, so it looks behind the file selector button.

:where(input[type="file"]) {
  inline-size: 100%;
  max-inline-size: max-content;
  background-color: var(--_input-well);
}

The file selector button and input type buttons are specifically given appearance: none to remove any browser-provided styles that weren't overwritten by the other button styles.

:where(input[type="button"]),
:where(input[type="file"])::file-selector-button {
  appearance: none;
}

Lastly, margin is added to the inline-end of the button to push the span text away from the button, creating some space.

:where(input[type="file"])::file-selector-button {
  margin-inline-end: var(--_padding-inline);
}

Special dark theme exceptions #

I gave the primary action buttons a darker background for higher contrasting text, giving them a slightly more promoted appearance.

@media (prefers-color-scheme: dark) {
  :where(
    [type="submit"],
    [type="reset"],
    [disabled],
    form button:not([type="button"])
  ) {
    --_bg: var(--_input-well);
  }
}

Creating variants #

For fun, and because it's practical, I chose to show how to create a few variants. One variant is very vibrant, similar to how primary buttons often look. Another variant is large. The last variant has a gradient-filled icon.

Vibrant button #

To achieve this button style, I overwrote the base props directly with blue colors. While this was quick and easy, it removes the adaptive props and looks the same in both light and dark themes.

.btn-custom {
  --_bg: linear-gradient(hsl(228 94% 67%), hsl(228 81% 59%));
  --_border: hsl(228 89% 63%);
  --_text: hsl(228 89% 100%);
  --_ink-shadow: 0 1px 0 hsl(228 57% 50%);
  --_highlight: hsl(228 94% 67% / 20%);
}

Large button #

This style of button is achieved by modifying the --_size custom property. Padding and other space elements are relative to this size, scaling along proportionally with the new size.

.btn-large {
  --_size: 1.5rem;
}

Icon button #

This icon effect doesn't have anything to do with our button styles, but it does show how to achieve it with just a few CSS properties, and how well the button handles icons that aren't inline SVG.

[data-icon="cloud"] {
  --icon-cloud: url("https://api.iconify.design/mdi:apple-icloud.svg") center / contain no-repeat;

  -webkit-mask: var(--icon-cloud);
  mask: var(--icon-cloud);
  background: linear-gradient(to bottom, var(--_accent-dark), var(--_accent-light));
}

Conclusion #

Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web.

Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Nothing to see here yet.

Resources #

Source code on Github

State of CSS 2022

2022-05-11T00:00:00Z

The year 2022 is set to be one of CSS's greatest years, in both features and cooperative browser feature releases, with a collaborative goal to implement 14 features!

Overview #

This post is the article form of the talk given at Google IO 2022. It's not meant to be an in-depth guide on each feature, rather an introduction and brief overview to pique your interest, providing breadth instead of depth. If your interest is piqued, check the end of a section for resource links to more information.

Table of contents #

Use the list below to jump to topics of interest:

Fresh in 2022	2022 and beyond
2022 Browser compatibility	@scope
@layer	@nest
subgrid	@media (prefers-reduced-data)
@container	@custom-media
hwb()	Media query ranges
lch, oklch, lab, oklab, display-p3, etc	@property
color-mix()	scroll-start
color-contrast()	:snap-target
Relative color syntax	snapChanging() and snapChanged()
Gradient color spaces	toggle()
accent-color	anchor()
inert	<selectmenu>
Color fonts v1
Viewport unit variants
:has()

Browser compatibility #

A primary reason so many CSS features are set to cooperatively release is due to the efforts of Interop 2022. Before studying the Interop efforts, it's important to look at Compat 2021’s efforts.

Compat 2021 #

The goals for 2021, driven by developer feedback via surveys, were to stabilize current features, improve the test suite and increase passing scores of browsers for five features:

sticky positioning
aspect-ratio sizing
flex layout
grid layout
transform positioning and animation

Test scores were raised across the board, demonstrating upgraded stability and reliability. Big congratulations to the teams here!

Interop 2022 #

This year, browsers met together to discuss the features and priorities they intended to work on, uniting their efforts. They planned to deliver the following web features for developers:

@layer
Color spaces and functions
Containment
<dialog>
Form compatibility
Scrolling
Subgrid
Typography
Viewport units
Web compat

This is an exciting and ambitious list that I can't wait to see unfold.

Fresh for 2022 #

Unsurprisingly, the state of CSS 2022 is dramatically impacted by the Interop 2022 work.

Cascade layers #

Browser support

Chrome 99, Supported 99
Firefox 97, Supported 97
Edge 99, Supported 99
Safari 15.4, Supported 15.4

Source

Before @layer, the discovered order of loaded stylesheets was very important, as styles loaded last can overwrite previously loaded styles. This led to meticulously managed entry stylesheets, where developers needed to load less important styles first and more important styles later. Entire methodologies exist to assist developers in managing this importance, such as ITCSS.

With @layer, the entry file can pre-define layers, and their order, ahead of time. Then, as styles load, are loaded or defined, they can be placed within a layer, allowing a preservation of style override importance but without the meticulously managed loading orchestration.

The video shows how the defined cascade layers allow for a more liberated and freestyle authoring and loading process, while still maintaining the cascade as needed.

Chrome DevTools is helpful for visualizing which styles are coming from which layers:

Resources #

Subgrid #

Browser support

Chrome 114, Behind a flag
Firefox 71, Supported 71
Edge 114, Behind a flag
Safari 16, Supported 16

Source

Before subgrid, a grid inside of another grid couldn't align itself to its parent cells or grid lines. Each grid layout was unique. Many designers place a single grid over their whole design and constantly align items within it, which couldn't be done in CSS.

After subgrid, a child of a grid can adopt its parents’ columns or rows as its own, and align itself or children to them!

In the following demo, the body element creates a classic grid of three columns: the middle column is called main, and the left and right columns name their lines fullbleed. Then, each element in the body, <nav> and <main>, adopts the named lines from body by setting grid-template-columns: subgrid.

body {
  display: grid;
  grid-template-columns:
    [fullbleed-start]
    auto [main-start] min(90%, 60ch) [main-end] auto
    [fullbleed-end]
  ;
}

body > * {
  display: grid;
  grid-template-columns: subgrid;
}

Lastly, children of <nav> or <main> can align or size themselves using the fullbleed and main columns and lines.

.main-content {
  grid-column: main;
}

.fullbleed {
  grid-column: fullbleed;
}

See the Pen Pen JjMQzVV by web-dot-dev on Codepen

Devtools can help you see the lines and subgrids (Firefox only at the moment). In the following image, the parent grid and subgrids have been overlaid. It now resembles how designers were thinking about the layout.

In the elements panel of devtools you can see which elements are grids and subgrids, which is very helpful for debugging or validating layout.

Screenshot from Firefox Devtools

Resources #

Container queries #

Browser support

Chrome 105, Supported 105
Firefox 110, Supported 110
Edge 105, Supported 105
Safari 16, Supported 16

Source

Before @container, elements of a webpage could only respond to the size of the whole viewport. This is great for macro layouts, but for micro layouts, where their outer container isn't the whole viewport, it's impossible for the layout to adjust accordingly.

After @container, elements can respond to a parent container size or style! The only caveat is the containers must declare themselves as possible query targets, which is a small requirement for a large benefit.

/* establish a container */
.day {
  container-type: inline-size;
  container-name: calendar-day;
}

These styles are what make the Mon, Tues, Wed, Thurs, and Fri columns in the following video able to be queried by the event elements.

Demo by Una Kravets

Here is the CSS for querying the calendar-day container for its size, then adjusting a layout and font sizes:

@container calendar-day (max-width: 200px) {
  .date {
    display: block;
  }

  .date-num {
    font-size: 2.5rem;
    display: block;
  }
}

Here's another example: one book component adapts itself to the space available in the column that it's dragged to:

Demo by Max Böck

Una is correct in assessing the situation as the new responsive. There are many exciting and meaningful design decisions to make when using @container.

Resources #

`accent-color` #

Browser support

Chrome 93, Supported 93
Firefox 92, Supported 92
Edge 93, Supported 93
Safari 15.4, Supported 15.4

Source

Before accent-color, when you wanted a form with brand matching colors, you could end up with complex libraries or CSS solutions that became hard to manage over time. While they gave you all the options, and hopefully included accessibility, the choice to use the built-in components or adopt your own becomes tedious to continue to choose.

After accent-color, one line of CSS brings a brand color to the built-in components. In addition to a tint, the browser intelligently chooses proper contrasting colors for ancillary parts of the component and adapts to system color schemes (light or dark).

/* tint everything */
:root {
  accent-color: hotpink;
}

/* tint one element */
progress {
  accent-color: indigo;
}

To learn more about accent-color, check out my post on web.dev where I explore many more aspects of this useful CSS property.

Resources #

Color level 4 and 5 #

The web has been dominated by sRGB for the past decades, but in an expanding digital world of high-definition displays and mobile devices pre-equipped with OLED or QLED screens, sRGB is not enough. Furthermore, dynamic pages that adapt to user preferences are expected, and color management has been a growing concern for designers, design systems, and code maintainers.

Not in 2022 though—CSS has a number of new color functions and spaces:

Colors that reach into the HD color capabilities of displays.
Color spaces that match an intent, such as perceptual uniformity.
Color spaces for gradients that drastically change the interpolation outcomes.
Color functions to help you mix and contrast, and choose which space you do the work in.

Before all these color features, design systems needed to precalculate proper contrasting colors, and ensure appropriately vibrant palettes, all while preprocessors or JavaScript did the heavy lifting.

After all these color features, the browser and CSS can do all the work, dynamically and just in time. Instead of sending many KBs of CSS and JavaScript to users to enable theming and data visualization colors, CSS can do the orchestrating and calculations. CSS is also better equipped to check for support before usage or handle fallbacks gracefully.

@media (dynamic-range: high) {
  .neon-pink {
    --neon-glow: color(display-p3 1 0 1);
  }
}

@supports (color: lab(0% 0 0)) {
  .neon-pink {
    --neon-glow: lab(150% 160 0);
  }
}

`hwb()` #

Browser support

Chrome 101, Supported 101
Firefox 96, Supported 96
Edge 101, Supported 101
Safari 15, Supported 15

Source

HWB stands for hue, whiteness, and blackness. It presents itself as a human-friendly way of articulating color, as it's just a hue and an amount of white or black to lighten or darken. Artists who mix colors with white or black may find themselves appreciating this color syntax addition.

See the Pen Pen KKZdeep by web-dot-dev on Codepen

Using this color function results in colors from the sRGB color space, the same as HSL and RGB. In terms of newness for 2022, this doesn’t give you new colors, but it may make some tasks easier for fans of the syntax and mental model.

Resources #

Color spaces #

The way colors are represented is done with a color space. Each color space offers various features and trade-offs for working with color. Some may pack all the bright colors together; some may line them up first based on their lightness.

2022 CSS is set to offer 10 new color spaces, each with unique features to assist designers and developers in displaying, picking, and mixing colors. Previously, sRGB was the only option for working with color, but now CSS unlocks new potential and a new default color space, LCH.

`color-mix()` #

Browser support

Chrome 111, Supported 111
Firefox 113, Supported 113
Edge 111, Supported 111
Safari 16.2, Supported 16.2

Source

Before color-mix(), developers and designers needed preprocessors like Sass to mix the colors before the browser saw them. Most color-mixing functions also didn't provide the option to specify which color space to do the mixing in, sometimes resulting in confusing results.

After color-mix(), developers and designers can mix colors in the browser, alongside all their other styles, without running build processes or including JavaScript. Additionally, they can specify which color space to do the mixing in, or use the default mixing color space of LCH.

Often, a brand color is used as a base and variants are created from it, such as lighter or darker colors for hover styles. Here's what that looks like with color-mix():

.color-mix-example {
  --brand: #0af;

  --darker: color-mix(var(--brand) 25%, black);
  --lighter: color-mix(var(--brand) 25%, white);
}

and if you wanted to mix those colors in a different color space, like srgb, change it:

.color-mix-example {
  --brand: #0af;

  --darker: color-mix(in srgb, var(--brand) 25%, black);
  --lighter: color-mix(in srgb, var(--brand) 25%, white);
}

Here follows a theming demo using color-mix(). Try changing the brand color and watch the theme update:

See the Pen Pen yLpYqVb by web-dot-dev on Codepen

Enjoy mixing colors in various color spaces in your stylesheets in 2022!

Resources #

`color-contrast()` #

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari 15, Behind a flag

Source

Before color-contrast(), stylesheet authors needed to know accessible colors ahead of time. Often a palette would show black or white text on a color swatch, to indicate to a user of the color system which text color would be needed to properly contrast with that swatch.

Example from 2014 Material Design color palettes

After color-contrast(), stylesheet authors can offload the task entirely to the browser. Not only can you employ the browser to automatically pick a black or white color, you can give it a list of design system appropriate colors and have it pick the first to pass your desired contrast ratio.

Here's a screenshot of an HWB color palette set demo where the text colors are automatically chosen by the browser based on the swatch color:

Try the demo

The basics of the syntax look like this, where gray is passed to the function and the browser determines if black or white have the most contrast:

color: color-contrast(gray);

The function can also be customized with a list of colors, from which it will pick the highest contrasting color from the selection:

color: color-contrast(gray vs indigo, rebeccapurple, hotpink);

Lastly, in case it's preferable not to pick the highest contrasting color from the list, a target contrast ratio can be provided, and the first color to pass it is chosen:

color: color-contrast(
  var(--bg-blue-1)
  vs
  var(--text-lightest), var(--text-light), var(--text-subdued)
  to AA /* 4.5 could also be passed */
);

This function can be used for more than just text color, though I estimate that will be its primary use case. Think about how much easier it will be to deliver accessible and legible interfaces once the choosing of proper contrasting colors is built into the CSS language itself.

Resources #

Relative color syntax #

Browser support

Chrome 111, Supported 111
Firefox 113, Supported 113
Edge 111, Supported 111
Safari 15, Supported 15

Source

Before relative color syntax, to compute on color and make adjustments, the color channels needed to be individually placed into custom properties. This limitation also made HSL the primary color function for manipulating colors because the hue, saturation, or lightness could all be adjusted in a straightforward way with calc().

After relative color syntax, any color in any space can be deconstructed, modified, and returned as a color, all in one line of CSS. No more limitations to HSL—manipulations can be done in any color space desired, and many less custom properties need to be created to facilitate it.

In the following syntax example, a base hex is provided and two new colors are created relative to it. The first color --absolute-change creates a new color in LCH from the base color, then proceeds to replace the base color’s lightness with 75%, maintaining the chroma (c) and hue (h). The second color --relative-change creates a new color in LCH from the base color, but this time reduces the chroma (c) by 20%.

.relative-color-syntax {
  --color: #0af;
  --absolute-change: lch(from var(--color) 75% c h);
  --relative-change: lch(from var(--color) l calc(c-20%) h);
}

It's akin to mixing colors, but it's more similar to alterations than it is mixing. You get to cast a color from another color, getting access to the three channel values as named by the color function used, with an opportunity to adjust those channels. All in all, this is a very cool and powerful syntax for color.

In the following demo I've used relative color syntax to create lighter and darker variants of a base color, and used color-contrast() to ensure the labels have proper contrast:

Try the demo

This function can also be used for color palette generation. Here is a demo where entire palettes are generated off a provided base color. This one set of CSS powers all the various palettes, each palette simply provides a different base. As a bonus, since I've used LCH, look at how perceptually even the palettes are—no hot or dead spots to be seen, thanks to this color space.

:root {
  --_color-base: #339af0;

  --color-0:  lch(from var(--_color-base) 98% 10 h);
  --color-1:  lch(from var(--_color-base) 93% 20 h);
  --color-2:  lch(from var(--_color-base) 85% 40 h);
  --color-3:  lch(from var(--_color-base) 75% 46 h);
  --color-4:  lch(from var(--_color-base) 66% 51 h);
  --color-5:  lch(from var(--_color-base) 61% 52 h);
  --color-6:  lch(from var(--_color-base) 55% 57 h);
  --color-7:  lch(from var(--_color-base) 49% 58 h);
  --color-8:  lch(from var(--_color-base) 43% 55 h);
  --color-9:  lch(from var(--_color-base) 39% 52 h);
  --color-10: lch(from var(--_color-base) 32% 48 h);
  --color-11: lch(from var(--_color-base) 25% 45 h);
  --color-12: lch(from var(--_color-base) 17% 40 h);
  --color-13: lch(from var(--_color-base) 10% 30 h);
  --color-14: lch(from var(--_color-base) 5% 20 h);
  --color-15: lch(from var(--_color-base) 1% 5 h);
}

Try the demo

Hopefully by now you can see how color spaces and different color functions can all be used for different purposes, based on their strengths and weaknesses.

Resources #

Gradient color spaces #

Before gradient color spaces, sRGB was the default color space used. sRGB is generally reliable, but does have some weaknesses like the gray dead zone.

After gradient color spaces, tell the browser which color space to use for the color interpolation. This gives developers and designers the ability to choose the gradient they prefer. The default color space also changes to LCH instead of sRGB.

The syntax addition goes after the gradient direction, uses the new in syntax, and is optional:

background-image: linear-gradient(
  to right in hsl,
  black, white
);

background-image: linear-gradient(
  to right in lch,
  black, white
);

Here's a basic and essential gradient from black to white. Look at the range of results in each color space. Some reach dark black earlier than others, some fade to white too late.

In this next example, black is transitioned to blue because it's a known problem space for gradients. Most color spaces creep into purple during color interpolation or, as I like to think of it, as colors travel inside their color space from point A to point B. Since the gradient will take a straight line from point A to point B, the shape of the color space drastically changes the stops that the path takes along the way.

For more deep explorations, examples and comments, read this Twitter thread.

Resources #

`inert` #

Browser support

Chrome 102, Supported 102
Firefox 112, Supported 112
Edge 102, Supported 102
Safari 15.5, Supported 15.5

Source

Before inert, it was good practice to guide the user's focus to areas of the page or app that needed immediate attention. This guided focus strategy became known as focus trapping because developers would place focus into an interactive space, listen for focus change events and, if the focus left the interactive space, then it was forced back in. Users on keyboards or screen readers are guided back to the interactive space to ensure the task is complete before moving on.

After inert, no trapping is required because you can freeze or guard entire sections of the page or app. Clicks and focus change attempts are just simply not available while those parts of a document are inert. One could also think of this like guards instead of a trap, where inert is not interested in making you stay somewhere, rather making other places unavailable.

A good example of this is the JavaScript alert() function:

Website is shown as interactive, then an alert() is called, and the page is no longer active.

Notice in the preceding video how the page was mouse and keyboard accessible until an alert() was called. Once the alert dialog popup was shown, the rest of the page was frozen, or inert. Users’ focus is placed inside the alert dialog and has nowhere else to go. Once the user interacts and completes the alert function request, the page is interactive again. inert empowers developers to achieve this same guided focus experience with ease.

Here's a small code sample to show how it works:

<body>
  <div class="modal">
    <h2>Modal Title</h2>
    <p>...<p>
    <button>Save</button>
    <button>Discard</button>
  </div>
  <main inert>
    <!-- cannot be keyboard focused or clicked -->
  </main>
</body>

A dialog is a great example, but inert is also helpful for things such as the slide-out side menu user experience. When a user slides out the side menu, it's not OK to let the mouse or keyboard interact with the page behind it; that's a bit tricky for users. Instead, when the side menu is showing, make the page inert, and now users must close or navigate within that side menu, and won't ever find themselves lost somewhere else in the page with an open menu.

Resources #

COLRv1 Fonts #

Before COLRv1 fonts, the web had OT-SVG fonts, also an open format for fonts with gradients and built-in colors and effects. These could grow very large though, and while they allowed editing the text, there wasn't much scope for customization.

After COLRv1 fonts, the web has smaller footprint, vector-scalable, repositionable, gradient-featuring, and blend-mode powered fonts that accept parameters to customize the font per use case or to match a brand.

Image sourced from https://developer.chrome.com/blog/colrv1-fonts/

Here's an example from the Chrome Developer blog post about emojis. Maybe you've noticed that if you scale up the font size on an emoji, it doesn't stay sharp. It's an image and not vector art. Often in applications when an emoji is used, it's swapped out for a higher quality asset. With COLRv1 fonts, the emojis are vector and beautiful:

Icon fonts could do some amazing things with this format, offering custom duo-tone color palettes, and more. Loading a COLRv1 font is just like any other font file:

@import url(https://fonts.googleapis.com/css2?family=Bungee+Spice);

Customizing the COLRv1 font is done with @font-palette-values, a special CSS at-rule for grouping and naming a set of customization options into a bundle for later reference. Notice how you specify a custom name just like a custom property, starting with --:

@import url(https://fonts.googleapis.com/css2?family=Bungee+Spice);

@font-palette-values --colorized {
  font-family: "Bungee Spice";
  base-palette: 0;
  override-colors: 0 hotpink, 1 cyan, 2 white;
}

With --colorized as an alias for the customizations, the last step is to apply the palette to an element that is using the color font family:

@import url(https://fonts.googleapis.com/css2?family=Bungee+Spice);

@font-palette-values --colorized {
  font-family: "Bungee Spice";
  base-palette: 0;
  override-colors: 0 hotpink, 1 cyan, 2 white;
}

.spicy {
  font-family: "Bungee Spice";
  font-palette: --colorized;
}

Bungee Spice font shown with custom colors, source from https://developer.chrome.com/blog/colrv1-fonts/

With more and more variable fonts and color fonts becoming available, web typography is on a very magnificent path towards rich customization and creative expression.

Resources #

Viewport units #

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Before the new viewport variants, the web offered physical units to assist in fitting viewports. There was one for height, width, smallest size (vmin), and largest side (vmax). These worked well for many things, but mobile browsers introduced a complexity.

On mobile, when loading a page, the status bar with the url is shown, and this bar consumes some of the viewport space. After a few seconds and some interactivity, the status bar may slide away to allow a bigger viewport experience for the user. But when that bar slides out, the viewport height has changed, and any vh units would shift and resize as their target size changed. In later years, the vh unit specifically needed to decide which of the two viewport sizes it was going to use, because it was causing jarring visual layout issues on mobile devices. It was determined that the vh would always represent the largest viewport.

.original-viewport-units {
  height: 100vh;
  width: 100vw;
  --size: 100vmin;
  --size: 100vmax;
}

After the new viewport variants, small, large, and dynamic viewport units are made available, with the addition of logical equivalents to the physical ones. The idea is to give developers and designers the ability to choose which unit they want to use for their given scenario. Maybe it's ok to have a small jarring layout shift when the status bar goes away, so then dvh (dynamic viewport height) could be used without worry.

Here's a complete list of all the new viewport unit options made available with the new viewport variants:

Height viewport units

.new-height-viewport-units {
  height: 100vh;
  height: 100dvh;
  height: 100svh;
  height: 100lvh;
  block-size: 100vb;
  block-size: 100dvb;
  block-size: 100svb;
  block-size: 100lvb;
}

Width viewport units

.new-width-viewport-units {
  width: 100vw;
  width: 100dvw;
  width: 100svw;
  width: 100lvw;
  inline-size: 100vi;
  inline-size: 100dvi;
  inline-size: 100svi;
  inline-size: 100lvi;
}

Smallest viewport side units

.new-min-viewport-units {
  --size: 100vmin;
  --size: 100dvmin;
  --size: 100svmin;
  --size: 100lvmin;
}

Largest viewport side units

.new-max-viewport-units {
  --size: 100vmax;
  --size: 100dvmax;
  --size: 100svmax;
  --size: 100lvmax;
}

Hopefully these will give developers and designers the flexibility needed to achieve their viewport responsive designs.

Resources #

`:has()` #

Browser support

Chrome 105, Supported 105
Firefox 103, Behind a flag
Edge 105, Supported 105
Safari 15.4, Supported 15.4

Source

Before :has(), the subject of a selector was always at the end. For example, the subject of this selector is a list item: ul > li. Pseudo selectors can alter the selector but they don't change the subject: ul > li:hover or ul > li:not(.selected).

After :has(), a subject higher in the element tree can remain the subject while providing a query about children: ul:has(> li). It is easy to understand how :has() got a common name of "parent selector", as the subject of the selector is now the parent in this case.

Here's a basic syntax example where the class .parent remains the subject but is only selected if a child element has the .child class:

.parent:has(.child) {...}

Here's an example where a <section> element is the subject, but the selector only matches if one of the children has :focus-visible:

section:has(*:focus-visible) {...}

The :has() selector starts to become a fantastic utility once more practical use cases become apparent. For example, it's not currently possible to select <a> tags when they wrap images, making it difficult to teach the anchor tag how to change its styles when in that use case. It is possible with :has() though:

a:has(> img) {...}

These have all been examples where :has() only looks like a parent selector. Consider the use case of images inside of <figure> elements and adjusting styles on the images if the figure has a <figcaption>. In the following example, figures with figcaptions are selected and then images within that context. :has() is used and doesn't change the subject, as the subject we're targeting is images not figures:

figure:has(figcaption) img {...}

The combinations are seemingly endless. Combine :has() with quantity queries and adjust CSS grid layouts based on the number of children. Combine :has() with interactive pseudo class states and create applications that respond in new creative ways.

Checking for support is made simple with @supports and its selector() function, which tests if the browser understands the syntax before using it:

@supports (selector(:has(works))) {
  /* safe to use :has() */
}

Resources #

2022 and beyond #

There are still a number of things that will be hard to do after all these amazing features land in 2022. The next section takes a look at some of the remaining problems and the solutions that are actively being developed to resolve them. These solutions are experimental, even though they may be specified or available behind flags in browsers.

The upshot from the next sections should be comfort that the problems listed have many people from many companies seeking resolution—not that these solutions are going to be released in 2023.

Loosely typed custom properties #

Browser support

Chrome 85, Supported 85
Firefox, Not supported
Edge 85, Supported 85
Safari 16.4, Supported 16.4

Source

CSS custom properties are amazing. They allow all sorts of things to be stored inside of a named variable, which then can be extended, calculated upon, shared, and more. In fact, they're so flexible, it would be nice to have some that are less flexible.

Consider a scenario where a box-shadow uses custom properties for its values:

box-shadow: var(--x) var(--y) var(--blur) var(--spread) var(--color);

This all works well until any one of the properties is changed into a value that CSS doesn't accept there, such as --x: red. The entire shadow breaks if any one of the nested variables is missing or is set to an invalid value type.

This is where @property comes in: --x can become a typed custom property, no longer loose and flexible, but safe with some defined boundaries:

@property --x {
  syntax: '<length>';
  initial-value: 0px;
  inherits: false;
}

Now, when the box-shadow uses var(--x) and later --x: red is attempted, red will be ignored as it's not a <length>. This means the shadow continues to work, even though an invalid value was given to one of its custom properties. Instead of failing, it reverts to its initial-value of 0px.

Animation #

In addition to type safety, it also opens up many doors for animation. The flexibility of CSS syntax makes animating some things impossible, such as gradients. @property helps here because the typed CSS property can inform the browser about a developer's intent inside of otherwise overly complex interpolation. It essentially limits the scope of possibility insomuch that a browser can animate aspects of a style that it couldn't before.

Consider this demo example, where a radial gradient is used to make a portion of an overlay, creating a spotlight focus effect. JavaScript sets the mouse x and y when the alt/opt key is pressed, and then changes the focal-size to a smaller value such as 25%, creating the spotlight focus circle at the mouse position:

Try the demo

.focus-effect {
  --focal-size: 100%;
  --mouse-x: center;
  --mouse-y: center;

  mask-image: radial-gradient(
    circle at var(--mouse-x) var(--mouse-y),
    transparent 0%,
    transparent var(--focal-size),
    black 0%
  );
}

Gradients can't be animated though. They are too flexible and too complex for the browser to "just derive" how you want them to animate. With @property, though, one property can be typed and animated in isolation, for which the browser can easily understand the intent.

Video games that use this focus effect always animate the circle, from a large circle to a pinhole circle. Here's how to use @property with our demo so the browser animates the gradient mask:

@property --focal-size {
  syntax: '<length-percentage>';
  initial-value: 100%;
  inherits: false;
}

.focus-effect {
  --focal-size: 100%;
  --mouse-x: center;
  --mouse-y: center;

  mask-image: radial-gradient(
    circle at var(--mouse-x) var(--mouse-y),
    transparent 0%,
    transparent var(--focal-size),
    black 0%
  );

  transition: --focal-size .3s ease;
}

Try the demo

The browser is now able to animate the gradient size because we've reduced the surface area of the modification to just one property and typed the value so the browser can intelligently interpolate the lengths.

@property can do so much more, but these small enablements can go a long way.

Resources #

Was in `min-width` or `max-width` #

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Before media query ranges, a CSS media query uses min-width and max-width to articulate over and under conditions. It may look like this:

@media (min-width: 320px) {
  …
}

After media query ranges, the same media query could look like this:

@media (width >= 320px) {
  …
}

A CSS media query using both min-width and max-width may look like this:

@media (min-width: 320px) and (max-width: 1280px) {
  …
}

After media query ranges, the same media query could look like this:

@media (320px <= width <= 1280px) {
  …
}

Depending on your coding background, one of those will look much more legible than the other. Thanks to the spec additions, developers will be able to choose which they prefer, or even use them interchangeably.

Resources #

No media query variables #

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Before @custom-media, media queries had to repeat themselves over and over, or rely on preprocessors to generate the proper output based on static variables during build time.

After @custom-media, CSS allows aliasing media queries and the referencing of them, just like a custom property.

Naming things is very important: it can align purpose with the syntax, making things easier to share and easier to use in teams. Here are a few custom media queries that follow me between projects:

@custom-media --OSdark  (prefers-color-scheme: dark);
@custom-media --OSlight (prefers-color-scheme: light);

@custom-media --pointer (hover) and (pointer: coarse);
@custom-media --mouse   (hover) and (pointer: fine);

@custom-media --xxs-and-above (width >= 240px);
@custom-media --xxs-and-below (width <= 240px);

Now that they're defined, I can use one of them like this:

@media (--OSdark) {
  :root {
    …
  }
}

Find a full list of custom media queries I use inside my CSS custom property library Open Props.

Resources #

Nesting selectors is so nice #

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Before @nest, there was a lot of repetition in stylesheets. It became especially unwieldy when selectors were long and each was targeting small differences. The convenience of nesting is one of the most common reasons for adopting a preprocessor.

After @nest, the repetition is gone. Nearly every feature of preprocessor-enabled nesting will be made available built into CSS.

article {
  color: darkgray;
}

article > a {
  color: var(--link-color);
}

/* with @nest becomes */

article {
  color: darkgray;

  & > a {
    color: var(--link-color);
  }
}

What's most important about nesting to me, besides not repeating article in the nested selector, is the styling context remains within one style block. Instead of bouncing from one selector, and its styles, to another selector with styles (example 1), the reader can remain within the context of an article and see the article owns links inside of it. The relationship and style intent are bundled together, so article gets to appear to own its own styles.

The ownership could also be thought of as centralization. Instead of looking around a stylesheet for relevant styles, they can all be found nested together within a context. This works with parent to child relationships, but also with child to parent relationships.

Consider a component child that wants to adjust itself when in a different parent context, as opposed to the parent owning the style and changing a child:

/* parent owns this, adjusting children */
section:focus-within > article {
  border: 1px solid hotpink;
}

/* with @nest becomes */

/* article owns this, adjusting itself when inside a section:focus-within */
article {
  @nest section:focus-within > & {
     border: 1px solid hotpink;
  }
}

@nest helps overall with healthier style organization, centralization, and ownership. Components can group and own their own styles, instead of having them spread amongst other style blocks. It may seem small in these examples, but it can have very large impacts, for both convenience and legibility.

Resources #

Scoping styles is really hard #

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Before @scope, many strategies existed because styles in CSS cascade, inherit, and are globally scoped by default. These features of CSS are very convenient for many things, but for complex sites and applications, with potentially many different styles of components, the global space and nature of the cascade can make styles feel like they're leaking.

After @scope, not only can styles be scoped to only within a context, like a class, they can also articulate where the styles end and do not continue to cascade or inherit.

In the following example, BEM naming convention scoping can be reversed into the actual intent. The BEM selector is attempting to scope the color of a header element to a .card container with naming conventions. This requires that the header has this classname on it, completing the goal. With @scope, no naming conventions are required in order to complete the same goal without marking up the header element:

.card__header {
  color: var(--text);
}

/* with @scope becomes */

@scope (.card) {
  header {
    color: var(--text);
  }
}

Here's another example, less component-specific and more about the global scope nature of CSS. Dark and light themes have to coexist inside a stylesheet, where order matters in determining a winning style. Usually this means dark theme styles come after the light theme; this establishes light as the default and dark as the optional style. Avoid the ordering and scope battling with @scope:

@scope (.light-theme) {
  a { color: purple; }
}

@scope (.dark-theme) {
  a { color: plum; }
}

To complete the story here, @scope also allows the establishing of where the style scope ends. This can't be done with any naming convention or preprocessor; it's special and only something CSS built-in to the browser can do. In the following example, img and .content styles are exclusively applied when a child of a .media-block is a sibling or parent of .content:

@scope (.media-block) to (.content) {
  img {
    border-radius: 50%;
  }

  .content {
    padding: 1em;
  }
}

Resources #

No CSS way for a masonry layout #

Before CSS masonry with grid, JavaScript was the best way to achieve a masonry layout, as any of the CSS methods with columns or flexbox would inaccurately represent the content order.

After CSS masonry with grid, no JavaScript libraries will be required and the content order will be correct.

Image and demo from Smashing Magazine
https://www.smashingmagazine.com/native-css-masonry-layout-css-grid/

The preceding demo is achieved with the following CSS:

.container {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-template-rows: masonry;
}

It's comforting to know that this is on the radar as a missing layout strategy, plus you can try it today in Firefox.

Resources #

CSS can't help users reduce data #

Browser support

Chrome 85, Behind a flag
Firefox, Not supported
Edge 85, Behind a flag
Safari, Not supported

Source

Before the prefers-reduced-data media query, JavaScript and a server could change their behavior based on a user’s operating system or browser "data saver" option, but CSS could not.

After the prefers-reduced-data media query, CSS can join the user experience enhancement and play its part in saving data.

@media (prefers-reduced-data: reduce) {
  picture, video {
    display: none;
  }
}

The preceding CSS is used in this media scroll component and the savings can be huge. Depending on how large the visiting viewport is, the more savings to be had on page load. Saving continues as users interact with the media scrollers. The images all have loading="lazy" attributes on them and that, combined with CSS hiding the element entirely, means a network request for the image is never made.

For my testing, on a medium sized viewport, 40 requests and 700kb of resources were initially loaded. As a user scrolls the media selection, more requests and resources are loaded. With CSS and the reduced data media query, 10 requests and 172kb of resources are loaded. That's half a megabyte of savings and the user hasn't even scrolled any of the media, at which point there are no additional requests made.

There are more advantages to this reduced data experience than just data savings. More titles can be seen and there's no distracting cover images to steal attention. Many users browse in a data saver mode because they pay per megabyte of data—it's really nice to see CSS able to help out here.

Resources #

Scroll snap features are too limited #

Before these scroll snap proposals, writing your own JavaScript to manage a carousel, slider, or gallery could quickly get complex, with all the observers and state management. Also, if not careful, the natural scrolling speeds could get normalized by script, making user interaction feel a bit unnatural and potentially clunky.

New APIs #

`snapChanging()` #

As soon as the browser has released a snap child, this event fires. This allows UI to reflect the lack of a snap child and the indeterminate snap state of the scroller, as it's now being used and will land somewhere new.

document.querySelector('.snap-carousel').addEventListener('snapchanging', event => {
  console.log('Snap is changing', event.snappedTargetsList);
});

`snapChanged()` #

As soon as the browser has snapped to a new child and the scroller is rested, this event fires. This lets any UI that depends on the snapped child to update and reflect the connection.

document.querySelector('.snap-carousel').addEventListener('snapchanged', event => {
  console.log('Snap changed', event.snappedTargetsList);
});

`scroll-start` #

Scrolling doesn't always begin at the start. Consider swipeable components where swiping left or right triggers different events, or a search bar that on page load is initially hidden until you scroll to the top. This CSS property lets developers specify that a scroller should begin at a specific point.

:root { --nav-height: 100px }

.snap-scroll-y {
  scroll-start-y: var(--nav-height);
}

`:snap-target` #

This CSS selector will match elements in a scroll snap container that are currently snapped by the browser.

.card {
  --shadow-distance: 5px;
  box-shadow: 0 var(--shadow-distance) 5px hsl(0 0% 0% / 25%);
  transition: box-shadow 350ms ease;
}

.card:snapped {
  --shadow-distance: 30px;
}

After these scroll snap proposals, making a slider, carousel, or gallery is much easier as the browser now offers conveniences for the task, eliminating observers and scroll orchestration code in favor of using built-in APIs.

It's still very early days for these CSS and JS features, but be on the lookout for polyfills that can help adoption, and testing, of them soon.

Resources #

Cycling between known states #

Before toggle(), only states built into the browser already could be leveraged for styling and interaction. The checkbox input, for example, has :checked, an internally managed browser state for the input that CSS is able to use for changing the element visually.

After toggle(), custom states can be created on any element for CSS to change and use for styling. It allows groups, cycling, directed toggling, and more.

In the following example, the same effect of a list item strikethrough on complete is achieved but without any checkbox elements:

<ul class='ingredients'>
   <li>1 banana
   <li>1 cup blueberries
  ...
</ul>

And the relevant CSS toggle() styles:

li {
  toggle-root: check self;
}

li:toggle(check) {
  text-decoration: line-through;
}

If you're familiar with state machines, you may notice how much crossover there is with toggle(). This feature will let developers build more of their state into CSS, hopefully resulting in clearer and more semantic ways of orchestrating interaction and state.

Resources #

Customizing select elements #

Before <selectmenu>, CSS didn't have the ability to customize <option> elements with rich HTML or change much about the display of a list of options. This led developers to load external libraries that recreated much of the functionality of a <select>, which ended up being a lot of work.

After <selectmenu>, developers can provide rich HTML for options elements and style them as much as they need, while still meeting accessibility requirements and providing semantic HTML.

In the following example, taken from the <selectmenu> explainer page, a new select menu is created with some basic options:

<selectmenu>
  <option>Option 1</option>
  <option>Option 2</option>
  <option>Option 3</option>
</selectmenu>

CSS can target and style the element's parts:

.my-select-menu::part(button) {
  color: white;
  background-color: red;
  padding: 5px;
  border-radius: 5px;
}

.my-select-menu::part(listbox) {
  padding: 10px;
  margin-top: 5px;
  border: 1px solid red;
  border-radius: 5px;
}

You can try the <selectmenu> element on Chromium in Canary with the web experiments flag enabled. Watch out in 2023 and beyond for customizable select menu elements.

Resources #

Anchoring an element to another #

Before anchor(), position absolute and relative were position strategies provided for developers to have child elements move around within a parent element.

After anchor(), developers can position elements to other elements, regardless of them being a child or not. It also allows developers to specify which edge to position against, and other niceties for creating position relationships between elements.

The explainer has a few great examples and code samples provided, if you're interested in learning more.

Resources #

anchor() explainer

Building a dialog component

2022-04-13T00:00:00Z

In this post I want to share my thoughts on how to build color-adaptive, responsive, and accessible mini and mega modals with the <dialog> element. Try the demo and view the source!

Demonstration of the mega and mini dialogs in their light and dark themes.

If you prefer video, here's a YouTube version of this post:

Overview #

The <dialog> element is great for in-page contextual information or action. Consider when the user experience can benefit from a same page action instead of multi-page action: perhaps because the form is small or the only action required from the user is confirm or cancel.

The <dialog> element has recently become stable across browsers:

Browser support

Chrome 37, Supported 37
Firefox 98, Supported 98
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

I found the element was missing a few things, so in this GUI Challenge I add the developer experience items I expect: additional events, light dismiss, custom animations, and a mini and mega type.

Markup #

The essentials of a <dialog> element are modest. The element will automatically be hidden and has styles built in to overlay your content.

<dialog>
  …
</dialog>

See the Pen Pen popLbZB by web-dot-dev on Codepen

We can improve this baseline.

Traditionally, a dialog element shares a lot with a modal, and often the names are interchangeable. I took the liberty here of using the dialog element for both small dialog popups (mini), as well as full page dialogs (mega). I named them mega and mini, with both dialogs slightly adapted for different use cases. I added a modal-mode attribute to allow you to specify the type:

<dialog id="MegaDialog" modal-mode="mega"></dialog>
<dialog id="MiniDialog" modal-mode="mini"></dialog>

Not always, but generally dialog elements will be used to gather some interaction information. Forms inside dialog elements are made to go together. It's a good idea to have a form element wrap your dialog content so that JavaScript can access the data the user has entered. Furthermore, buttons inside a form using method="dialog" can close a dialog without JavaScript and pass data.

<dialog id="MegaDialog" modal-mode="mega">
  <form method="dialog">
    …
    <button value="cancel">Cancel</button>
    <button value="confirm">Confirm</button>
  </form>
</dialog>

Mega dialog #

A mega dialog has three elements inside the form: <header>, <article>, and <footer>. These serve as semantic containers, as well as style targets for the presentation of the dialog. The header titles the modal and offers a close button. The article is for form inputs and information. The footer holds a <menu> of action buttons.

<dialog id="MegaDialog" modal-mode="mega">
  <form method="dialog">
    <header>
      <h3>Dialog title</h3>
      <button onclick="this.closest('dialog').close('close')"></button>
    </header>
    <article>...</article>
    <footer>
      <menu>
        <button autofocus type="reset" onclick="this.closest('dialog').close('cancel')">Cancel</button>
        <button type="submit" value="confirm">Confirm</button>
      </menu>
    </footer>
  </form>
</dialog>

The first menu button has autofocus and an onclick inline event handler. The autofocus attribute will receive focus when the dialog is opened, and I find it's best practice to put this on the cancel button, not the confirm button. This ensures that confirmation is deliberate and not accidental.

Mini dialog #

The mini dialog is very similar to the mega dialog, it's just missing a <header> element. This allows it to be smaller and more inline.

<dialog id="MiniDialog" modal-mode="mini">
  <form method="dialog">
    <article>
      <p>Are you sure you want to remove this user?</p>
    </article>
    <footer>
      <menu>
        <button autofocus type="reset" onclick="this.closest('dialog').close('cancel')">Cancel</button>
        <button type="submit" value="confirm">Confirm</button>
      </menu>
    </footer>
  </form>
</dialog>

The dialog element provides a strong foundation for a full viewport element that can collect data and user interaction. These essentials can make for some very interesting and powerful interactions in your site or app.

Accessibility #

The dialog element has very good built-in accessibility. Instead of adding these features like I usually do, many are already there.

Restoring focus #

As we did by hand in Building a sidenav component, it's important that opening and closing something properly puts focus on the relevant open and close buttons. When that sidenav opens, focus is put on the close button. When the close button is pressed, focus is restored to the button that opened it.

With the dialog element, this is built-in default behavior:

Unfortunately, if you want to animate the dialog in and out, this functionality is lost. In the JavaScript section I'll be restoring that functionality.

Trapping focus #

The dialog element manages inert for you on the document. Before inert, JavaScript was used to watch for focus leaving an element, at which point it intercepts and puts it back.

Browser support

Chrome 102, Supported 102
Firefox 112, Supported 112
Edge 102, Supported 102
Safari 15.5, Supported 15.5

Source

After inert, any parts of the document can be "frozen" insomuch that they are no longer focus targets or are interactive with a mouse. Instead of trapping focus, focus is guided into the only interactive part of the document.

Open and auto focus an element #

By default, the dialog element will assign focus to the first focusable element in the dialog markup. If this isn't the best element for the user to default to, use the autofocus attribute. As described earlier, I find it's best practice to put this on the cancel button and not the confirm button. This ensures that confirmation is deliberate and not accidental.

Closing with the escape key #

It's important to make it easy to close this potentially interruptive element. Fortunately, the dialog element will handle the escape key for you, freeing you from the orchestration burden.

Styles #

There's an easy path to styling the dialog element and a hard path. The easy path is achieved by not changing the display property of the dialog and working with its limitations. I go down the hard path to provide custom animations for opening and closing the dialog, taking over the display property and more.

Styling with Open Props #

To accelerate adaptive colors and overall design consistency, I've shamelessly brought in my CSS variable library Open Props. In addition to the free provided variables, I also import a normalize file and some buttons, both of which Open Props provides as optional imports. These imports help me focus on customizing the dialog and demo while not needing a lot of styles to support it and make it look good.

Styling the `<dialog>` element #

Owning the display property #

The default show and hide behavior of a dialog element toggles the display property from block to none. This unfortunately means it can't be animated in and out, only in. I'd like to animate both in and out, and the first step is to set my own display property:

dialog {
  display: grid;
}

By changing, and therefore owning, the display property value, as shown in the above CSS snippet, a considerable amount of styles needs managed in order to facilitate the proper user experience. First, the default state of a dialog is closed. You can represent this state visually and prevent the dialog from receiving interactions with the following styles:

dialog:not([open]) {
  pointer-events: none;
  opacity: 0;
}

Now the dialog is invisible and cannot be interacted with when not open. Later I'll add some JavaScript to manage the inert attribute on the dialog, ensuring that keyboard and screen-reader users also can't reach the hidden dialog.

Giving the dialog an adaptive color theme #

While color-scheme opts your document into a browser-provided adaptive color theme to light and dark system preferences, I wanted to customize the dialog element more than that. Open Props provides a few surface colors that adapt automatically to light and dark system preferences, similar to using the color-scheme. These are great for creating layers in a design and I love using color to help visually support this appearance of layer surfaces. The background color is var(--surface-1); to sit on top of that layer, use var(--surface-2):

dialog {
  …
  background: var(--surface-2);
  color: var(--text-1);
}

@media (prefers-color-scheme: dark) {
  dialog {
    border-block-start: var(--border-size-1) solid var(--surface-3);
  }
}

More adaptive colors will be added later for child elements, such as the header and footer. I consider them extra for a dialog element, but really important in making a compelling and well designed dialog design.

Responsive dialog sizing #

The dialog defaults to delegating its size to its contents, which is generally great. My goal here is to constrain the max-inline-size to a readable size (--size-content-3 = 60ch) or 90% of the viewport width. This ensures the dialog won't go edge to edge on a mobile device, and won't be so wide on a desktop screen that it's hard to read. Then I add a max-block-size so the dialog won't exceed the height of the page. This also means that we'll need to specify where the scrollable area of the dialog is, in case it's a tall dialog element.

dialog {
  …
  max-inline-size: min(90vw, var(--size-content-3));
  max-block-size: min(80vh, 100%);
  max-block-size: min(80dvb, 100%);
  overflow: hidden;
}

Notice how I have max-block-size twice? The first uses 80vh, a physical viewport unit. What I really want is to keep the dialog within relative flow, for international users, so I use the logical, newer, and only partially supported dvb unit in the second declaration for when it becomes more stable.

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Mega dialog positioning #

To assist in positioning a dialog element, it's worth breaking down its two parts: the full screen backdrop and the dialog container. The backdrop must cover everything, providing a shade effect to help support that this dialog is in front and the content behind is inaccessible. The dialog container is free to center itself over this backdrop and take whatever shape its contents require.

The following styles fix the dialog element to the window, stretching it to each corner, and uses margin: auto to center the content:

dialog {
  …
  margin: auto;
  padding: 0;
  position: fixed;
  inset: 0;
  z-index: var(--layer-important);
}

Mobile mega dialog styles #

On small viewports, I style this full page mega modal a little differently. I set the bottom margin to 0, which brings the dialog content to the bottom of the viewport. With a couple of style adjustments, I can turn the dialog into an actionsheet, closer to the user's thumbs:

@media (max-width: 768px) {
  dialog[modal-mode="mega"] {
    margin-block-end: 0;
    border-end-end-radius: 0;
    border-end-start-radius: 0;
  }
}

Mini dialog positioning #

When using a larger viewport such as on a desktop computer, I chose to position the mini dialogs over the element that called them. To do this I need JavaScript. You can find the technique I use here, but I feel it is beyond the scope of this article. Without the JavaScript, the mini dialog appears in the center of the screen, just like mega dialog.

Make it pop #

Last, add some flair to the dialog so it looks like a soft surface sitting far above the page. The softness is achieved by rounding the corners of the dialog. The depth is achieved with one of Open Props’ carefully crafted shadow props:

dialog {
  …
  border-radius: var(--radius-3);
  box-shadow: var(--shadow-6);
}

Customizing the backdrop pseudo element #

I chose to work very lightly with the backdrop, only adding a blur effect with backdrop-filter to the mega dialog:

Browser support

Chrome 76, Supported 76
Firefox 103, Supported 103
Edge 17, Supported 17
Safari 9, Supported 9

Source

dialog[modal-mode="mega"]::backdrop {
  backdrop-filter: blur(25px);
}

I also chose to put a transition on backdrop-filter, in the hope that browsers will allow transitioning the backdrop element in the future:

dialog::backdrop {
  transition: backdrop-filter .5s ease;
}

Styling extras #

I call this section "extras" because it has more to do with my dialog element demo than it does the dialog element in general.

Scroll containment #

When the dialog is shown, the user is still able to scroll the page behind it, which I do not want:

Normally, overscroll-behavior would be my usual solution, but according to the spec, it has no effect on the dialog because it's not a scroll port, that is, it's not a scroller so there's nothing to prevent. I could use JavaScript to watch for the new events from this guide, such as "closed" and "opened", and toggle overflow: hidden on the document, or I could wait for :has() to be stable in all browsers:

Browser support

Chrome 105, Supported 105
Firefox 103, Behind a flag
Edge 105, Supported 105
Safari 15.4, Supported 15.4

Source

html:has(dialog[open][modal-mode="mega"]) {
  overflow: hidden;
}

Now when a mega dialog is open, the html document has overflow: hidden.

The `<form>` layout #

Besides being a very important element for collecting the interaction information from the user, I use it here to lay out the header, footer and article elements. With this layout I intend to articulate the article child as a scrollable area. I achieve this with grid-template-rows. The article element is given 1fr and the form itself has the same maximum height as the dialog element. Setting this firm height and firm row size is what allows the article element to be constrained and scroll when it overflows:

dialog > form {
  display: grid;
  grid-template-rows: auto 1fr auto;
  align-items: start;
  max-block-size: 80vh;
  max-block-size: 80dvb;
}

Styling the dialog `<header>` #

The role of this element is to provide a title for the dialog content and offer an easy to find close button. It's also given a surface color to make it appear to be behind the dialog article content. These requirements lead to a flexbox container, vertically aligned items that are spaced to their edges, and some padding and gaps to give the title and close buttons some room:

dialog > form > header {
  display: flex;
  gap: var(--size-3);
  justify-content: space-between;
  align-items: flex-start;
  background: var(--surface-2);
  padding-block: var(--size-3);
  padding-inline: var(--size-5);
}

@media (prefers-color-scheme: dark) {
  dialog > form > header {
    background: var(--surface-1);
  }
}

Styling the header close button #

Since the demo is using the Open Props buttons, the close button is customized into a round icon centric button like so:

dialog > form > header > button {
  border-radius: var(--radius-round);
  padding: .75ch;
  aspect-ratio: 1;
  flex-shrink: 0;
  place-items: center;
  stroke: currentColor;
  stroke-width: 3px;
}

Styling the dialog `<article>` #

The article element has a special role in this dialog: it's a space intended to be scrolled in the case of a tall or long dialog.

To accomplish this, the parent form element has established some maximums for itself which provide constraints for this article element to reach if it gets too tall. Set overflow-y: auto so scrollbars are only shown when needed, contain scrolling within it with overscroll-behavior: contain, and the rest will be custom presentation styles:

dialog > form > article {
  overflow-y: auto; 
  max-block-size: 100%; /* safari */
  overscroll-behavior-y: contain;
  display: grid;
  justify-items: flex-start;
  gap: var(--size-3);
  box-shadow: var(--shadow-2);
  z-index: var(--layer-1);
  padding-inline: var(--size-5);
  padding-block: var(--size-3);
}

@media (prefers-color-scheme: light) {
  dialog > form > article {
    background: var(--surface-1);
  }
}

Styling the dialog `<footer>` #

The footer's role is to contain menus of action buttons. Flexbox is used to align the content to the end of the footer inline axis, then some spacing to give the buttons some room.

dialog > form > footer {
  background: var(--surface-2);
  display: flex;
  flex-wrap: wrap;
  gap: var(--size-3);
  justify-content: space-between;
  align-items: flex-start;
  padding-inline: var(--size-5);
  padding-block: var(--size-3);
}

@media (prefers-color-scheme: dark) {
  dialog > form > footer {
    background: var(--surface-1);
  }
}

The menu element is used to contain the action buttons for the dialog. It uses a wrapping flexbox layout with gap to provide space between the buttons. Menu elements have padding such as a <ul>. I also remove that style since I don't need it.

dialog > form > footer > menu {
  display: flex;
  flex-wrap: wrap;
  gap: var(--size-3);
  padding-inline-start: 0;
}

dialog > form > footer > menu:only-child {
  margin-inline-start: auto;
}

Animation #

Dialog elements are often animated because they enter and exit the window. Giving dialogs some supportive motion for this entrance and exit helps users orient themselves in the flow.

Normally the dialog element can only be animated in, not out. This is because the browser toggles the display property on the element. Earlier, the guide set display to grid, and never sets it to none. This unlocks the ability to animate in and out.

Open Props comes with many keyframe animations for use, which makes orchestration easy and legible. Here are the animation goals and layered approach I took:

Reduced motion is the default transition, a simple opacity fade in and out.
If motion is ok, slide and scale animations are added.
The responsive mobile layout for the mega dialog is adjusted to slide out.

A safe and meaningful default transition #

While Open Props comes with keyframes for fading in and out, I prefer this layered approach of transitions as the default with keyframe animations as potential upgrades. Earlier we already styled the dialog’s visibility with opacity, orchestrating 1 or 0 depending on the [open] attribute. To transition between 0% and 100%, tell the browser how long and what kind of easing you'd like:

dialog {
  transition: opacity .5s var(--ease-3);
}

Adding motion to the transition #

If the user is ok with motion, both the mega and the mini dialogs should slide up as their entrance, and scale out as their exit. You can achieve this with the prefers-reduced-motion media query and a few Open Props:

@media (prefers-reduced-motion: no-preference) {
  dialog {
    animation: var(--animation-scale-down) forwards;
    animation-timing-function: var(--ease-squish-3);
  }

  dialog[open] {
    animation: var(--animation-slide-in-up) forwards;
  }
}

Adapting the exit animation for mobile #

Earlier in the styling section, the mega dialog style is adapted for mobile devices to be more like an action sheet, as if a small piece of paper has slid up from the bottom of the screen and is still attached to the bottom. The scale out exit animation doesn't fit this new design well, and we can adapt this with a couple media queries and some Open Props:

@media (prefers-reduced-motion: no-preference) and @media (max-width: 768px) {
  dialog[modal-mode="mega"] {
    animation: var(--animation-slide-out-down) forwards;
    animation-timing-function: var(--ease-squish-2);
  }
}

JavaScript #

There are quite a few things to add with JavaScript:

// dialog.js
export default async function (dialog) {
  // add light dismiss
  // add closing and closed events
  // add opening and opened events
  // add removed event
  // removing loading attribute
}

These additions stem from the desire for light dismiss (clicking the dialog backdrop), animation, and some additional events for better timing on getting the form data.

Adding light dismiss #

This task is straightforward and a great addition to a dialog element that isn't being animated. The interaction is achieved by watching clicks on the dialog element and leveraging event bubbling to assess what was clicked, and will only close() if it's the top-most element:

export default async function (dialog) {
  dialog.addEventListener('click', lightDismiss)
}

const lightDismiss = ({target:dialog}) => {
  if (dialog.nodeName === 'DIALOG')
    dialog.close('dismiss')
}

Notice dialog.close('dismiss'). The event is called and a string is provided. This string can be retrieved by other JavaScript to get insights into how the dialog was closed. You'll find I've also provided close strings each time I call the function from various buttons, to provide context to my application about the user interaction.

Adding closing and closed events #

The dialog element comes with a close event: it emits immediately when the dialog close() function is called. Since we're animating this element, it's nice to have events for before and after the animation, for a change to grab the data or reset the dialog form. I use it here to manage the addition of the inert attribute on the closed dialog, and in the demo I use these to modify the avatar list if the user has submitted a new image.

To achieve this, create two new events called closing and closed. Then listen for the built-in close event on the dialog. From here, set the dialog to inert and dispatch the closing event. The next task is to wait for the animations and transitions to finish running on the dialog, then dispatch the closed event.

const dialogClosingEvent = new Event('closing')
const dialogClosedEvent  = new Event('closed')

export default async function (dialog) {
  …
  dialog.addEventListener('close', dialogClose)
}

const dialogClose = async ({target:dialog}) => {
  dialog.setAttribute('inert', '')
  dialog.dispatchEvent(dialogClosingEvent)

  await animationsComplete(dialog)

  dialog.dispatchEvent(dialogClosedEvent)
}

const animationsComplete = element =>
  Promise.allSettled(
    element.getAnimations().map(animation => 
      animation.finished))

The animationsComplete function, which is also used in the Building a toast component, returns a promise based on the completion of the animation and transition promises. This is why dialogClose is an async function; it can then await the promise returned and move forward confidently to the closed event.

Adding opening and opened events #

These events aren't as easy to add since the built-in dialog element doesn't provide an open event like it does with close. I use a MutationObserver to provide insights into the dialog’s attributes changing. In this observer, I'll watch for changes to the open attribute and manage the custom events accordingly.

Similar to how we started the closing and closed events, create two new events called opening and opened. Where we previously listened for the dialog close event, this time use a created mutation observer to watch the dialog's attributes.

…
const dialogOpeningEvent = new Event('opening')
const dialogOpenedEvent  = new Event('opened')

export default async function (dialog) {
  …
  dialogAttrObserver.observe(dialog, { 
    attributes: true,
  })
}

const dialogAttrObserver = new MutationObserver((mutations, observer) => {
  mutations.forEach(async mutation => {
    if (mutation.attributeName === 'open') {
      const dialog = mutation.target

      const isOpen = dialog.hasAttribute('open')
      if (!isOpen) return

      dialog.removeAttribute('inert')

      // set focus
      const focusTarget = dialog.querySelector('[autofocus]')
      focusTarget
        ? focusTarget.focus()
        : dialog.querySelector('button').focus()

      dialog.dispatchEvent(dialogOpeningEvent)
      await animationsComplete(dialog)
      dialog.dispatchEvent(dialogOpenedEvent)
    }
  })
})

The mutation observer callback function will be called when the dialog attributes are changed, providing the list of changes as an array. Iterate over the attribute changes, looking for the attributeName to be open. Next, check if the element has the attribute or not: this informs whether or not the dialog has become open. If it has been opened, remove the inert attribute, set focus to either an element requesting autofocus or the first button element found in the dialog. Last, similar to the closing and closed event, dispatch the opening event right away, wait for the animations to finish, then dispatch the opened event.

Adding a removed event #

In single page applications, dialogs are often added and removed based on routes or other application needs and state. It can be useful to clean up events or data when a dialog is removed.

You can achieve this with another mutation observer. This time, instead of observing attributes on a dialog element, we'll observe the children of the body element and watch for dialog elements being removed.

…
const dialogRemovedEvent = new Event('removed')

export default async function (dialog) {
  …
  dialogDeleteObserver.observe(document.body, {
    attributes: false,
    subtree: false,
    childList: true,
  })
}

const dialogDeleteObserver = new MutationObserver((mutations, observer) => {
  mutations.forEach(mutation => {
    mutation.removedNodes.forEach(removedNode => {
      if (removedNode.nodeName === 'DIALOG') {
        removedNode.removeEventListener('click', lightDismiss)
        removedNode.removeEventListener('close', dialogClose)
        removedNode.dispatchEvent(dialogRemovedEvent)
      }
    })
  })
})

The mutation observer callback is called whenever children are added or removed from the body of the document. The specific mutations being watched are for removedNodes that have the nodeName of a dialog. If a dialog was removed, the click and close events are removed to free up memory, and the custom removed event is dispatched.

Removing the loading attribute #

To prevent the dialog animation from playing its exit animation when added to the page or on page load, a loading attribute has been added to the dialog. The following script waits for the dialog animations to finish running, then removes the attribute. Now the dialog is free to animate in and out, and we've effectively hidden an otherwise distracting animation.

export default async function (dialog) {
  …
  await animationsComplete(dialog)
  dialog.removeAttribute('loading')
}

Learn more about the problem of preventing keyframe animations on page load here.

All together #

Here is dialog.js in its entirety, now that we've explained each section individually:

// custom events to be added to <dialog>
const dialogClosingEvent = new Event('closing')
const dialogClosedEvent  = new Event('closed')
const dialogOpeningEvent = new Event('opening')
const dialogOpenedEvent  = new Event('opened')
const dialogRemovedEvent = new Event('removed')

// track opening
const dialogAttrObserver = new MutationObserver((mutations, observer) => {
  mutations.forEach(async mutation => {
    if (mutation.attributeName === 'open') {
      const dialog = mutation.target

      const isOpen = dialog.hasAttribute('open')
      if (!isOpen) return

      dialog.removeAttribute('inert')

      // set focus
      const focusTarget = dialog.querySelector('[autofocus]')
      focusTarget
        ? focusTarget.focus()
        : dialog.querySelector('button').focus()

      dialog.dispatchEvent(dialogOpeningEvent)
      await animationsComplete(dialog)
      dialog.dispatchEvent(dialogOpenedEvent)
    }
  })
})

// track deletion
const dialogDeleteObserver = new MutationObserver((mutations, observer) => {
  mutations.forEach(mutation => {
    mutation.removedNodes.forEach(removedNode => {
      if (removedNode.nodeName === 'DIALOG') {
        removedNode.removeEventListener('click', lightDismiss)
        removedNode.removeEventListener('close', dialogClose)
        removedNode.dispatchEvent(dialogRemovedEvent)
      }
    })
  })
})

// wait for all dialog animations to complete their promises
const animationsComplete = element =>
  Promise.allSettled(
    element.getAnimations().map(animation => 
      animation.finished))

// click outside the dialog handler
const lightDismiss = ({target:dialog}) => {
  if (dialog.nodeName === 'DIALOG')
    dialog.close('dismiss')
}

const dialogClose = async ({target:dialog}) => {
  dialog.setAttribute('inert', '')
  dialog.dispatchEvent(dialogClosingEvent)

  await animationsComplete(dialog)

  dialog.dispatchEvent(dialogClosedEvent)
}

// page load dialogs setup
export default async function (dialog) {
  dialog.addEventListener('click', lightDismiss)
  dialog.addEventListener('close', dialogClose)

  dialogAttrObserver.observe(dialog, { 
    attributes: true,
  })

  dialogDeleteObserver.observe(document.body, {
    attributes: false,
    subtree: false,
    childList: true,
  })

  // remove loading attribute
  // prevent page load @keyframes playing
  await animationsComplete(dialog)
  dialog.removeAttribute('loading')
}

Using the `dialog.js` module #

The exported function from the module expects to be called and passed a dialog element that wants to have these new events and functionality added:

import GuiDialog from './dialog.js'

const MegaDialog = document.querySelector('#MegaDialog')
const MiniDialog = document.querySelector('#MiniDialog')

GuiDialog(MegaDialog)
GuiDialog(MiniDialog)

Just like that, the two dialogs are upgraded with light dismiss, animation loading fixes, and more events to work with.

Listening to the new custom events #

Each upgraded dialog element can now listen for five new events, like this:

MegaDialog.addEventListener('closing', dialogClosing)
MegaDialog.addEventListener('closed', dialogClosed)

MegaDialog.addEventListener('opening', dialogOpening)
MegaDialog.addEventListener('opened', dialogOpened)

MegaDialog.addEventListener('removed', dialogRemoved)

Here are two examples of handling those events:

const dialogOpening = ({target:dialog}) => {
  console.log('Dialog opening', dialog)
}

const dialogClosed = ({target:dialog}) => {
  console.log('Dialog closed', dialog)
  console.info('Dialog user action:', dialog.returnValue)

  if (dialog.returnValue === 'confirm') {
    // do stuff with the form values
    const dialogFormData = new FormData(dialog.querySelector('form'))
    console.info('Dialog form data', Object.fromEntries(dialogFormData.entries()))

    // then reset the form
    dialog.querySelector('form')?.reset()
  }
}

In the demo that I built with the dialog element, I use that closed event and the form data to add a new avatar element to the list. The timing is good in that the dialog has completed its exit animation, and then some scripts animate in the new avatar. Thanks to the new events, orchestrating the user experience can be smoother.

Notice dialog.returnValue: this contains the close string passed when the dialog close() event is called. It's critical in the dialogClosed event to know if the dialog was closed, canceled, or confirmed. If it's confirmed, the script then grabs the form values and resets the form. The reset is useful so that when the dialog is shown again, it's blank and ready for a new submission.

Conclusion #

Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web.

Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

@GrimLink with a 3-in-1 dialog.
@mikemai2awesome with a nice remix that doesn't change the display property.
@geoffrich_ with Svelte and nice Svelte FLIP polish.

Resources #

Source code on Github
Doodle Avatars

Building a loading bar component

2022-03-16T00:00:00Z

In this post I want to share thinking on how to build a color adaptive and accessible loading bar with the <progress> element. Try the demo and view the source!

Light and dark, indeterminate, increasing, and completion demoed on Chrome.

If you prefer video, here's a YouTube version of this post:

Overview #

The <progress> element provides visual and audible feedback to users about completion. This visual feedback is valuable for scenarios such as: progress through a form, displaying downloading or uploading information, or even showing that the progress amount is unknown but work is still active.

This GUI Challenge worked with the existing HTML <progress> element to save some effort in accessibility. The colors and layouts push the limits of customization for the built-in element, to modernize the component and have it fit better within design systems.

Demo shown across Firefox, Safari, iOS Safari, Chrome, and Android Chrome in light and dark schemes.

Markup #

I chose to wrap the <progress> element in a <label> so I could skip the explicit relationship attributes in favor of an implicit relationship. I've also labeled a parent element affected by the loading state, so screen reader technologies can relay that information back to a user.

<progress></progress>

If there is no value, then the element's progress is indeterminate. The max attribute defaults to 1, so progress is between 0 and 1. Setting max to 100, for example, would set the range to 0-100. I chose to stay within the 0 and 1 limits, translating progress values to 0.5 or 50%.

Label-wrapped progress #

In an implicit relationship, a progress element is wrapped by a label like this:

<label>Loading progress<progress></progress></label>

In my demo I chose to include the label for screen readers only. This is done by wrapping the label text in a <span> and applying some styles to it so that it's effectively off screen:

<label>
  <span class="sr-only">Loading progress</span>
  <progress></progress>
</label>

With the following accompanying CSS from WebAIM:

.sr-only {
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(50%);
  height: 1px;
  width: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
}

Area affected by loading progress #

If you have healthy vision, it can be easy to associate a progress indicator with related elements and page areas, but for visually impaired users, it's not so clear. Improve this by assigning the aria-busy attribute to the top-most element that will change when loading is complete. Furthermore, indicate a relationship between the progress and the loading zone with aria-describedby.

<main id="loading-zone" aria-busy="true">
  …
  <progress aria-describedby="loading-zone"></progress>
</main>

From JavaScript, toggle aria-busy to true at the start of the task, and to false once finished.

Aria attribute additions #

While the implicit role of a <progress> element is progressbar, I've made it explicit for browsers that lack that implicit role. I've also added the attribute indeterminate to explicitly put the element into a state of unknown, which is clearer than observing the element has no value set.

<label>
  Loading 
  <progress 
    indeterminate 
    role="progressbar" 
    aria-describedby="loading-zone"
    tabindex="-1"
  >unknown</progress>
</label>

Use tabindex="-1" to make the progress element focusable from JavaScript. This is important for screen reader technology, since giving the progress focus as progress changes, will announce to the user how far the updated progress has reached.

Styles #

The progress element is a bit tricky when it comes to styling. Built-in HTML elements have special hidden parts that can be difficult to select and often only offer a limited set of properties to be set.

Layout #

The layout styles are intended to allow some flexibility in the progress element's size and label position. A special completion state is added that can be a useful, but not required, additional visual cue.

`<progress>` Layout #

The width of the progress element is left untouched so it can shrink and grow with the space needed in the design. The built-in styles are stripped out by setting appearance and border to none. This is done so the element can be normalized across browsers, since each browser has its own styles for their element.

progress {
  --_track-size: min(10px, 1ex);
  --_radius: 1e3px;

  /*  reset  */
  appearance: none;
  border: none;

  position: relative;
  height: var(--_track-size);
  border-radius: var(--_radius);
  overflow: hidden;
}

The value of 1e3px for _radius uses scientific number notation to express a large number so the border-radius is always rounded. It's equivalent to 1000px. I like to use this because my aim is to use a value large enough that I can set it and forget it (and it's shorter to write than 1000px). It is also easy to make it even larger if needed: just change the 3 to a 4, then 1e4px is equivalent to 10000px.

overflow: hidden is used and has been a contentious style. It made a few things easy, such as not needing to pass border-radius values down to the track, and track fill elements; but it also meant no children of the progress could live outside of the element. Another iteration on this custom progress element could be done without overflow: hidden and it may open up some opportunities for animations or better completion states.

Progress complete #

CSS selectors do the tough work here by comparing the maximum with the value, and if they match, then the progress is complete. When complete, a pseudo-element is generated and appended to the end of the progress element, providing a nice additional visual cue to the completion.

progress:not([max])[value="1"]::before,
progress[max="100"][value="100"]::before {
  content: "✓";
  
  position: absolute;
  inset-block: 0;
  inset-inline: auto 0;
  display: flex;
  align-items: center;
  padding-inline-end: max(calc(var(--_track-size) / 4), 3px);

  color: white;
  font-size: calc(var(--_track-size) / 1.25);
}

Color #

The browser brings its own colors for the progress element, and is adaptive to light and dark with just one CSS property. This can be built upon with some special browser-specific selectors.

Light and dark browser styles #

To opt your site into a dark and light adaptive <progress> element, color-scheme is all that is required.

progress {
  color-scheme: light dark;
}

See the Pen Pen KKZwoVy by web-dot-dev on Codepen

Single property progress filled color #

To tint a <progress> element, use accent-color.

progress {
  accent-color: rebeccapurple;
}

Notice the track background color changes from light to dark depending on the accent-color. The browser is ensuring proper contrast: pretty neat.

See the Pen Pen mdpyxRP by web-dot-dev on Codepen

Fully custom light and dark colors #

Set two custom properties on the <progress> element, one for the track color and the other for the track progress color. Inside the prefers-color-scheme media query, provide new color values for the track and track progress.

progress {
  --_track: hsl(228 100% 90%);
  --_progress: hsl(228 100% 50%);
}

@media (prefers-color-scheme: dark) {
  progress {
    --_track: hsl(228 20% 30%);
    --_progress: hsl(228 100% 75%);
  }
}

Focus styles #

Earlier we gave the element a negative tab index so it could be programmatically focused. Use :focus-visible to customize focus to opt into the smarter focus ring style. With this, a mouse click and focus won't show the focus ring, but keyboard clicks will. The YouTube video goes into this in more depth and is worth reviewing.

progress:focus-visible {
  outline-color: var(--_progress);
  outline-offset: 5px;
}

Custom styles across browsers #

Customize the styles by selecting the parts of a <progress> element that each browser exposes. Using the progress element is a single tag, but it's made of a few child elements that are exposed via CSS pseudo selectors. Chrome DevTools will show these elements to you if you enable the setting:

Right-click on your page and select Inspect Element to bring up DevTools.
Click the Settings gear in the top-right corner of the DevTools window.
Under the Elements heading, find and enable the Show user agent shadow DOM checkbox.

Safari and Chromium styles #

WebKit-based browsers such as Safari and Chromium expose ::-webkit-progress-bar and ::-webkit-progress-value, which allow a subset of CSS to be used. For now, set background-color using the custom properties created earlier, which adapt to light and dark.

/*  Safari/Chromium  */
progress[value]::-webkit-progress-bar {
  background-color: var(--_track);
}

progress[value]::-webkit-progress-value {
  background-color: var(--_progress);
}

Firefox styles #

Firefox only exposes the ::-moz-progress-bar pseudo selector on the <progress> element. This also means we can't tint the track directly.

/*  Firefox  */
progress[value]::-moz-progress-bar {
  background-color: var(--_progress);
}

Notice that Firefox has a track color set from accent-color while iOS Safari has a light blue track. It's the same in dark mode: Firefox has a dark track but not the custom color we've set, and it works in Webkit-based browsers.

Animation #

While working with browser built-in pseudo selectors, it's often with a limited set of permitted CSS properties.

Animating the track filling up #

Adding a transition to the inline-size of the progress element works for Chromium but not for Safari. Firefox also does not use a transition property on it's ::-moz-progress-bar.

/*  Chromium Only 😢  */
progress[value]::-webkit-progress-value {
  background-color: var(--_progress);
  transition: inline-size .25s ease-out;
}

Animating the `:indeterminate` state #

Here I get a bit more creative so I can provide an animation. A pseudo-element for Chromium is created and a gradient is applied that is animated back and forth for all three browsers.

The custom properties #

Custom properties are great for many things, but one of my favorites is simply giving a name to an otherwise magical looking CSS value. Following is a fairly complex linear-gradient, but with a nice name. Its purpose and use cases can be clearly understood.

progress {
  --_indeterminate-track: linear-gradient(to right,
    var(--_track) 45%,
    var(--_progress) 0%,
    var(--_progress) 55%,
    var(--_track) 0%
  );
  --_indeterminate-track-size: 225% 100%;
  --_indeterminate-track-animation: progress-loading 2s infinite ease;
}

Custom properties will also help the code stay DRY since once again, we can't group these browser-specific selectors together.

The keyframes #

The goal is an infinite animation that goes back and forth. The start and end keyframes will be set in CSS. Only one keyframe is needed, the middle keyframe at 50%, to create an animation that returns to where it started from, over and over again!

@keyframes progress-loading {
  50% {
    background-position: left; 
  }
}

Targeting each browser #

Not every browser allows the creation of pseudo-elements on the <progress> element itself or allows animating the progress bar. More browsers support animating the track than a pseudo-element, so I upgrade from pseudo-elements as a base and into animating bars.

Chromium pseudo-element #

Chromium does allow the pseudo-element: ::after used with a position to cover the element. The indeterminate custom properties are used, and the back and forth animation works very well.

progress:indeterminate::after {
  content: "";
  inset: 0;
  position: absolute;
  background: var(--_indeterminate-track);
  background-size: var(--_indeterminate-track-size);
  background-position: right; 
  animation: var(--_indeterminate-track-animation);
}

Safari progress bar #

For Safari, the custom properties and an animation are applied to the pseudo-element progress bar:

progress:indeterminate::-webkit-progress-bar {
  background: var(--_indeterminate-track);
  background-size: var(--_indeterminate-track-size);
  background-position: right; 
  animation: var(--_indeterminate-track-animation);
}

Firefox progress bar #

For Firefox, the custom properties and an animation are also applied to the pseudo-element progress bar:

progress:indeterminate::-moz-progress-bar {
  background: var(--_indeterminate-track);
  background-size: var(--_indeterminate-track-size);
  background-position: right; 
  animation: var(--_indeterminate-track-animation);
}

JavaScript #

JavaScript plays an important role with the <progress> element. It controls the value sent to the element and ensures enough information is present in the document for screen readers.

const state = {
  val: null
}

The demo offers buttons for controlling the progress; they update state.val and then call a function for updating the DOM.

document.querySelector('#complete').addEventListener('click', e => {
  state.val = 1
  setProgress()
})

`setProgress()` #

This function is where the UI/UX orchestration occurs. Get started by creating a setProgress() function. No parameters are needed because it has access to the state object, progress element, and <main> zone.

const setProgress = () => {
  
}

Setting the loading status on the `<main>` zone #

Depending on whether the progress is complete or not, the related <main> element needs an update to the aria-busy attribute:

const setProgress = () => {
  zone.setAttribute('aria-busy', state.val < 1)
}

Clear attributes if loading amount is unknown #

If the value is unknown or unset, null in this usage, remove the value and aria-valuenow attributes. This will turn the <progress> to indeterminate.

const setProgress = () => {
  zone.setAttribute('aria-busy', state.val < 1)

  if (state.val === null) {
    progress.removeAttribute('aria-valuenow')
    progress.removeAttribute('value')
    progress.focus()
    return
  }
}

Fix JavaScript decimal math issues #

Since I chose to stick with the progress default maximum of 1, the demo increment and decrement functions use decimal math. JavaScript, and other languages, are not always great at that. Here's a roundDecimals() function that will trim the excess off the math result:

const roundDecimals = (val, places) =>
  +(Math.round(val + "e+" + places)  + "e-" + places)

Round the value so it can be presented and is legible:

const setProgress = () => {
  zone.setAttribute('aria-busy', state.val < 1)

  if (state.val === null) {
    progress.removeAttribute('aria-valuenow')
    progress.removeAttribute('value')
    progress.focus()
    return
  }

  const val = roundDecimals(state.val, 2)
  const valPercent = val * 100 + "%"
}

Set value for screen readers and browser state #

The value is used in three locations in the DOM:

The <progress> element's value attribute.
The aria-valuenow attribute.
The <progress> inner text content.

const setProgress = () => {
  zone.setAttribute('aria-busy', state.val < 1)

  if (state.val === null) {
    progress.removeAttribute('aria-valuenow')
    progress.removeAttribute('value')
    progress.focus()
    return
  }

  const val = roundDecimals(state.val, 2)
  const valPercent = val * 100 + "%"

  progress.value = val
  progress.setAttribute('aria-valuenow', valPercent)
  progress.innerText = valPercent
}

Giving the progress focus #

With the values updated, sighted users will see the progress change, but screen reader users are not yet given the announcement of change. Focus the <progress> element and the browser will announce the update!

const setProgress = () => {
  zone.setAttribute('aria-busy', state.val < 1)

  if (state.val === null) {
    progress.removeAttribute('aria-valuenow')
    progress.removeAttribute('value')
    progress.focus()
    return
  }

  const val = roundDecimals(state.val, 2)
  const valPercent = val * 100 + "%"

  progress.value = val
  progress.setAttribute('aria-valuenow', valPercent)
  progress.innerText = valPercent

  progress.focus()
}

Conclusion #

Now that you know how I did it, how would you‽ 🙂

There are certainly a few changes I'd like to make if given another chance. I think there's room to clean up the current component, and room to try and build one without the <progress> element's pseudo-class style limitations. It's worth exploring!

Let's diversify our approaches and learn all the ways to build on the web.

Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Varun KS - source and demo

Building an adaptive favicon

2022-02-09T00:00:00Z

In this post I want to share thinking on how to build an adaptive favicon with SVG. Try the demo.

Browser tabs shown adapting to MacOS system light and dark theme changes. Try the Demo

If you prefer video, here's a YouTube version of this post:

Overview #

A custom favicon is a great way to polish a web project. It displays on desktop browser tabs, and also inside "save for later" readers, other blog posts linking to your site, and more. Traditionally this has been done with the .ico file type, but recently browsers have allowed use of SVG, a vector format. Using progressive enhancement you can serve well supported .ico favicons, and upgrade to an .svg if available.

SVG is able to scale up and down without quality loss, and can potentially be very small in size, they can also have embedded CSS, even embedded media queries. This means if an SVG favicon is used in a reader app or bookmarks bars, there's a chance the user could get a theme relevant (light or dark) icon due to dark preference styles provided inside the SVG. The SVG then adapts using its embedded styling for light and dark user preferences.

Light and dark tabs in each browser providing an overview of the adaptive icon from top to bottom: Safari, Firefox, Chrome.

Markup #

SVG markup is XML using an .svg file type extension which allows it to hold more dynamic types of code.

Start by making `favicon.svg` #

Make a new file called favicon.svg and add the following:

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

</svg>

Here's my SVG file, I've sized the viewBox relevant to my artwork:

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

</svg>

Adding shapes and paths #

Next, add SVG path code. Often this means opening the SVG in a code editor, but that code is generally not human friendly. Here's a great guide that guides you through exporting and optimizing SVG from design tools.

The artwork for this GUI Challenge came from a designer who made it in Adobe Illustrator. I heavily optimized it. I ran it through SVGOMG and then hand-edited the cruft away.

Here's an example of the skull artwork path group from mine, after cleaning it:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 447 428">
  <g id="skull">
    <path id="skull-outline" class="favicon-stroke" stroke-linejoin="round" d="M19.62 188.39A166.62 166.62 0 0 1 186.24 21.77c115.25 0 166.61 74.59 166.61 166.62 0 1.83-.08 3.64-.13 5.46h.13s.68 175.09.68 178.65c0 30.11-16.26 41.67-36.32 41.67-12.7 0-35.22-3.93-36.22-32.69h-.2c-1 28.76-16.81 32.69-36.22 32.69-18 0-32.87-6.78-35.77-32.53-2.9 25.75-17.8 32.53-35.8 32.53-20.06 0-36.32-11.56-36.32-41.67 0-2.48.36-24.88.36-24.88A166.68 166.68 0 0 1 19.62 188.39Z" />
    <path id="eyes-and-nose" d="M180.77 205.76c0 23.64 12.84 42.81 28.68 42.81s28.68-19.17 28.68-42.81-12.84-42.82-28.68-42.82-28.68 19.17-28.68 42.82M275 205.76c0 23.64 12.84 42.81 28.68 42.81s28.68-19.17 28.68-42.81-12.84-42.82-28.68-42.82S275 182.11 275 205.76M264.51 276.85s-29.26 43.53-20.12 49.23c7.07 4.41 20.49-16.71 20.49-16.71s12.82 22.58 16.76 20c16.24-10.71-17.13-52.5-17.13-52.5"/>
    <path id="jawline" class="favicon-stroke" fill="none" stroke-linecap="round" d="M114.92 284.33c22.54-1 22 7 22 62.48" />
  </g>
</svg>

Notice the human readable ID selectors like #eyes-and-nose and classes like .favicon-stroke. These are from my hand editing, in preparation for CSS. Adding classes and ID's is not required for your SVG to be an adaptive favicon.

Link the favicon SVG from HTML #

In the <head> tag of your HTML, after the .ico favicon, add the following:

<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">

As the new icon may look identical to the .ico version verify that it is being used. Open the Network panel of DevTools. Filter by images and search for favicon:

Styles #

Like HTML, you can add a <style> tag to the markup for use against that document scope:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 447 428">
  <style>
    
  </style>
  …
</svg>

The light theme version will be the default coloring of my favicon SVG. The styles I wrote for that were mostly stroke and fill colors:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 447 428">
  <style>
    .favicon-stroke {
      stroke-width: 8px;
      stroke: #8929ff;
    }
    #skull-outline { fill: white }
    #eyes-and-nose, #hat-outline { fill: #8929ff }
    #hat-fill, #hat-bill { fill: #e662e6 }
  </style>
  …
</svg>

Next, the most fun part, styling the dark theme version of your favicon. The styles for that will go into a media query within the style tag:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 447 428">
  <style>
    …
    @media (prefers-color-scheme: dark) {
      /* dark theme styles */
    }
  </style>
  …
</svg>

Mine ended up like this:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 447 428">
  <style>
    …
    @media (prefers-color-scheme: dark) {
      .favicon-stroke { stroke: #343a40 }
      #skull-outline { fill: #adb5bd }
      #hat-outline { fill: #343a40 }
      #eyes-and-nose { fill: #343a40 }
    }
  </style>
  …
</svg>

I chose to swap the bright purple borders for a nice cool dark gray (#343a40), changed the skull bone color from white to a light cool gray (#adb5bd), but left the pink accent hat.

Conclusion #

Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Where I learned of this technique: @tomayac on his blog

Building a theme switch component

2022-01-19T00:00:00Z

In this post I want to share thinking on a way to build a dark and light theme switch component. Try the demo.

Demo button size increased for easy visibility

If you prefer video, here's a YouTube version of this post:

Overview #

A website may provide settings for controlling the color scheme instead of relying entirely on the system preference. This means that users may browse in a mode other than their system preferences. For example, a user's system is in a light theme, but the user prefers the website to display in the dark theme.

There are several web engineering considerations when building this feature. For example, the browser should be made aware of the preference as soon as possible to prevent page color flashes, and the control needs to first sync with the system then allow client-side stored exceptions.

Diagram shows a preview of JavaScript page load and document interaction events to overall show there's 4 paths to setting the theme

Markup #

A <button> should be used for the toggle, as you then benefit from browser-provided interaction events and features, such as click events and focusability.

The button #

The button needs a class for use from CSS and an ID for use from JavaScript. Additionally, since the button content is an icon rather than text, add a title attribute to provide information about the button's purpose. Last, add an [aria-label] to hold the state of the icon button, so screen readers can share the state of the theme to folks who are visually impaired.

<button 
  class="theme-toggle" 
  id="theme-toggle" 
  title="Toggles light & dark" 
  aria-label="auto"
>
  …
</button>

`aria-label` and `aria-live` polite #

To indicate to screen readers that changes to aria-label should be announced, add aria-live="polite" to the button.

<button 
  class="theme-toggle" 
  id="theme-toggle" 
  title="Toggles light & dark" 
  aria-label="auto" 
  aria-live="polite"
>
  …
</button>

This markup addition signals to screen readers to politely, instead of aria-live="assertive", tell the user what changed. In the case of this button, it will announce "light" or "dark" depending on what the aria-label has become.

The scalable vector graphic (SVG) icon #

SVG provides a way to create high-quality, scalable shapes with minimal markup. Interacting with the button can trigger new visual states for the vectors, making SVG great for icons.

The following SVG markup goes inside the <button>:

<svg class="sun-and-moon" aria-hidden="true" width="24" height="24" viewBox="0 0 24 24">
  …
</svg>

aria-hidden has been added to the SVG element so screen readers know to ignore it as it's marked presentational. This is great to do for visual decorations, like the icon inside a button. In addition to the required viewBox attribute on the element, add height and width for similar reasons that images should get inline sizes.

The sun #

The sun graphic consists of a circle and lines which SVG conveniently has shapes for. The <circle> is centered by setting the cx and cy properties to 12, which is half of the viewport size (24), and then given a radius (r) of 6 which sets the size.

<svg class="sun-and-moon" aria-hidden="true" width="24" height="24" viewBox="0 0 24 24">
  <circle class="sun" cx="12" cy="12" r="6" mask="url(#moon-mask)" fill="currentColor" />
</svg>

Additionally, the mask property points to an SVG element's ID, which you will create next, and finally given a fill color that matches the page's text color with currentColor.

The sun beams #

Next, the sunbeam lines are added just below the circle, inside of a group element <g> group.

<svg class="sun-and-moon" aria-hidden="true" width="24" height="24" viewBox="0 0 24 24">
  <circle class="sun" cx="12" cy="12" r="6" mask="url(#moon-mask)" fill="currentColor" />
  <g class="sun-beams" stroke="currentColor">
    <line x1="12" y1="1" x2="12" y2="3" />
    <line x1="12" y1="21" x2="12" y2="23" />
    <line x1="4.22" y1="4.22" x2="5.64" y2="5.64" />
    <line x1="18.36" y1="18.36" x2="19.78" y2="19.78" />
    <line x1="1" y1="12" x2="3" y2="12" />
    <line x1="21" y1="12" x2="23" y2="12" />
    <line x1="4.22" y1="19.78" x2="5.64" y2="18.36" />
    <line x1="18.36" y1="5.64" x2="19.78" y2="4.22" />
  </g>
</svg>

This time, instead of the value of fill being currentColor, each line's stroke is set. The lines plus the circle shapes create a nice sun with beams.

The moon #

To create the illusion of a seamless transition between light (sun) and dark (moon), the moon is an augmentation of the sun icon, using an SVG mask.

<svg class="sun-and-moon" aria-hidden="true" width="24" height="24" viewBox="0 0 24 24">
  <circle class="sun" cx="12" cy="12" r="6" mask="url(#moon-mask)" fill="currentColor" />
  <g class="sun-beams" stroke="currentColor">
    …
  </g>
  <mask class="moon" id="moon-mask">
    <rect x="0" y="0" width="100%" height="100%" fill="white" />
    <circle cx="24" cy="10" r="6" fill="black" />
  </mask>
</svg>

Masks with SVG are powerful, allowing the colors white and black to either remove or include parts of another graphic. The sun icon will be eclipsed by a moon <circle> shape with an SVG mask, simply by moving a circle shape in and out of a mask area.

What happens if CSS doesn’t load? #

It can be nice to test your SVG as if CSS didn't load to ensure the result isn't super large or causing layout issues. The inline height and width attributes on the SVG plus the use of currentColor give minimal style rules for the browser to use if CSS doesn't load. This makes for nice defensive styles against network turbulence.

Layout #

The theme switch component has little surface area, so you don’t need grid or flexbox for layout. Instead, SVG positioning and CSS transforms are used.

Styles #

`.theme-toggle` styles #

The <button> element is the container for the icon shapes and styles. This parent context will hold adaptive colors and sizes to pass down to SVG.

The first task is to make the button a circle and remove the default button styles:

.theme-toggle {
  --size: 2rem;
  
  background: none;
  border: none;
  padding: 0;

  inline-size: var(--size);
  block-size: var(--size);
  aspect-ratio: 1;
  border-radius: 50%;
}

Next, add some interaction styles. Add a cursor style for mouse users. Add touch-action: manipulation for a fast reacting touch experience. Remove the semi-transparent highlight iOS applies to buttons. Last, give the focus state outline some breathing room from the edge of the element:

.theme-toggle {
  --size: 2rem;

  background: none;
  border: none;
  padding: 0;

  inline-size: var(--size);
  block-size: var(--size);
  aspect-ratio: 1;
  border-radius: 50%;

  cursor: pointer;
  touch-action: manipulation;
  -webkit-tap-highlight-color: transparent;
  outline-offset: 5px;
}

The SVG inside of the button needs some styles as well. The SVG should fit the size of the button and, for visual softness, round out the line ends:

.theme-toggle {
  --size: 2rem;

  background: none;
  border: none;
  padding: 0;

  inline-size: var(--size);
  block-size: var(--size);
  aspect-ratio: 1;
  border-radius: 50%;

  cursor: pointer;
  touch-action: manipulation;
  -webkit-tap-highlight-color: transparent;
  outline-offset: 5px;

  & > svg {
    inline-size: 100%;
    block-size: 100%;
    stroke-linecap: round;
  }
}

Adaptive sizing with the `hover` media query #

The icon button size is a bit small at 2rem, which is fine for mouse users but can be a struggle for a coarse pointer like a finger. Make the button meet many touch size guidelines by using a hover media query to specify a size increase.

.theme-toggle {
  --size: 2rem;
  …
  
  @media (hover: none) {
    --size: 48px;
  }
}

Sun and moon SVG styles #

The button holds the interactive aspects of the theme switch component while SVG inside will hold the visual and animated aspects. This is where the icon can be made beautiful and brought to life.

Light theme #

For scale and rotate animations to happen from the center of SVG shapes, set their transform-origin: center center. The adaptive colors provided by the button are used here by the shapes. The moon and sun use the button provided var(--icon-fill) and var(--icon-fill-hover) for their fill, while the sunbeams use the variables for stroke.

.sun-and-moon {
  & > :is(.moon, .sun, .sun-beams) {
    transform-origin: center center;
  }

  & > :is(.moon, .sun) {
    fill: var(--icon-fill);

    @nest .theme-toggle:is(:hover, :focus-visible) > & {
      fill: var(--icon-fill-hover);
    }
  }

  & > .sun-beams {
    stroke: var(--icon-fill);
    stroke-width: 2px;

    @nest .theme-toggle:is(:hover, :focus-visible) & {
      stroke: var(--icon-fill-hover);
    }
  }
}

Dark theme #

The moon styles need to remove the sunbeams, scale up the sun circle and move the circle mask.

.sun-and-moon {
  @nest [data-theme="dark"] & {
    & > .sun {
      transform: scale(1.75);
    }

    & > .sun-beams {
      opacity: 0;
    }

    & > .moon > circle {
      transform: translateX(-7px);

      @supports (cx: 1) {
        transform: translateX(0);
        cx: 17;
      }
    }
  }
}

Notice the dark theme has no color changes or transitions. The parent button component owns the colors, where they're already adaptive within a dark and light context. The transition information should be behind a user's motion preference media query.

Animation #

The button should be functional and stateful but without transitions at this point. The following sections are all about defining how and what transitions.

To make it easy to put transitions and animations behind a user's operating system motion preferences, the PostCSS plugin Custom Media enables usage of the drafted CSS specification for media query variables syntax:

@custom-media --motionOK (prefers-reduced-motion: no-preference);

/* usage example */
@media (--motionOK) {
  .sun {
    transition: transform .5s var(--ease-elastic-3);
  }
}

For unique and easy to use CSS easings, import the easings portion of Open Props:

@import "https://unpkg.com/open-props/easings.min.css";

/* usage example */
.sun {
  transition: transform .5s var(--ease-elastic-3);
}

The sun #

The sun transitions will be more playful than the moon, achieving this effect with bouncy easings. The sunbeams should bounce a small amount as they rotate and the center of the sun should bounce a small amount as it scales.

The default (light theme) styles define the transitions and the dark theme styles define customizations for the transition to light:

.sun-and-moon {
  @media (--motionOK) {
    & > .sun {
      transition: transform .5s var(--ease-elastic-3);
    }

    & > .sun-beams {
      transition: 
        transform .5s var(--ease-elastic-4),
        opacity .5s var(--ease-3)
      ;
    }

    @nest [data-theme="dark"] & {
      & > .sun {
        transform: scale(1.75);
        transition-timing-function: var(--ease-3);
        transition-duration: .25s;
      }

      & > .sun-beams {
        transform: rotateZ(-25deg);
        transition-duration: .15s;
      }
    }
  }
}

In the Animation panel in Chrome DevTools, you can find a timeline for animation transitions. The duration of the total animation, the elements, and the easing timing can be inspected.

Light to dark transition

Dark to light transition

The moon #

The moon light and dark positions are already set, add transition styles inside of the --motionOK media query to bring it to life while respecting the user's motion preferences.

The timing with delay and duration are critical in making this transition clean. If the sun is eclipsed too early, for example, the transition doesn't feel orchestrated or playful, it feels chaotic.

.sun-and-moon {
  @media (--motionOK) {
    & .moon > circle {
      transform: translateX(-7px);
      transition: transform .25s var(--ease-out-5);

      @supports (cx: 1) {
        transform: translateX(0);
        cx: 17;
        transition: cx .25s var(--ease-out-5);
      }
    }

    @nest [data-theme="dark"] & {
      & > .moon > circle {
        transition-delay: .25s;
        transition-duration: .5s;
      }
    }
  }
}

Light to dark transition

Dark to light transition

Prefers reduced motion #

In most GUI Challenges I try to keep some animation, like opacity cross fades, for users who prefer reduced motion. This component felt better with instant state changes however.

JavaScript #

There's a lot of work for JavaScript in this component, from managing ARIA information for screen readers to getting and setting values from local storage.

The page load experience #

It was important that no color flashing occurs on page load. If a user with a dark color scheme indicates they preferred light with this component, then reloaded the page, at first the page would be dark then it would flash to light. Preventing this meant running a small amount of blocking JavaScript with the goal to set the HTML attribute data-theme as early as possible.

<script src="./theme-toggle.js"></script>

To achieve this, a plain <script> tag in the document <head> is loaded first, before any CSS or <body> markup. When the browser encounters an unmarked script like this, it runs the code and executes it before the rest of the HTML. Using this blocking moment sparingly, it's possible to set the HTML attribute before the main CSS paints the page, thus preventing a flash or colors.

The JavaScript first checks for the user's preference in local storage and fallback to check the system preference if nothing is found in storage:

const storageKey = 'theme-preference'

const getColorPreference = () => {
  if (localStorage.getItem(storageKey))
    return localStorage.getItem(storageKey)
  else
    return window.matchMedia('(prefers-color-scheme: dark)').matches
      ? 'dark'
      : 'light'
}

A function to set the user's preference in local storage is parsed next:

const setPreference = () => {
  localStorage.setItem(storageKey, theme.value)
  reflectPreference()
}

Followed by a function to modify the document with the preferences.

const reflectPreference = () => {
  document.firstElementChild
    .setAttribute('data-theme', theme.value)

  document
    .querySelector('#theme-toggle')
    ?.setAttribute('aria-label', theme.value)
}

An important thing to note at this point is the HTML document parsing state. The browser doesn't know about the "#theme-toggle" button yet, as the <head> tag hasn't been completely parsed. However, the browser does have a document.firstElementChild , aka the <html> tag. The function attempts to set both to keep them in sync, but on first run will only be able to set the HTML tag. The querySelector won't find anything at first and the optional chaining operator ensures no syntax errors when it's not found and the setAttribute function is attempted to be invoked.

Next, that function reflectPreference() is immediately called so the HTML document has its data-theme attribute set:

reflectPreference()

The button still needs the attribute, so wait for the page load event, then it will be safe to query, add listeners and set attributes on:

window.onload = () => {
  // set on load so screen readers can get the latest value on the button
  reflectPreference()

  // now this script can find and listen for clicks on the control
  document
    .querySelector('#theme-toggle')
    .addEventListener('click', onClick)
}

The toggling experience #

When the button is clicked, the theme needs to be swapped, in JavaScript memory and in the document. The current theme value will need to be inspected and a decision made about its new state. Once the new state is set, save it and update the document:

const onClick = () => {
  theme.value = theme.value === 'light'
    ? 'dark'
    : 'light'

  setPreference()
}

Synchronizing with the system #

Unique to this theme switch is synchronization with the system preference as it changes. If a user changes their system preference while a page and this component are visible, the theme switch will change to match the new user preference, as if the user had interacted with the theme switch at the same time it did the system switch.

Achieve this with JavaScript and a matchMedia event listening for changes to a media query:

window
  .matchMedia('(prefers-color-scheme: dark)')
  .addEventListener('change', ({matches:isDark}) => {
    theme.value = isDark ? 'dark' : 'light'
    setPreference()
  })

Changing the MacOS system preference changes the theme switch state

Conclusion #

Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Building Designcember

2021-12-28T00:00:00Z

In the spirit of December and the many calendars that folks use to countdown and celebrate, we wanted to highlight web content from the community and the Chrome team. Every day, we highlighted one piece of UI-development and design-related content, totaling 31 highlights, among which were 26 new demo sites, tools, announcements, podcasts, videos, articles, and case studies.

See the full experience at designcember.com.

Overview #

Our goal was to deliver an accessible, whimsical, modern, and responsive web experience in as few bytes as possible. We wanted to highlight new responsive APIs like container queries, and include a beautiful example of a dark mode in a design-focused and asset-heavy website. To achieve this, we compressed files, offered multiple formats, used build tools optimized for static site generation, shipped a new polyfill, and more.

Starting with whimsy #

The idea around the Designcember calendar site was to function as a showcase for all the work we wanted to spotlight throughout the month of December, while acting like a demo site itself. We decided to build a responsive apartment building that could get taller and more narrow, or shorter and wider, with windows that rearranged themselves within the frame. Each window represented one day (and thus, one piece of content). We worked with illustrator Alice Lee to bring our vision to life.

Alice was inspiring, sharing processes and sketches that were exciting even in their early concepts. While she worked on the art, we hacked on the architecture. Early discussions were around the macro layout, the building, and its windows. How would the windows adapt to one, two, or three columns as more viewport space became available? How far could they shrink or stretch? What would the maximum size of the building be? How much would the windows shift?

Here's a preview of a responsive prototype using grid-auto-flow: dense showing how windows could be auto placed by the grid algorithm. We quickly realized that while aspect-ratio grids performed beautifully to showcase art, they didn’t provide an opportunity to let the windows grow and shrink into non-uniform available space and showcase the power of container queries.

Check out this demo on CodePen.

Once the general grid was relatively stable and communicated a sense of direction for the responsiveness of the building and its windows, we could focus on a single window. Some windows stretched, shrank, squeezed, grew, and re-composed themselves more than others in the grid.

Each window would need to handle a certain amount of resize turbulence. Below is a prototype of a window demonstrating its responsiveness to turbulence, showing how much we could expect each interactive window to adjust.

Window animation with spritesheets #

Some windows have animations to bring extra interaction to the experience. The animations are hand-drawn, frame by frame, in Photoshop. Each frame is exported, turned into a spritesheet with this spritesheet generator, then optimized with Squoosh. The CSS animation then uses background-position-x and animation-timing-function as shown in the following example.

.una
  background: url("/day1/una_sprite.webp") 0% 0%;
  background-size: 400% auto;
}

.day:is(:hover, :focus-within) .una {
  animation: una-wave .5s steps(1) alternate infinite;
}

@keyframes una-wave {
  0%  { background-position-x: 0%; }
  25% { background-position-x: 300%; }
  50% { background-position-x: 200%; }
  75% { background-position-x: 100%; }
}

Some animations, such as the piggy bank of day six, were step-based CSS animations. We achieved this effect with a similar technique, using steps(), with the difference being that the keyframes were CSS transform positions instead of background positions.

CSS masking #

Some windows had unique shapes. We used masks and aspect-ratio to help make a scalable, uniquely shaped, and adaptive window.

To create a mask, such as this one for window eight, some classic Photoshop skills were needed, plus a little bit of knowledge about how masks on the web work. Let's look at the window for day eight.

To become a mask, the inner four leaf clover type shape has to be isolated as its own shape and filled in the color white. White tells the CSS what content stays, and everything outside the white won't. In Photoshop, the inside of the window was selected, feathered 1px (to remove aliasing issues), then filled white and exported at the same height and width as the window frame. This way the frame and the mask could be layered directly on top of each other, showing the inner content within the frame as expected.

Once complete, the contents of the window could be modified and would always appear to stay within the custom frame. The following image shows the dark mode version of the window, with a different background gradient and a glow CSS filter applied to the light.

Masking also supports responsive container-query based windows. In window nine, there’s a character who is hidden behind a mask until the window is in a more narrow size. To make sure the user can’t adjust the image out of frame, Alice completed the full character for us. The character is masked within the window, but the plants are not, so another challenge we dealt with was layering masked elements with unmasked layers, and ensuring that they all scaled well together.

The following image shows what it looks like without the mask on the window and character.

Squooshing the art #

To maintain the fidelity of the illustration and ensure high definition screens wouldn't get a blurry user experience, Alice worked at a 3x pixel ratio. The plan was to use imgix and serve optimized images and formats on their server, but we found that manual tweaking with the Squoosh tool could save us 50% or more.

Illustration has unique challenges for compression, especially the brush stroke and transparent rough edge style Alice used. We chose to Squoosh each 3x Photoshop exported png image, to a smaller png, webp, and avif. Each file type has its own special compression abilities, and it took compressing more than 50 images to find some common optimization settings.

The Squoosh CLI became crucial with over 200 images to optimize—doing all those manually would have taken days. Once we had the common optimization settings, we provided them as command line instructions and batch processed entire folders of PNG images into their WebP and AVIF compressed counterparts.

Here's an example AVIF CLI squoosh command used:

npx @squoosh/cli --quant '{"enabled":true,"zx":0,"maxNumColors":256,"dither":1}' --avif '{"cqLevel":19,"cqAlphaLevel":17,"subsample":1,"tileColsLog2":0,"tileRowsLog2":0,"speed":6,"chromaDeltaQ":false,"sharpness":5,"denoiseLevel":0,"tune":0}' image-1.png image-2.png image-3.png

With optimized artwork checked into the repo, we could start loading them from HTML:

<picture>
  <source srcset="/day1/inner-frame.avif" type="image/avif">
  <source srcset="/day1/inner-frame.webp" type="image/webp">
  <img alt="" decoding="async" role="presentation" src="/day1/inner-frame.png">
</picture>

It was repetitive to write the picture source code, so we made an Astro component to embed images with one line of code.

<Pic filename="day1/inner-frame" role="presentation" />

Much of the experience of Designcember is through the art and interactive windows. It was important to us that a keyboard user could use the site and peek into windows, and that screen reader users get a nice narrated experience.

For example, when embedding the images we used role="presentation" to mark the image as presentational for screen readers. We felt that a user experience of between 5 and 12 fractured alt descriptions was going to be a poor experience. So, we marked the images as presentational and provided an overall window narration. Moving through the windows on a screen reader then has a nice narrative feeling, which we hoped would help deliver the whimsy and fun the site wants to share.

The following video shows a demo of the keyboard experience. Tab, enter, spacebar, and escape keys are all used to orchestrate focus to and from the window popups and the windows.

The screen reader experience has special ARIA attributes that bring clarity to the content. For example, the links for the days only say "one" or "two", but with some added ARIA, they are announced as "Day one" and "Day two." Furthermore, all the images are summarized in a single label so each window has a description.

Astro, static first, component-driven site generator #

Astro made it easy for the team to work together on the site. The component model was familiar to both Angular and React developers, while the scoped classname style system helped each developer know their work on a window wouldn't conflict with anyone else.

Days as components #

Each day was a component that fetched status from a build time data store. This let us run template logic before the HTML reached the browser. The logic would determine if the day should show its tooltip or not, as inactive days don't have pop ups.

Builds are run every hour and the build time data store would unlock a new day when the build server was past midnight. These self-updating and self-sufficient little systems keep the site up to date.

Scoped styles and Open Props #

Astro scopes styles written inside its component model, which made distributing the workload amongst many team members easier, and also made using Open Props fun. The Open Props normalize.css styles came in handy with the adaptive (light and dark) theme, as well as helping wrangle content like paragraphs and headers.

As early adopters of Astro, we ran into a few snags with PostCSS. For example, we weren't able to update to the latest Astro version due to too many build issues. More time could be spent here, optimizing the build and developer workflows.

Flexible containers #

Some windows grow and shrink, maintaining aspect ratio to preserve their art. We used some other windows to showcase the power of component-based architecture with container queries. Container queries meant windows could own their individual responsive styling information and readjust based on their own sizes. Some windows went from narrow to wide and needed to adjust the size of the media within them, as well as the placement of that media.

As more space becomes available for a window, we could adapt the size or child elements of the window to fit. Turned out that in order to fulfill the adaptive windows, container queries wouldn't just be fun to showcase, they'd be required and drastically simplify orchestrating certain layouts.

.day {
  container: inline-size;
}

.day > .pane {
  min-block-size: 250px;

  @container (min-width: 220px) {
    min-block-size: 300px;
  }

  @container (min-width: 260px) {
    min-block-size: 310px;
  }

  @container (min-width: 360px) {
    min-block-size: 450px;
  }
}

This approach is different from maintaining an aspect ratio. It offers more control and more opportunities. At a certain size, many children shift around to adapt to a new layout.

Container queries also allowed us to support block-direction (vertical) containment, so as a window grew in length, we could adjust its styles to fit appropriately. This is seen in the height-based queries, which we used standalone, and in addition to width-based queries:

.person {
  place-self: flex-end;
  margin-block: 25% 50%;
  margin-inline-start: -15%;
  z-index: var(--layer-1);

  @container (max-height: 350px) and (max-width: 425px) {
    place-self: center flex-end;
    inline-size: 50%;
    inset-block-end: -15%;
    margin-block-start: -2%;
    margin-block-end: -25%;
    z-index: var(--layer-2);
  }
}

We also used container queries to show and hide detail as the art became increasingly crowded at smaller sizes, and emptier at wider sizes. Window nine is a great example of where this came into play:

Cross-browser support #

To create a great modern cross-browser experience, especially for experimental APIs like container queries, we need a great polyfill. We sent a call out to our team, and Surma spearheaded a build for a new container query polyfill. The polyfill relies on ResizeObserver, MutationObserver and the CSS :is() function. Therefore, all modern browsers support the polyfill, specifically Chrome and Edgefrom version 88, Firefox from version 78, and Safari from version 14. Using the polyfill allows any of the following syntaxes:

/* These are all equivalent */
@container (min-width: 200px) {
  /* ... */
}
@container (width >= 200px) {
  /* ... */
}
@container size(width >= 200px) {
  /* ... */
}

Dark mode #

One last touch that was essential for the Designcember website was a beautiful dark theme. We wanted to show how you could use art itself to be an active participant in creating a great dark mode experience. For this, we adjusted the background styles of each window itself programmatically, and used as much CSS as made sense when creating the window art. Most of the backgrounds were CSS gradients, so that it would be easier to adjust their color values. We then layered the art on top of these.

Other Easter eggs #

Personal touches #

We added a few personal touches to the page to give the site more personality. The first was the cast of characters, drawn from inspiration from our team. We also included a throwback-style cursor on inactive days and played around with the favicon style.

Functional touches #

One of the additional functional touches is a "Jump to Today" functionality, with a bird that sits on top of the building. Clicking or hitting enter on this bird jumps you down on the page to the current day of the month, so you can quickly get to the latest launches.

Designcember.com also has a special print stylesheet where we're essentially serving a specific image that works best on 8.5" x 11" paper so you can print the calendar out yourself and stay festive all year long.

Una holding a large print of the calendar.

All in all, a ton of work went into creating a fun, whimsical modern web experience to celebrate UI development all month long in December. We hope you enjoyed it!

Building a toast component

2021-12-08T00:00:00Z

In this post I want to share thinking on how to build a toast component. Try the demo.

Demo

If you prefer video, here's a YouTube version of this post:

Overview #

Toasts are non-interactive, passive, and asynchronous short messages for users. Generally they are used as an interface feedback pattern for informing the user about the results of an action.

Interactions #

Toasts are unlike notifications, alerts and prompts because they're not interactive; they're not meant to be dismissed or persist. Notifications are for more important information, synchronous messaging that requires interaction, or system level messages (as opposed to page level). Toasts are more passive than other notice strategies.

Markup #

The <output> element is a good choice for the toast because it is announced to screen readers. Correct HTML provides a safe base for us to enhance with JavaScript and CSS, and there will be lots of JavaScript.

A toast #

<output class="gui-toast">Item added to cart</output>

It can be more inclusive by adding role="status". This provides a fallback if the browser doesn't give <output> elements the implicit role per the spec.

<output role="status" class="gui-toast">Item added to cart</output>

A toast container #

More than one toast can be shown at a time. In order to orchestrate multiple toasts, a container is used. This container also handles the position of the toasts on the screen.

<section class="gui-toast-group">
  <output role="status">Wizard Rose added to cart</output>
  <output role="status">Self Watering Pot added to cart</output>
</section>

Layouts #

I chose to pin toasts to the inset-block-end of the viewport, and if more toasts are added, they stack from that screen edge.

GUI container #

The toasts container does all the layout work for presenting toasts. It's fixed to the viewport and uses the logical property inset to specify which edges to pin to, plus a little bit of padding from the same block-end edge.

.gui-toast-group {
  position: fixed;
  z-index: 1;
  inset-block-end: 0;
  inset-inline: 0;
  padding-block-end: 5vh;
}

In addition to positioning itself within the viewport, the toast container is a grid container that can align and distribute toasts. Items are centered as a group with justify-content and individually centered with justify-items. Throw in a little bit of gap so toasts don't touch.

.gui-toast-group {
  display: grid;
  justify-items: center;
  justify-content: center;
  gap: 1vh;
}

GUI Toast #

An individual toast has some padding, some softer corners with border-radius, and a min() function to aid in mobile and desktop sizing. The responsive size in the following CSS prevents toasts growing wider than 90% of the viewport or 25ch.

.gui-toast {
  max-inline-size: min(25ch, 90vw);
  padding-block: .5ch;
  padding-inline: 1ch;
  border-radius: 3px;
  font-size: 1rem;
}

Styles #

With layout and positioning set, add CSS that helps with adapting to user settings and interactions.

Toast container #

Toasts are not interactive, tapping or swiping on them doesn't do anything, but they do currently consume pointer events. Prevent the toasts from stealing clicks with the following CSS.

.gui-toast-group {
  pointer-events: none;
}

GUI Toast #

Give the toasts a light or dark adaptive theme with custom properties, HSL and a preference media query.

.gui-toast {
  --_bg-lightness: 90%;

  color: black;
  background: hsl(0 0% var(--_bg-lightness) / 90%);
}

@media (prefers-color-scheme: dark) {
  .gui-toast {
    color: white;
    --_bg-lightness: 20%;
  }
}

Animation #

A new toast should present itself with an animation as it enters the screen. Accommodating reduced motion is done by setting translate values to 0 by default, but updating the motion value to a length in a motion preference media query . Everyone gets some animation, but only some users have the toast travel a distance.

Here are the keyframes used for the toast animation. CSS will be controlling the entrance, the wait, and the exit of the toast, all in one animation.

@keyframes fade-in {
  from { opacity: 0 }
}

@keyframes fade-out {
  to { opacity: 0 }
}

@keyframes slide-in {
  from { transform: translateY(var(--_travel-distance, 10px)) }
}

The toast element then sets up the variables and orchestrates the keyframes.

.gui-toast {
  --_duration: 3s;
  --_travel-distance: 0;

  will-change: transform;
  animation: 
    fade-in .3s ease,
    slide-in .3s ease,
    fade-out .3s ease var(--_duration);
}

@media (prefers-reduced-motion: no-preference) {
  .gui-toast {
    --_travel-distance: 5vh;
  }
}

JavaScript #

With the styles and screen reader accessible HTML ready, JavaScript is needed to orchestrate the creation, addition, and destruction of toasts based on user events. The developer experience of the toast component should be minimal and easy to get started with, like this:

import Toast from './toast.js'

Toast('My first toast')

Creating the toast group and toasts #

When the toast module loads from JavaScript, it must create a toast container and add it to the page. I chose to add the element before body, this will make z-index stacking issues unlikely as the container is above the container for all the body elements.

const init = () => {
  const node = document.createElement('section')
  node.classList.add('gui-toast-group')

  document.firstElementChild.insertBefore(node, document.body)
  return node
}

The init() function is called internally to the module, stashing the element as Toaster:

const Toaster = init()

Toast HTML element creation is done with the createToast() function. The function requires some text for the toast, creates an <output> element, adorns it with some classes and attributes, sets the text, and returns the node.

const createToast = text => {
  const node = document.createElement('output')
  
  node.innerText = text
  node.classList.add('gui-toast')
  node.setAttribute('role', 'status')

  return node
}

Managing one or many toasts #

JavaScript now adds a container to the document for containing toasts and is ready to add created toasts. The addToast() function orchestrates handling one or many toasts. First checking the number of toasts, and whether motion is ok, then using this information to either append the toast or do some fancy animation so the other toasts appear to "make room" for the new toast.

const addToast = toast => {
  const { matches:motionOK } = window.matchMedia(
    '(prefers-reduced-motion: no-preference)'
  )

  Toaster.children.length && motionOK
    ? flipToast(toast)
    : Toaster.appendChild(toast)
}

When adding the first toast, Toaster.appendChild(toast) adds a toast to the page triggering the CSS animations: animate in, wait 3s, animate out. flipToast() is called when there are existing toasts, employing a technique called FLIP by Paul Lewis. The idea is to calculate the difference in positions of the container, before and after the new toast has been added. Think of it like marking where the Toaster is now, where it's going to be, then animating from where it was to where it is.

const flipToast = toast => {
  // FIRST
  const first = Toaster.offsetHeight

  // add new child to change container size
  Toaster.appendChild(toast)

  // LAST
  const last = Toaster.offsetHeight

  // INVERT
  const invert = last - first

  // PLAY
  const animation = Toaster.animate([
    { transform: `translateY(${invert}px)` },
    { transform: 'translateY(0)' }
  ], {
    duration: 150,
    easing: 'ease-out',
  })
}

CSS grid does the lifting of the layout. When a new toast is added, grid puts it at the start and spaces it with the others. Meanwhile, a web animation is used to animate the container from the old position.

Putting all the JavaScript together #

When Toast('my first toast') is called, a toast is created, added to the page (maybe even the container is animated to accommodate the new toast), a promise is returned and the created toast is watched for CSS animation completion (the three keyframe animations) for promise resolution.

const Toast = text => {
  let toast = createToast(text)
  addToast(toast)

  return new Promise(async (resolve, reject) => {
    await Promise.allSettled(
      toast.getAnimations().map(animation => 
        animation.finished
      )
    )
    Toaster.removeChild(toast)
    resolve() 
  })
}

I felt the confusing part of this code is in the Promise.allSettled() function and toast.getAnimations() mapping. Since I used multiple keyframe animations for the toast, to confidently know all of them have finished, each must be requested from JavaScript and each of their finished promises observed for completion. allSettled does that work for us, resolving itself as complete once all of its promises have been fulfilled. Using await Promise.allSettled() means the next line of code can confidently remove the element and assume the toast has completed its lifecycle. Finally, calling resolve() fulfills the high level Toast promise so developers can clean up or do other work once the toast has shown.

export default Toast

Last, the Toast function is exported from the module, for other scripts to import and use.

Using the Toast component #

Using the toast, or the toast's developer experience, is done by importing the Toast function and calling it with a message string.

import Toast from './toast.js'

Toast('Wizard Rose added to cart')

If the developer wants to do clean up work or whatever, after the toast has shown, they can use async and await.

import Toast from './toast.js'

async function example() {
  await Toast('Wizard Rose added to cart')
  console.log('toast finished')
}

Conclusion #

Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

@_developit with HTML/CSS/JS: demo & code
Joost van der Schee with HTML/CSS/JS: demo & code

Building a 3D game menu component

2021-11-10T00:00:00Z

In this post I want to share thinking on a way to build a 3D game menu component. Try the demo.

Demo

If you prefer video, here's a YouTube version of this post:

Overview #

Video games often present users with a creative and unusual menu, animated and in 3D space. It's popular in new AR/VR games to make the menu appear to be floating in space. Today we'll be recreating the essentials of this effect but with the added flair of an adaptive color scheme and accommodations for users who prefer reduced motion.

HTML #

A game menu is a list of buttons. The best way to represent this in HTML is as follows:

<ul class="threeD-button-set">
  <li><button>New Game</button></li>
  <li><button>Continue</button></li>
  <li><button>Online</button></li>
  <li><button>Settings</button></li>
  <li><button>Quit</button></li>
</ul>

A list of buttons will announce itself well to screen reader technologies and works without JavaScript or CSS.

CSS #

Styling the button list breaks down into the following high level steps:

Setting up custom properties.
A flexbox layout.
A custom button with decorative pseudo-elements.
Placing elements into 3D space.

Overview of custom properties #

Custom properties help disambiguate values by giving meaningful names to otherwise random-looking values, avoiding repeated code and sharing values amongst children.

Below are media queries saved as CSS variables, also known as custom media. These are global and will be used throughout various selectors to keep code concise and legible. The game menu component uses motion preferences, system color scheme, and color range capabilities of the display.

@custom-media --motionOK (prefers-reduced-motion: no-preference);
@custom-media --dark (prefers-color-scheme: dark);
@custom-media --HDcolor (dynamic-range: high);

The following custom properties manage the color scheme and hold mouse positional values for making the game menu interactive to hover. Naming custom properties helps code legibility as it reveals the use case for the value or a friendly name for the result of the value.

.threeD-button-set {
  --y:;
  --x:;
  --distance: 1px;
  --theme: hsl(180 100% 50%);
  --theme-bg: hsl(180 100% 50% / 25%);
  --theme-bg-hover: hsl(180 100% 50% / 40%);
  --theme-text: white;
  --theme-shadow: hsl(180 100% 10% / 25%);

  --_max-rotateY: 10deg;
  --_max-rotateX: 15deg;
  --_btn-bg: var(--theme-bg);
  --_btn-bg-hover: var(--theme-bg-hover);
  --_btn-text: var(--theme-text);
  --_btn-text-shadow: var(--theme-shadow);
  --_bounce-ease: cubic-bezier(.5, 1.75, .75, 1.25);

  @media (--dark) {
    --theme: hsl(255 53% 50%);
    --theme-bg: hsl(255 53% 71% / 25%);
    --theme-bg-hover: hsl(255 53% 50% / 40%);
    --theme-shadow: hsl(255 53% 10% / 25%);
  }

  @media (--HDcolor) {
    @supports (color: color(display-p3 0 0 0)) {
      --theme: color(display-p3 .4 0 .9);
    }
  }
}

Light and dark theme background conic backgrounds #

The light theme has a vibrant cyan to deeppink conic gradient while the dark theme has a dark subtle conic gradient. To see more about what can be done with conic gradients, see conic.style.

html {
  background: conic-gradient(at -10% 50%, deeppink, cyan);

  @media (--dark) {
    background: conic-gradient(at -10% 50%, #212529, 50%, #495057, #212529);
  }
}

Demonstration of background changing between light and dark color preferences.

Enabling 3D perspective #

For elements to exist in the 3D space of a web page, a viewport with perspective needs to be initialized. I chose to put the perspective on the body element and used viewport units to create the style I liked.

body {
  perspective: 40vw;
}

This is the type of impact perspective can have.

Styling the `<ul>` button list #

This element is responsible for the overall button list macro layout as well as being an interactive and 3D floating card. Here's a way to achieve that.

Button group layout #

Flexbox can manage the container layout. Change the default direction of flex from rows to columns with flex-direction and ensure each item is the size of its contents by changing from stretch to start for align-items.

.threeD-button-set {
  /* remove <ul> margins */
  margin: 0;

  /* vertical rag-right layout */
  display: flex;
  flex-direction: column;
  align-items: flex-start;
  gap: 2.5vh;
}

Next, establish the container as a 3D space context and set up CSS clamp() functions to ensure the card doesn't rotate beyond legible rotations. Notice that the middle value for the clamp is a custom property, these --x and --y values will be set from JavaScript upon mouse interaction later.

.threeD-button-set {
  …

  /* create 3D space context */
  transform-style: preserve-3d;

  /* clamped menu rotation to not be too extreme */
  transform:
    rotateY(
      clamp(
        calc(var(--_max-rotateY) * -1),
        var(--y),
        var(--_max-rotateY)
      )
    )
    rotateX(
      clamp(
        calc(var(--_max-rotateX) * -1),
        var(--x),
        var(--_max-rotateX)
      )
    )
  ;
}

Next, if motion is OK with the visiting user, add a hint to the browser that this item's transform will be constantly changing with will-change. Additionally, enable interpolation by setting a transition on transforms. This transition will occur when the mouse interacts with the card, enabling smooth transitions to rotation changes. The animation is a constant running animation that demonstrates the 3D space the card is within, even if a mouse can't or isn't interacting with the component.

@media (--motionOK) {
  .threeD-button-set {
    /* browser hint so it can be prepared and optimized */
    will-change: transform;

    /* transition transform style changes and run an infinite animation */
    transition: transform .1s ease;
    animation: rotate-y 5s ease-in-out infinite;
  }
}

The rotate-y animation only sets the middle keyframe at 50% since the browser will default 0% and 100% to the default style of the element. This is shorthand for animations that alternate, needing to begin and end at the same position. It's a great way to articulate infinite alternating animations.

@keyframes rotate-y {
  50% {
    transform: rotateY(15deg) rotateX(-6deg);
  }
}

Styling the `<li>` elements #

Each list item (<li>) contains the button and its border elements. The display style is changed so the item doesn't show a ::marker. The position style is set to relative so the upcoming button pseudo-elements can position themselves within the full area the button consumes.

.threeD-button-set > li {
  /* change display type from list-item */
  display: inline-flex;

  /* create context for button pseudos */
  position: relative;

  /* create 3D space context */
  transform-style: preserve-3d;
}

Styling the `<button>` elements #

Styling buttons can be tough work, there's a lot of states and interaction types to account for. These buttons get complex quickly due to balancing pseudo-elements, animations and interactions.

Initial `<button>` styles #

Below are the foundational styles that will support the other states.

.threeD-button-set button {
  /* strip out default button styles */
  appearance: none;
  outline: none;
  border: none;

  /* bring in brand styles via props */
  background-color: var(--_btn-bg);
  color: var(--_btn-text);
  text-shadow: 0 1px 1px var(--_btn-text-shadow);

  /* large text rounded corner and padded*/
  font-size: 5vmin;
  font-family: Audiowide;
  padding-block: .75ch;
  padding-inline: 2ch;
  border-radius: 5px 20px;
}

Button pseudo-elements #

The borders of the button aren't traditional borders, they're absolute position pseudo-elements with borders.

These elements are crucial in showcasing the 3D perspective that's been established. One of these pseudo-elements will be pushed away from the button, and one will be pulled closer to the user. The effect is most noticeable in the top and bottom buttons.

.threeD-button button {
  …

  &::after,
  &::before {
    /* create empty element */
    content: '';
    opacity: .8;

    /* cover the parent (button) */
    position: absolute;
    inset: 0;

    /* style the element for border accents */
    border: 1px solid var(--theme);
    border-radius: 5px 20px;
  }

  /* exceptions for one of the pseudo elements */
  /* this will be pushed back (3x) and have a thicker border */
  &::before {
    border-width: 3px;

    /* in dark mode, it glows! */
    @media (--dark) {
      box-shadow:
        0 0 25px var(--theme),
        inset 0 0 25px var(--theme);
    }
  }
}

3D transform styles #

Below transform-style is set to preserve-3d so the children can space themselves out on the z axis. The transform is set to the --distance custom property, which will be increased on hover and focus.

.threeD-button-set button {
  …

  transform: translateZ(var(--distance));
  transform-style: preserve-3d;

  &::after {
    /* pull forward in Z space with a 3x multiplier */
    transform: translateZ(calc(var(--distance) / 3));
  }

  &::before {
    /* push back in Z space with a 3x multiplier */
    transform: translateZ(calc(var(--distance) / 3 * -1));
  }
}

Conditional animation styles #

If the user is OK with motion, the button hints to the browser that the transform property should be ready for change and a transition is set for transform and background-color properties. Notice the difference in duration, I felt it made for a nice subtle staggered effect.

.threeD-button-set button {
  …

  @media (--motionOK) {
    will-change: transform;
    transition:
      transform .2s ease,
      background-color .5s ease
    ;

    &::before,
    &::after {
      transition: transform .1s ease-out;
    }

    &::after    { transition-duration: .5s }
    &::before { transition-duration: .3s }
  }
}

Hover and focus interaction styles #

The goal of the interaction animation is to spread the layers that made up the flat appearing button. Accomplish this by setting the --distance variable, initially to 1px. The selector shown in the following code example checks to see if the button is being hovered or focused by a device that should see a focus indicator, and not being activated. If so it applies CSS to do the following:

Apply the hover background color.
Increase the distance .
Add a bounce ease effect.
Stagger the pseudo-element transitions.

.threeD-button-set button {
  …

  &:is(:hover, :focus-visible):not(:active) {
    /* subtle distance plus bg color change on hover/focus */
    --distance: 15px;
    background-color: var(--_btn-bg-hover);

    /* if motion is OK, setup transitions and increase distance */
    @media (--motionOK) {
      --distance: 3vmax;

      transition-timing-function: var(--_bounce-ease);
      transition-duration: .4s;

      &::after  { transition-duration: .5s }
      &::before { transition-duration: .3s }
    }
  }
}

The 3D perspective was still really neat for the reduced motion preference. The top and bottom elements show the effect in a nice subtle way.

Small enhancements with JavaScript #

The interface is usable from keyboards, screen readers, gamepads, touch and a mouse already, but we can add some light touches of JavaScript to ease a couple of scenarios.

Supporting arrow keys #

The tab key is a fine way to navigate the menu but I'd expect the directional pad or joysticks to move focus on a gamepad. The roving-ux library often used for GUI Challenge interfaces will handle arrow keys for us. The below code tells the library to trap focus within .threeD-button-set and forward the focus to the button children.

import {rovingIndex} from 'roving-ux'

rovingIndex({
  element: document.querySelector('.threeD-button-set'),
  target: 'button',
})

Mouse parallax interaction #

Tracking the mouse and having it tilt the menu is intended to mimic AR and VR video game interfaces, where instead of a mouse you may have a virtual pointer. It can be fun when elements are hyper aware of the pointer.

Since this is a small extra feature, we'll put the interaction behind a query of the user's motion preference. Also, as part of setup, store the button list component into memory with querySelector and cache the element's bounds into menuRect. Use these bounds to determine the rotate offset applied to the card based on mouse position.

const menu = document.querySelector('.threeD-button-set')
const menuRect = menu.getBoundingClientRect()

const { matches:motionOK } = window.matchMedia(
  '(prefers-reduced-motion: no-preference)'
)

Next, we need a function that accepts the mouse x and y positions and return a value we can use to rotate the card. The following function uses the mouse position to detemine which side of the box it's inside of and by how much. The delta is returned from the function.

const getAngles = (clientX, clientY) => {
  const { x, y, width, height } = menuRect

  const dx = clientX - (x + 0.5 * width)
  const dy = clientY - (y + 0.5 * height)

  return {dx,dy}
}

Lastly, watch the mouse move, pass the position to our getAngles() function and use the delta values as custom property styles. I divided by 20 to pad the delta and make it less twitchy, there may be a better way to do that. If you remember from the beginning, we put the --x and --y props in the middle of a clamp() function, this prevents the mouse position from overly rotating the card into an illegible position.

if (motionOK) {
  window.addEventListener('mousemove', ({target, clientX, clientY}) => {
    const {dx,dy} = getAngles(clientX, clientY)

    menu.attributeStyleMap.set('--x', `${dy / 20}deg`)
    menu.attributeStyleMap.set('--y', `${dx / 20}deg`)
  })
}

Translations and directions #

There was one gotcha when testing out the game menu in other writing modes and languages.

<button> elements have an !important style for writing-mode in the user agent stylesheet. This meant the game menu HTML needed to change to accommodate the desired design. Changing the button list to a list of links enables logical properties to change the menu direction, as <a> elements don't have a browser supplied !important style.

Conclusion #

Now that you know how I did it, how would you‽ 🙂 Can you add accelerometer interaction to the menu, so tiling your phone rotates the menu? Can we improve the no motion experience?

Let's diversify our approaches and learn all the ways to build on the web. Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Nothing to see here yet!

Building a multi-select component

2021-10-13T00:00:00Z

In this post I want to share thinking on a way to build a multi-select component. Try the demo.

Demo

If you prefer video, here's a YouTube version of this post:

Overview #

Users are often presented with items, sometimes lots of items, and in these cases it can be a good idea to provide a way to reduce the list to prevent choice overload. This blog post explores filtering UI as a way to reduce choices. It does this by presenting item attributes that users can select or deselect, reducing results and therefore reducing choice overload.

Interactions #

The goal is to enable swift traversal of filter options for all users and their varying input types. This will be delivered with an adaptable and responsive pair of components. A traditional sidebar of checkboxes for desktop, keyboard and screen readers, and a <select multiple> for touch users.

This decision to use built-in multiselect for touch, and not for desktop, saves work and creates work, but I believe delivers appropriate experiences with less code debt than building the entire responsive experience in one component.

Touch #

The touch component saves on space and helps user interaction accuracy on mobile. It saves space by collapsing an entire sidebar of checkboxes into a <select> built-in overlay touch experience. It helps input accuracy by showing a large touch overlay experience provided by the system.

Keyboard and gamepad #

Below is a demonstration of how to use a <select multiple> from the keyboard.

This built-in multi-select can't be styled and is only offered in a compact layout not suitable for presenting a lot of options. See how you can't really see the breadth of options in that tiny box? While you can change its size, it's still not as usable as a sidebar of checkboxes.

Markup #

Both components will be contained in the same <form> element. The results of this form, whether checkboxes or a multi-select, will be observed and used to filter the grid, but could also be submitted to a server.

<form>

</form>

Checkboxes component #

Groups of checkboxes should be wrapped in a <fieldset> element and given a <legend>. When HTML is structured this way, screen readers and FormData will automatically understand the relationship of the elements.

<form>
  <fieldset>
    <legend>New</legend>
    … checkboxes …
  </fieldset>
</form>

With the grouping in place, add a <label> and <input type="checkbox"> for each of the filters. I chose to wrap mine in a <div> so the CSS gap property can space them evenly and maintain alignment when labels go multiline.

<form>
  <fieldset>
    <legend>New</legend>
    <div>
      <input type="checkbox" id="last 30 days" name="new" value="last 30 days">
      <label for="last 30 days">Last 30 Days</label>
    </div>
    <div>
      <input type="checkbox" id="last 6 months" name="new" value="last 6 months">
      <label for="last 6 months">Last 6 Months</label>
    </div>
   </fieldset>
</form>

`<select multiple>` component #

A seldom used feature of the <select> element is multiple. When the attribute is used with a <select> element, the user is allowed to choose many from the list. It's like changing the interaction from a radio list to a checkbox list.

<form>
  <select multiple="true" title="Filter results by category">
    …
  </select>
</form>

To label and create groups inside of a <select>, use the <optgroup> element and give it a label attribute and value. This element and attribute value are akin to the <fieldset> and <legend> elements.

<form>
  <select multiple="true" title="Filter results by category">
    <optgroup label="New">
      …
    </optgroup>
  </select>
</form>

Now add the <option> elements for the filter.

<form>
  <select multiple="true" title="Filter results by category">
    <optgroup label="New">
      <option value="last 30 days">Last 30 Days</option>
      <option value="last 6 months">Last 6 Months</option>
    </optgroup>
  </select>
</form>

Tracking input with counters to inform assistive technology #

The status role technique is used in this user experience, to track and maintain the tally of filters for screen readers and other assistive technologies. The YouTube video demonstrates the feature. The integration begins with HTML and the attribute role="status".

<div role="status" class="sr-only" id="applied-filters"></div>

This element will read aloud changes made to the contents. We can update the contents with CSS counters as users interact with the checkboxes. To do that we first need to create a counter with a name on a parent element of the inputs and state element.

aside {
  counter-reset: filters;
}

By default, the count will be 0, which is great, nothing is :checked by default in this design.

Next, to increment our newly created counter, we'll target children of the <aside> element that are :checked. As the user changes the state of inputs, the filters counter will tally up.

aside :checked {
  counter-increment: filters;
}

CSS is now aware of the general tally of the checkbox UI and the status role element is empty and awaiting values. Since CSS is maintaining the tally in memory, the counter() function allows accessing the value from pseudo element contents:

aside #applied-filters::before {
  content: counter(filters) " filters ";
}

The HTML for the status role element will now announce "2 filters " to a screen reader. This is a good start, but we can do better, like share the tally of results the filters have updated. We'll do this work from JavaScript, as it's outside what counters can do.

Nesting excitement #

The counters algorithm felt great with CSS nesting-1, as I was able to put all the logic into one block. Feels portable and centralized for reading and updating.

aside {
  counter-reset: filters;

  & :checked {
    counter-increment: filters;
  }

  & #applied-filters::before {
    content: counter(filters) " filters ";
  }
}

Layouts #

This section describes the layouts between the two components. Most of the layout styles are for the desktop checkbox component.

The form #

To optimize legibility and scannability for users, the form is given a maximum width of 30 characters, essentially setting an optical line width for each filter label. The form uses grid layout and the gap property to space out the fieldsets.

form {
  display: grid;
  gap: 2ch;
  max-inline-size: 30ch;
}

The `<select>` element #

The list of labels and checkboxes both consume too much space on mobile. Therefore, the layout checks to see the user’s primary pointing device to change the experience for touch.

@media (pointer: coarse) {
  select[multiple] {
    display: block;
  }
}

A value of coarse indicates that the user will not be able to interact with the screen with high amounts of precision with their primary input device. On a mobile device, the pointer value is often coarse, as the primary interaction is touch. On a desktop device, the pointer value is often fine as it's common to have a mouse or other high precision input device connected.

The fieldsets #

The default styling and layout of a <fieldset> with a <legend> is unique:

Normally, to space my child elements I'd use the gap property, but the unique positioning of the <legend> makes it difficult to create an evenly spaced set of children. Instead of gap, the adjacent sibling selector and margin-block-start are used.

fieldset {
  padding: 2ch;

  & > div + div {
    margin-block-start: 2ch;
  }
}

This skips the <legend> from having it's space adjusted by targeting just the <div> children.

As a direct child of a <fieldset> and within the max width of the form's 30ch, label text may wrap if too long. Wrapping text is great, but misalignment between text and checkbox is not. Flexbox is ideal for this.

fieldset > div {
  display: flex;
  gap: 2ch;
  align-items: baseline;
}

Play more in this Codepen

The animated grid #

The layout animation is done by Isotope. A performant and powerful plugin for interactive sort and filter.

JavaScript #

In addition to helping orchestrate a neat animated, interactive grid, JavaScript is used to polish a couple of rough edges.

Normalizing the user input #

This design has one form with two different ways to provide input, and they don't serialize the same. With some JavaScript though, we can normalize the data.

I chose to align the <select> element data structure to the grouped checkboxes structure. To do this, an input event listener is added to the <select> element, at which point it's selectedOptions are mapped.

document.querySelector('select').addEventListener('input', event => {
  // make selectedOptions iterable then reduce a new array object
  let selectData = Array.from(event.target.selectedOptions).reduce((data, opt) => {
    // parent optgroup label and option value are added to the reduce aggregator
    data.push([opt.parentElement.label.toLowerCase(), opt.value])
    return data
  }, [])
})

Now it's safe to submit the form, or in the case of this demo, instruct Isotope on what to filter by.

Finishing the status role element #

The element is only tallying and announcing filter count based on checkbox interaction but I felt it was a good idea to additionally share the number of results and ensure the <select> element choices are counted as well.

`<select>` element choice reflected in the `counter()` #

In the data normalization section, a listener was already created on input. At the end of this function the number of chosen filters and the number of results for those filters are known. The values can be passed to the state role element like this.

let statusRoleElement = document.querySelector('#applied-filters')
statusRoleElement.style.counterSet = selectData.length

Results reflected in the `role="status"` element #

:checked provides a built-in way of passing the number of chosen filters to the status role element, but lacks visibility to the filtered number of results. JavaScript can watch for interaction with the checkboxes and after filtering the grid, add textContent like the <select> element did.

document
  .querySelector('aside form')
  .addEventListener('input', e => {
    // isotope demo code
    let filterResults = IsotopeGrid.getFilteredItemElements().length
    document.querySelector('#applied-filters').textContent = `giving ${filterResults} results`
})

Altogether this work completes the announcement "2 filters giving 25 results".

Now our excellent assistive technology experience will be delivered to all the users, however they interact with it.

Conclusion #

Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Nothing to see here yet!

Building a split-button component

2021-09-01T00:00:00Z

In this post I want to share thinking on a way to build a split button . Try the demo.

Demo

If you prefer video, here's a YouTube version of this post:

Overview #

Split buttons are buttons that conceal a primary button and a list of additional buttons. They're useful for exposing a common action while nesting secondary, less frequently used actions until needed. A split button can be crucial to helping a busy design feel minimal. An advanced split button may even remember the last user action and promote it into the primary position.

A common split button can be found in your email application. The primary action is send, but perhaps you can send later or save a draft instead:

The shared action area is nice, since the user doesn't need to look around. They know that essential email actions are contained in the split button.

Parts #

Let's break down the essential parts of a split button before discussing their overall orchestration and final user experience. VisBug's accessibility inspect tool is used here to help show a macro view of the component, surfacing aspects of the HTML, style and accessibility for each major part.

Top level split button container #

The highest level component is an inline flexbox, with a class of gui-split-button, containing the primary action and the .gui-popup-button.

The primary action button #

The initially visible and focusable <button> fits within the container with two matching corner shapes for focus, hover and active interactions to appear contained within .gui-split-button.

The "popup button" support element is for activating and alluding to the list of secondary buttons. Notice it's not a <button> and it's not focusable. However, it is the positioning anchor for .gui-popup and host for :focus-within used to present the popup.

This is a floating card child to its anchor .gui-popup-button, positioned absolute and semantically wrapping the button list.

The secondary action(s) #

A focusable <button> with a slightly smaller font size than the primary action button features an icon and a complimentary style to the primary button.

Custom properties #

The following variables assist in creating color harmony and a central place to modify values used throughout the component.

@custom-media --motionOK (prefers-reduced-motion: no-preference);
@custom-media --dark (prefers-color-scheme: dark);
@custom-media --light (prefers-color-scheme: light);

.gui-split-button {
  --theme:             hsl(220 75% 50%);
  --theme-hover:  hsl(220 75% 45%);
  --theme-active:  hsl(220 75% 40%);
  --theme-text:      hsl(220 75% 25%);
  --theme-border: hsl(220 50% 75%);
  --ontheme:         hsl(220 90% 98%);
  --popupbg:         hsl(220 0% 100%);

  --border: 1px solid var(--theme-border);
  --radius: 6px;
  --in-speed: 50ms;
  --out-speed: 300ms;

  @media (--dark) {
    --theme:             hsl(220 50% 60%);
    --theme-hover:  hsl(220 50% 65%);
    --theme-active:  hsl(220 75% 70%);
    --theme-text:      hsl(220 10% 85%);
    --theme-border: hsl(220 20% 70%);
    --ontheme:         hsl(220 90% 5%);
    --popupbg:         hsl(220 10% 30%);
  }
}

Layouts and color #

Markup #

The element begins as a <div> with a custom class name.

<div class="gui-split-button"></div>

Add the primary button and the .gui-popup-button elements.

<div class="gui-split-button">
  <button>Send</button>
  <span class="gui-popup-button" aria-haspopup="true" aria-expanded="false" title="Open for more actions"></span>
</div>

Notice the aria attributes aria-haspopup and aria-expanded. These cues are critical for screen readers to be aware of the capability and state of split button experience. The title attribute is helpful for everyone.

Add an <svg> icon and the .gui-popup container element.

<div class="gui-split-button">
  <button>Send</button>
  <span class="gui-popup-button" aria-haspopup="true" aria-expanded="false" title="Open for more actions">
    <svg aria-hidden="true" viewBox="0 0 20 20">
      <path d="M5.293 7.293a1 1 0 011.414 0L10 10.586l3.293-3.293a1 1 0 111.414 1.414l-4 4a1 1 0 01-1.414 0l-4-4a1 1 0 010-1.414z" />
    </svg>
    <ul class="gui-popup"></ul>
  </span>
</div>

For straightforward popup placement, .gui-popup is a child to the button that expands it. The only catch with this strategy is the .gui-split-button container can't use overflow: hidden, as it will clip the popup from being visually present.

A <ul> filled with <li><button> contents will announce itself as a "button list" to screen readers, which is precisely the interface being presented.

<div class="gui-split-button">
  <button>Send</button>
  <span class="gui-popup-button" aria-haspopup="true" aria-expanded="false" title="Open for more actions">
    <svg aria-hidden="true" viewBox="0 0 20 20">
      <path d="M5.293 7.293a1 1 0 011.414 0L10 10.586l3.293-3.293a1 1 0 111.414 1.414l-4 4a1 1 0 01-1.414 0l-4-4a1 1 0 010-1.414z" />
    </svg>
    <ul class="gui-popup">
      <li>
        <button>Schedule for later</button>
      </li>
      <li>
        <button>Delete</button>
      </li>
      <li>
        <button>Save draft</button>
      </li>
    </ul>
  </span>
</div>

For flair and to have fun with color, I've added icons to the secondary buttons from https://heroicons.com. Icons are optional for both the primary and secondary buttons.

<div class="gui-split-button">
  <button>Send</button>
  <span class="gui-popup-button" aria-haspopup="true" aria-expanded="false" title="Open for more actions">
    <svg aria-hidden="true" viewBox="0 0 20 20">
      <path d="M5.293 7.293a1 1 0 011.414 0L10 10.586l3.293-3.293a1 1 0 111.414 1.414l-4 4a1 1 0 01-1.414 0l-4-4a1 1 0 010-1.414z" />
    </svg>
    <ul class="gui-popup">
      <li><button>
        <svg aria-hidden="true" viewBox="0 0 24 24">
          <path d="M8 7V3m8 4V3m-9 8h10M5 21h14a2 2 0 002-2V7a2 2 0 00-2-2H5a2 2 0 00-2 2v12a2 2 0 002 2z" />
        </svg>
        Schedule for later
      </button></li>
      <li><button>
        <svg aria-hidden="true" viewBox="0 0 24 24">
          <path d="M19 7l-.867 12.142A2 2 0 0116.138 21H7.862a2 2 0 01-1.995-1.858L5 7m5 4v6m4-6v6m1-10V4a1 1 0 00-1-1h-4a1 1 0 00-1 1v3M4 7h16" />
        </svg>
        Delete
      </button></li>
      <li><button>
        <svg aria-hidden="true" viewBox="0 0 24 24">
          <path d="M5 5a2 2 0 012-2h10a2 2 0 012 2v16l-7-3.5L5 21V5z" />
        </svg>
        Save draft
      </button></li>
    </ul>
  </span>
</div>

Styles #

With HTML and content in place, styles are ready to provide color and layout.

Styling the split button container #

An inline-flex display type works well for this wrapping component as it should fit inline with other split buttons, actions or elements.

.gui-split-button {
  display: inline-flex;
  border-radius: var(--radius);
  background: var(--theme);
  color: var(--ontheme);
  fill: var(--ontheme);

  touch-action: manipulation;
  user-select: none;
  -webkit-tap-highlight-color: transparent;
}

The `<button>` styling #

Buttons are very good at disguising how much code is required. You might need to undo or replace browser default styles, but you'll also need to enforce some inheritance, add interaction states and adapt to various user preferences and input types. Button styles add up quickly.

These buttons are different from regular buttons because they share a background with a parent element. Usually, a button owns its background and text color. These, though, share it, and only apply their own background on interaction.

.gui-split-button button {
  cursor: pointer;
  appearance: none;
  background: none;
  border: none;

  display: inline-flex;
  align-items: center;
  gap: 1ch;
  white-space: nowrap;

  font-family: inherit;
  font-size: inherit;
  font-weight: 500;

  padding-block: 1.25ch;
  padding-inline: 2.5ch;

  color: var(--ontheme);
  outline-color: var(--theme);
  outline-offset: -5px;
}

Add interaction states with a few CSS pseudo-classes and use of matching custom properties for the state:

.gui-split-button button {
  …

  &:is(:hover, :focus-visible) {
    background: var(--theme-hover);
    color: var(--ontheme);

    & > svg {
      stroke: currentColor;
      fill: none;
    }
  }

  &:active {
    background: var(--theme-active);
  }
}

The primary button needs a few special styles to complete the design effect:

.gui-split-button > button {
  border-end-start-radius: var(--radius);
  border-start-start-radius: var(--radius);

  & > svg {
    fill: none;
    stroke: var(--ontheme);
  }
}

Lastly, for some flair, the light theme button and icon get a shadow:

.gui-split-button {
  @media (--light) {
    & > button,
    & button:is(:focus-visible, :hover) {
      text-shadow: 0 1px 0 var(--theme-active);
    }
    & > .gui-popup-button > svg,
    & button:is(:focus-visible, :hover) > svg {
      filter: drop-shadow(0 1px 0 var(--theme-active));
    }
  }
}

A great button has paid attention to the microinteractions and tiny details.

A note about `:focus-visible` #

Notice how the button styles use :focus-visible instead of :focus. :focus is a crucial touch to making an accessible user interface but it does have one downfall: it's not intelligent about whether or not the user needs to see it or not, it'll apply for any focus.

The video below attempts to break this microinteraction down, to show how :focus-visible is an intelligent alternative.

A 4ch flexbox for centering an icon and anchoring a popup button list. Like the primary button, it is transparent until otherwise hovered or interacted with, and stretched to fill.

.gui-popup-button {
  inline-size: 4ch;
  cursor: pointer;
  position: relative;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  border-inline-start: var(--border);
  border-start-end-radius: var(--radius);
  border-end-end-radius: var(--radius);
}

Layer in hover, focus and active states with CSS Nesting and the :is() functional selector:

.gui-popup-button {
  …

  &:is(:hover,:focus-within) {
    background: var(--theme-hover);
  }

  /* fixes iOS trying to be helpful */
  &:focus {
    outline: none;
  }

  &:active {
    background: var(--theme-active);
  }
}

These styles are the primary hook for showing and hiding the popup. When the .gui-popup-button has focus on any of its children, set opacity, position and pointer-events, on the icon and popup.

.gui-popup-button {
  …

  &:focus-within {
    & > svg {
      transition-duration: var(--in-speed);
      transform: rotateZ(.5turn);
    }
    & > .gui-popup {
      transition-duration: var(--in-speed);
      opacity: 1;
      transform: translateY(0);
      pointer-events: auto;
    }
  }
}

With the in and out styles complete, the last piece is to conditionally transition transforms depending on the user's motion preference:

.gui-popup-button {
  …

  @media (--motionOK) {
    & > svg {
      transition: transform var(--out-speed) ease;
    }
    & > .gui-popup {
      transform: translateY(5px);

      transition:
        opacity var(--out-speed) ease,
        transform var(--out-speed) ease;
    }
  }
}

A keen eye on the code would notice opacity is still transitioned for users who prefer reduced motion.

The .gui-popup element is a floating card button list using custom properties and relative units to be subtly smaller, interactively matched with the primary button, and on brand with its use of color. Notice the icons have less contrast, are thinner, and the shadow has a hint of brand blue to it. Like with buttons, strong UI and UX is a result of these little details stacking up.

.gui-popup {
  --shadow: 220 70% 15%;
  --shadow-strength: 1%;

  opacity: 0;
  pointer-events: none;

  position: absolute;
  bottom: 80%;
  left: -1.5ch;

  list-style-type: none;
  background: var(--popupbg);
  color: var(--theme-text);
  padding-inline: 0;
  padding-block: .5ch;
  border-radius: var(--radius);
  overflow: hidden;
  display: flex;
  flex-direction: column;
  font-size: .9em;
  transition: opacity var(--out-speed) ease;

  box-shadow:
    0 -2px 5px 0 hsl(var(--shadow) / calc(var(--shadow-strength) + 5%)),
    0 1px 1px -2px hsl(var(--shadow) / calc(var(--shadow-strength) + 10%)),
    0 2px 2px -2px hsl(var(--shadow) / calc(var(--shadow-strength) + 12%)),
    0 5px 5px -2px hsl(var(--shadow) / calc(var(--shadow-strength) + 13%)),
    0 9px 9px -2px hsl(var(--shadow) / calc(var(--shadow-strength) + 14%)),
    0 16px 16px -2px hsl(var(--shadow) / calc(var(--shadow-strength) + 20%))
  ;
}

The icons and buttons are given brand colors to style nicely within each dark and light themed card:

.gui-popup {
  …

  & svg {
    fill: var(--popupbg);
    stroke: var(--theme);

    @media (prefers-color-scheme: dark) {
      stroke: var(--theme-border);
    }
  }

  & button {
    color: var(--theme-text);
    width: 100%;
  }
}

The dark theme popup has text and icon shadow additions, plus a slightly more intense box shadow:

.gui-popup {
  …

  @media (--dark) {
    --shadow-strength: 5%;
    --shadow: 220 3% 2%;

    & button:not(:focus-visible, :hover) {
      text-shadow: 0 1px 0 var(--ontheme);
    }

    & button:not(:focus-visible, :hover) > svg {
      filter: drop-shadow(0 1px 0 var(--ontheme));
    }
  }
}

Generic `<svg>` icon styles #

All icons are relatively sized to the button font-size they're used within by using the ch unit as the inline-size. Each is also given some styles to help outline icons soft and smooth.

.gui-split-button svg {
  inline-size: 2ch;
  box-sizing: content-box;
  stroke-linecap: round;
  stroke-linejoin: round;
  stroke-width: 2px;
}

Right-to-left layout #

Logical properties do all the complex work. Here's the list of logical properties used:

display: inline-flex creates an inline flex element.
padding-block and padding-inline as a pair, instead of padding shorthand, get the benefits of padding the logical sides.
border-end-start-radius and friends will round corners based on document direction.
inline-size rather than width ensures the size isn't tied to physical dimensions.
border-inline-start adds a border to the start, which might be on the right or the left depending on script direction.

JavaScript #

Nearly all of the following JavaScript is to enhance accessibility. Two of my helper libraries are used to make the tasks a little easier. BlingBlingJS is used for succinct DOM queries and easy event listener setup, while roving-ux helps facilitate accessible keyboard and gamepad interactions for the popup.

import $ from 'blingblingjs'
import {rovingIndex} from 'roving-ux'

const splitButtons = $('.gui-split-button')
const popupButtons = $('.gui-popup-button')

With the above libraries imported and the elements selected and saved into variables, upgrading the experience is a few functions away from being complete.

Roving index #

When a keyboard or screen reader focuses the .gui-popup-button, we want to forward the focus into the first (or most recently focused) button in the .gui-popup. The library helps us do this with the element and target parameters.

popupButtons.forEach(element =>
  rovingIndex({
    element,
    target: 'button',
  }))

The element now passes focus to the target <button> children and enables standard arrow key navigation to browse options.

Toggling `aria-expanded` #

While it's visually apparent that a popup is showing and hiding, a screen reader needs more than visual cues. JavaScript is used here to compliment the CSS driven :focus-within interaction by toggling a screen reader appropriate attribute.

popupButtons.on('focusin', e => {
  e.currentTarget.setAttribute('aria-expanded', true)
})

popupButtons.on('focusout', e => {
  e.currentTarget.setAttribute('aria-expanded', false)
})

Enabling the `Escape` key #

The user's focus has been intentionally sent to a trap, which means we need to provide a way to leave. The most common way is to allow using the Escape key. To do so, watch for keypresses on the popup button, since any keyboard events on children will bubble up to this parent.

popupButtons.on('keyup', e => {
  if (e.code === 'Escape')
    e.target.blur()
})

If the popup button sees any Escape key presses, it removes focus from itself with blur().

Split button clicks #

Finally, if the user clicks, taps, or keyboard interacts with the buttons, the application needs to perform the appropriate action. Event bubbling is used again here, but this time on the .gui-split-button container, to catch button clicks from a child popup or the primary action.

splitButtons.on('click', event => {
  if (event.target.nodeName !== 'BUTTON') return
  console.info(event.target.innerText)
})

Conclusion #

Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Codepen by Joost van der Schee

CSS `accent-color`

2021-08-11T00:00:00Z

Today's HTML form elements are difficult to customize. It feels as if it's a choice between few or no custom styles, or resetting input styles and build it up from scratch. Building it up from scratch ends up being much more work than anticipated. It can also lead to forgotten styles for element states (indeterminate, I'm looking at you), and the loss of built-in accessibility features. To fully recreate what the browser provides may be more work than you're looking to take on.

accent-color: hotpink;

CSS accent-color from the CSS UI specification is here to tint elements with one line of CSS, saving you from customization efforts by providing a way to bring your brand into elements.

Browser support

Chrome 93, Supported 93
Firefox 92, Supported 92
Edge 93, Supported 93
Safari 15.4, Supported 15.4

Source

Demo

The accent-color property also works with color-scheme, allowing authors to tint both the light and dark elements. In the following example the user has a dark theme active, the page uses color-scheme: light dark, and uses the same accent-color: hotpink for dark themed hotpink tinted controls.

Demo

Supported elements #

Currently, only four elements will tint via the accent-color property: checkbox, radio, range and progress. Each can be previewed here https://accent-color.glitch.me in light and dark color schemes.

Guaranteeing contrast #

To prevent inaccessible elements from existing, browsers with accent-color need to determine an eligible contrast color to be used alongside the custom accent. Below is a screenshot demonstrating how Chrome 94 (left) and Firefox 92 Nightly (right) differ in their algorithms:

The most important thing to take away from this, is to trust the browser. Provide a brand color, and trust that it will make smart decisions for you.

Extra: More tinting #

You may be wondering how to tint more than these four form elements? Here's a minimal sandbox which tints:

the focus ring
text selection highlights
list markers
arrow indicators (Webkit only)
scrollbar thumb (Firefox only)

html {
  --brand: hotpink;
  scrollbar-color: hotpink Canvas;
}

:root { accent-color: var(--brand); }
:focus-visible { outline-color: var(--brand); }
::selection { background-color: var(--brand); }
::marker { color: var(--brand); }

:is(
  ::-webkit-calendar-picker-indicator,
  ::-webkit-clear-button,
  ::-webkit-inner-spin-button,
  ::-webkit-outer-spin-button
) {
  color: var(--brand);
}

See the Pen Pen RwVBreJ by web-dot-dev on Codepen

Potential future #

The spec does not limit the application of accent-color to the four elements shown in this article, more support could be added later. Elements like the selected <option> in a <select> could be highlighted with the accent-color.

What else do you like to tint on the web? Tweet @argyleink with your selector and it might get added to this article!

Building a switch component

2021-08-11T00:00:00Z

In this post I want to share thinking on a way to build switch components. Try the demo.

Demo

If you prefer video, here's a YouTube version of this post:

Overview #

A switch functions similar to a checkbox but explicitly represents boolean on and off states.

This demo uses <input type="checkbox" role="switch"> for the majority of its functionality, which has the advantage of not needing CSS or JavaScript to be fully functional and accessible. Loading CSS brings support for right-to-left languages, verticality, animation and more. Loading JavaScript makes the switch draggable and tangible.

Custom properties #

The following variables represent the various parts of the switch and their options. As the top-level class, .gui-switch contains custom properties used throughout the component children, and entry points for centralized customization.

Track #

The length (--track-size), padding, and two colors:

.gui-switch {
  --track-size: calc(var(--thumb-size) * 2);
  --track-padding: 2px;

  --track-inactive: hsl(80 0% 80%);
  --track-active: hsl(80 60% 45%);

  --track-color-inactive: var(--track-inactive);
  --track-color-active: var(--track-active);

  @media (prefers-color-scheme: dark) {
    --track-inactive: hsl(80 0% 35%);
    --track-active: hsl(80 60% 60%);
  }
}

Thumb #

The size, background color, and interaction highlight colors:

.gui-switch {
  --thumb-size: 2rem;
  --thumb: hsl(0 0% 100%);
  --thumb-highlight: hsl(0 0% 0% / 25%);

  --thumb-color: var(--thumb);
  --thumb-color-highlight: var(--thumb-highlight);

  @media (prefers-color-scheme: dark) {
    --thumb: hsl(0 0% 5%);
    --thumb-highlight: hsl(0 0% 100% / 25%);
  }
}

Reduced motion #

To add a clear alias and reduce repetition, a reduced motion preference user media query can be put into a custom property with the PostCSS plugin based on this draft spec in Media Queries 5:

@custom-media --motionOK (prefers-reduced-motion: no-preference);

Markup #

I chose to wrap my <input type="checkbox" role="switch"> element with a <label>, bundling their relationship to avoid checkbox and label association ambiguity, while giving the user the ability to interact with the label to toggle the input.

<label for="switch" class="gui-switch">
  Label text
  <input type="checkbox" role="switch" id="switch">
</label>

<input type="checkbox"> comes prebuilt with an API and state. The browser manages the checked property and input events such as oninputand onchanged.

Layouts #

Flexbox, grid, and custom properties are critical in maintaining the styles of this component. They centralize values, give names to otherwise ambiguous calculations or areas, and enable a small custom property API for easy component customizations.

`.gui-switch` #

The top-level layout for the switch is flexbox. The class .gui-switch contains the private and public custom properties the children use to compute their layouts.

.gui-switch {
  display: flex;
  align-items: center;
  gap: 2ch;
  justify-content: space-between;
}

Extending and modifying the flexbox layout is like changing any flexbox layout. For example, to put labels above or below a switch, or to change the flex-direction:

<label for="light-switch" class="gui-switch" style="flex-direction: column">
  Default
  <input type="checkbox" role="switch" id="light-switch">
</label>

Track #

The checkbox input is styled as a switch track by removing its normal appearance: checkbox and supplying its own size instead:

.gui-switch > input {
  appearance: none;

  inline-size: var(--track-size);
  block-size: var(--thumb-size);
  padding: var(--track-padding);

  flex-shrink: 0;
  display: grid;
  align-items: center;
  grid: [track] 1fr / [track] 1fr;
}

The track also creates a one by one single cell grid track area for a thumb to claim.

Thumb #

The style appearance: none also removes the visual checkmark supplied by the browser. This component uses a pseudo-element and the :checked pseudo-class on the input to replace this visual indicator.

The thumb is a pseudo-element child attached to the input[type="checkbox"] and stacks on top of the track instead of below it by claiming the grid area track:

.gui-switch > input::before {
  content: "";
  grid-area: track;
  inline-size: var(--thumb-size);
  block-size: var(--thumb-size);
}

Styles #

Custom properties enable a versatile switch component that adapts to color schemes, right-to-left languages and motion preferences.

Touch interaction styles #

On mobile, browsers add tap highlights and text selection features to labels and inputs. These negatively affected the style and visual interaction feedback that this switch needed. With a few lines of CSS I can remove those effects and add my own cursor: pointer style:

.gui-switch {
  cursor: pointer;
  user-select: none;
  -webkit-tap-highlight-color: transparent;
}

It's not always advisable to remove those styles, as they can be valuable visual interaction feedback. Be sure to provide custom alternatives if you remove them.

Track #

This element's styles are mostly about its shape and color, which it accesses from the parent .gui-switch via the cascade.

.gui-switch > input {
  appearance: none;
  border: none;
  outline-offset: 5px;
  box-sizing: content-box;

  padding: var(--track-padding);
  background: var(--track-color-inactive);
  inline-size: var(--track-size);
  block-size: var(--thumb-size);
  border-radius: var(--track-size);
}

A wide variety of customization options for the switch track come from four custom properties. border: none is added since appearance: none doesn't remove the borders from the checkbox on all browsers.

Thumb #

The thumb element is already on the right track but needs circle styles:

.gui-switch > input::before {
  background: var(--thumb-color);
  border-radius: 50%;
}

Interaction #

Use custom properties to prepare for interactions which will show hover highlights and thumb position changes. The user's preference is also checked before transitioning the motion or hover highlight styles.

.gui-switch > input::before {
  box-shadow: 0 0 0 var(--highlight-size) var(--thumb-color-highlight);

  @media (--motionOK) { & {
    transition:
      transform var(--thumb-transition-duration) ease,
      box-shadow .25s ease;
  }}
}

Thumb position #

Custom properties provide a single source mechanism for positioning the thumb in the track. At our disposal are the track and thumb sizes which we'll use in calculations to keep the thumb properly offset and between within the track: 0% and 100%.

The input element owns the position variable --thumb-position, and the thumb pseudo element uses it as a translateX position:

.gui-switch > input {
  --thumb-position: 0%;
}

.gui-switch > input::before {
  transform: translateX(var(--thumb-position));
}

We're now free to change --thumb-position from CSS and the pseudo-classes provided on checkbox elements. Since we conditionally set transition: transform var(--thumb-transition-duration) ease earlier on this element, these changes may animate when changed:

/* positioned at the end of the track: track length - 100% (thumb width) */
.gui-switch > input:checked {
  --thumb-position: calc(var(--track-size) - 100%);
}

/* positioned in the center of the track: half the track - half the thumb */
.gui-switch > input:indeterminate {
  --thumb-position: calc(
    (var(--track-size) / 2) - (var(--thumb-size) / 2)
  );
}

I thought this decoupled orchestration worked out well. The thumb element is only concerned with one style, a translateX position. The input can manage all the complexity and calculations.

Vertical #

Supporting was done with a modifier class -vertical which adds a rotation with CSS transforms to the input element.

A 3D rotated element does not change the overall height of the component though, which can throw off block layout. Account for this using the --track-size and --track-padding variables. Calculate the minimum amount of space required for a vertical button to flow in layout as expected:

.gui-switch.-vertical {
  min-block-size: calc(var(--track-size) + calc(var(--track-padding) * 2));

  & > input {
    transform: rotate(-90deg);
  }
}

(RTL) right-to-left #

A CSS friend, Elad Schecter, and I prototyped together a slide out side menu using CSS transforms that handled right-to-left languages by flipping a single variable. We did this because there are no logical property transforms in CSS, and there may never be. Elad had the great idea of using a custom property value to invert percentages, to allow single location management of our own custom logic for logical transforms. I used this same technique in this switch and I think it worked out great:

.gui-switch {
  --isLTR: 1;

  &:dir(rtl) {
    --isLTR: -1;
  }
}

A custom property called --isLTR initially holds a value of 1, meaning it's true since our layout is left-to-right by default. Then, using the CSS pseudo class :dir(), the value is set to -1 when the component is within a right-to-left layout.

Put --isLTR into action by using it within a calc() inside of a transform:

.gui-switch.-vertical > input {
  transform: rotate(-90deg);
  transform: rotate(calc(90deg * var(--isLTR) * -1));
}

Now the rotation of the vertical switch accounts for the opposite side position required by the right-to-left layout.

The translateX transforms on the thumb pseudo-element also need updated to account for the opposite side requirement:

.gui-switch > input:checked {
  --thumb-position: calc(var(--track-size) - 100%);
  --thumb-position: calc((var(--track-size) - 100%) * var(--isLTR));
}

.gui-switch > input:indeterminate {
  --thumb-position: calc(
    (var(--track-size) / 2) - (var(--thumb-size) / 2)
  );
  --thumb-position: calc(
   ((var(--track-size) / 2) - (var(--thumb-size) / 2))
    * var(--isLTR)
  );
}

While this approach won't work to solve all needs regarding a concept like logical CSS transforms, it does offer some DRY principles for many use cases.

States #

Using the built in input[type="checkbox"] wouldn't be complete without handling the various states it can be in: :checked, :disabled, :indeterminate and :hover. :focus was intentionally left alone, with an adjustment only made to its offset; the focus ring looked great on Firefox and Safari:

Checked #

<label for="switch-checked" class="gui-switch">
  Default
  <input type="checkbox" role="switch" id="switch-checked" checked="true">
</label>

This state represents the on state. In this state, the input "track" background is set to the active color and the thumb position is set to "the end".

.gui-switch > input:checked {
  background: var(--track-color-active);
  --thumb-position: calc((var(--track-size) - 100%) * var(--isLTR));
}

Disabled #

<label for="switch-disabled" class="gui-switch">
  Default
  <input type="checkbox" role="switch" id="switch-disabled" disabled="true">
</label>

A :disabled button not only visually looks different, but also should make the element immutable.Interaction immutability is free from the browser, but the visual states need styles due to the use of appearance: none.

.gui-switch > input:disabled {
  cursor: not-allowed;
  --thumb-color: transparent;

  &::before {
    cursor: not-allowed;
    box-shadow: inset 0 0 0 2px hsl(0 0% 100% / 50%);

    @media (prefers-color-scheme: dark) { & {
      box-shadow: inset 0 0 0 2px hsl(0 0% 0% / 50%);
    }}
  }
}

This state is tricky since it needs dark and light themes with both disabled and checked states. I stylistically chose minimal styles for these states to ease the maintenance burden of the combinations of styles.

Indeterminate #

An often forgotten state is :indeterminate, where a checkbox is neither checked or unchecked. This is a fun state, it's inviting and unassuming. A good reminder that boolean states can have sneaky in between states.

It is tricky to set a checkbox to indeterminate, only JavaScript can set it:

<label for="switch-indeterminate" class="gui-switch">
  Indeterminate
  <input type="checkbox" role="switch" id="switch-indeterminate">
  <script>document.getElementById('switch-indeterminate').indeterminate = true</script>
</label>

Since the state, to me, is unassuming and inviting, it felt appropriate to put the switch thumb position in the middle:

.gui-switch > input:indeterminate {
  --thumb-position: calc(
    calc(calc(var(--track-size) / 2) - calc(var(--thumb-size) / 2))
    * var(--isLTR)
  );
}

Hover #

Hover interactions should provide visual support for connected UI and also provide direction towards interactive UI. This switch highlights the thumb with a semi-transparent ring when the label or the input are hovered. This hover animation then provides direction towards the interactive thumb element.

The "highlight" effect is done with box-shadow. On hover, of an non-disabled input, increase the size of --highlight-size. If the user is OK with motion, we transition the box-shadow and see it grow, if they're not ok with motion, the highlight appears instantly:

.gui-switch > input::before {
  box-shadow: 0 0 0 var(--highlight-size) var(--thumb-color-highlight);

  @media (--motionOK) { & {
    transition:
      transform var(--thumb-transition-duration) ease,
      box-shadow .25s ease;
  }}
}

.gui-switch > input:not(:disabled):hover::before {
  --highlight-size: .5rem;
}

JavaScript #

To me, a switch interface can feel uncanny in its attempt to emulate a physical interface, especially this kind with a circle inside a track. iOS got this right with their switch, you can drag them side to side, and it's very satisfying to have the option. Conversely, a UI element can feel inactive if a drag gesture is attempted and nothing happens.

Draggable thumbs #

The thumb pseudo-element receives its position from the .gui-switch > input scoped var(--thumb-position), JavaScript can supply an inline style value on the input to dynamically update the thumb position making it appear to follow the pointer gesture. When the pointer is released, remove the inline styles and determine if the drag was closer to off or on by using the custom property --thumb-position. This is the backbone of the solution; pointer events conditionally tracking pointer positions to modify CSS custom properties.

Since the component was already 100% functional before this script is showing up, it does take quite a bit of work to maintain the existing behavior, like clicking a label to toggle the input. Our JavaScript shouldn't add features at the expense of existing features.

`touch-action` #

Dragging is a gesture, a custom one, which makes it a great candidate for touch-action benefits. In the case of this switch, a horizontal gesture should be handled by our script, or a vertical gesture captured for the vertical switch variant. With touch-action we can tell the browser what gestures to handle on this element, so a script can handle a gesture without competition.

The following CSS instructs the browser that when a pointer gesture starts from within this switch track, handle vertical gestures, do nothing with horizontal ones:

.gui-switch > input {
  touch-action: pan-y;
}

The desired result is a horizontal gesture that doesn't also pan or scroll the page. A pointer can vertically scroll start from within the input and scroll the page, but horizontal ones are custom handled.

Pixel value style utilities #

On setup and during drag, various computed number values will need to be grabbed from elements. The following JavaScript functions return computed pixel values given a CSS property. It's used in the setup script like this getStyle(checkbox, 'padding-left').

const getStyle = (element, prop) => {
  return parseInt(window.getComputedStyle(element).getPropertyValue(prop));
}

const getPseudoStyle = (element, prop) => {
  return parseInt(window.getComputedStyle(element, ':before').getPropertyValue(prop));
}

export {
  getStyle,
  getPseudoStyle,
}

Notice how window.getComputedStyle() accepts a second argument, a target pseudo element. Pretty neat that JavaScript can read so many values from elements, even from pseudo elements.

`dragging` #

This is a core moment for the drag logic and there are a few things with noting from the function event handler:

const dragging = event => {
  if (!state.activethumb) return

  let {thumbsize, bounds, padding} = switches.get(state.activethumb.parentElement)
  let directionality = getStyle(state.activethumb, '--isLTR')

  let track = (directionality === -1)
    ? (state.activethumb.clientWidth * -1) + thumbsize + padding
    : 0

  let pos = Math.round(event.offsetX - thumbsize / 2)

  if (pos < bounds.lower) pos = 0
  if (pos > bounds.upper) pos = bounds.upper

  state.activethumb.style.setProperty('--thumb-position', `${track + pos}px`)
}

The script hero is state.activethumb, the little circle this script is positioning along with a pointer. The switches object is a Map() where the keys are .gui-switch's and the values are cached bounds and sizes that keep the script efficient. Right-to-left is handled using the same custom property that CSS is --isLTR, and is able to use it to invert logic and continue supporting RTL. The event.offsetX is valuable as well, as it contains a delta value useful for positioning the thumb.

state.activethumb.style.setProperty('--thumb-position', `${track + pos}px`)

This final line of CSS sets the custom property used by the thumb element. This value assignment would otherwise transition over time, but a previous pointer event has temporarily set --thumb-transition-duration to 0s, removing what would have been a sluggish interaction.

`dragEnd` #

In order for the user to be allowed to drag far outside the switch and let go, a global window event needed registered:

window.addEventListener('pointerup', event => {
  if (!state.activethumb) return

  dragEnd(event)
})

I think it's very important that a user has freedom to drag loosely and have the interface be smart enough to account for it. It didn't take much to handle it with this switch, but it did need careful consideration during the development process.

const dragEnd = event => {
  if (!state.activethumb) return

  state.activethumb.checked = determineChecked()

  if (state.activethumb.indeterminate)
    state.activethumb.indeterminate = false

  state.activethumb.style.removeProperty('--thumb-transition-duration')
  state.activethumb.style.removeProperty('--thumb-position')
  state.activethumb.removeEventListener('pointermove', dragging)
  state.activethumb = null

  padRelease()
}

Interaction with the element has completed, time to set the input checked property and remove all the gesture events. The checkbox is changed with state.activethumb.checked = determineChecked().

`determineChecked()` #

This function, called by dragEnd, determines where the thumb current lies within the bounds of its track and returns true if it is equal to or over halfway along the track:

const determineChecked = () => {
  let {bounds} = switches.get(state.activethumb.parentElement)

  let curpos =
    Math.abs(
      parseInt(
        state.activethumb.style.getPropertyValue('--thumb-position')))

  if (!curpos) {
    curpos = state.activethumb.checked
      ? bounds.lower
      : bounds.upper
  }

  return curpos >= bounds.middle
}

Extra thoughts #

The drag gesture incurred a bit of code debt due to the initial HTML structure chosen, mostly notably wrapping the input in a label. The label, being a parent element, would receive click interactions after the input. At the end of the dragEnd event, you may have noticed padRelease() as an odd sounding function.

const padRelease = () => {
  state.recentlyDragged = true

  setTimeout(_ => {
    state.recentlyDragged = false
  }, 300)
}

This is to account for the label getting this later click, as it would uncheck, or check, the interaction a user performed.

If I was to do this again, I might consider adjusting DOM with JavaScript during the UX upgrade, as to create an element that handles label clicks itself and doesn't fight with built-in behavior.

This kind of JavaScript is my least favorite to write, I don't want to manage conditional event bubbling:

const preventBubbles = event => {
  if (state.recentlyDragged)
    event.preventDefault() && event.stopPropagation()
}

Conclusion #

This teeny switch component ended up being the most work of all GUI Challenges so far! Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

@KonstantinRouda with a custom element: demo and code.
@jhvanderschee with a button: Codepen.

Resources #

Find the .gui-switch source code on GitHub.

2021 Scroll Survey Report

2021-08-02T00:00:00Z

In April, the Chrome team released a scroll and touch-action survey based on top reported issues from the 2019 MDN Web DNA Report. The 2021 Scroll Survey Report is ready, and the Chrome team would like to share some thoughts and action items we've gleaned from the survey results. We hope these results will help browser vendors and standards groups understand how to improve web scrolling.

View the 2021 Scroll Survey Report.

Noteworthy results #

The survey anonymously collected 880 submissions, with 366 answering every question.

While getting started with scrolling is one line of CSS, like overflow-x: scroll;, the surface area of scroll APIs and options is large, spanning JavaScript to CSS. The following results help to highlight the issues web developers are encountering.

Overall satisfaction with web scrolling #

Question 27

45_%

are somewhat or extremely dissatisfied overall
with web scrolling.

This question was placed near the end of the survey intentionally, after questions on 26 scroll use cases and features. From the response, it's clear that the web community struggles with scroll. Almost half of the respondents report a level of overall dissatisfaction.

We believe overall sentiment about working with scroll should not be this low. This metric needs to be changed; it's a clear signal there's work to be done.

Difficulty working with scroll #

Question 2

43_%

reported it's somewhat or
extremely difficult
to work with scrolling.

From our research, these difficulties come from the multitude of use cases for scroll. When we talk about scrolling, that might include:

Missing browser features, complex JavaScript, and the need to support input modes including touch, keyboard, and gamepads, make all of these things harder.

Importance of touch interactions #

Question 3

51_%

report touch interactions as
very or extremely important
to their work.

With mobile web users still on the rise in visit statistics, it wasn't surprising to see half of the respondents report that touch is very important to their work on the web. This signaled that web features like CSS scroll snap and touch-action need extra attention so the web can deliver on high-quality touch interaction.

Question 5a

44_%

report somewhat or extremely difficult
to do gamepad and tab navigation.

Scrolling includes navigation methods such as keyboard arrows, tab keys, spacebar presses, and gamepads, and it can be difficult to include these when doing custom scroll work. Almost half of the respondents report it's somewhat or extremely difficult to include these inputs.

Learning `touch-action` #

Question 9

50_%

report learning about
`touch-action: manipulation`
from the survey.

Some of the survey questions asked about using certain APIs with a possible answer of Yes, No, or "today I learned." One notable piece of feedback was the number of people who reported learning about touch-action from the survey, as it's a critical property when building custom touch gestures that need to interact within scroll.

Cyclical scrolling #

Question 27

58_%

report sometimes, often or on every project
using cyclical scrolling.

The video shows cyclical seconds scrolling,
after 60 seconds it begins at 0 again.

Those numbers are high for a scrolling feature with little or no support provided by the web platform. The feature often incurs high amounts of technical debt because of this, with duplication or JavaScript injected to force the effect. It's popular for product carousels and when selecting time in seconds or minutes to offer cyclical scrolling.

Are scrollable areas important #

Question 2

55_%

very or
extremely important

16_%

report not at all
or slightly important

Respondents felt strongly about the importance of scrollable areas, giving another signal about the struggles required to deliver high-quality scrolling.

Carousels #

Question 20

87_%

have used carousels.

24_%

report they're
easy to manage.

Nearly every respondent delivers carousels in their web work, while only 25% find them easy to manage. Off-the-shelf carousels were popular during our research, but this statistic surprised us, as it doesn't sound very solved.

Infinite scroll #

Question 22

65_%

use it sometimes
to every project

60_%

somewhat or
extremely difficult.

Two-thirds of respondents deliver infinite scroll in their web work, and an equal amount report it's difficult to do. Another example of high usage paired with high difficulty, which indicates to us an area needing attention.

While content-visibility and contain-intrinsic-size can be combined to reduce render costs for long scrollable areas, it doesn't seem to be helping with "load more" infinite scroll UX.

Scroll-linked or scroll-triggered animations #

Question 24

47_%

use it sometimes
to every project

56_%

report somewhat or
extremely difficult

Almost half of all respondents use scroll-orchestrated animations and half the respondents find it difficult, once again linking high usage with difficulty.

Compete with built-in scrolling #

Question 26

32_%

always or
most of the time

50_%

sometimes

The built-in scroll and touch interactions of phone and tablet applications are often touted as a clear place where the web can catch up. The features include scroll-linked animations, programmatic interfaces, voice integration, scroll hints, and pull-to-refresh APIs.

Just half of the respondents felt it was only sometimes possible to match the experience of built-in scrolling.

Overall satisfaction building scroll interactions on the web #

Question 27

Survey Takeaways #

The survey results are segmented into four categories: compatibility, education, APIs, and features.

Compatibility #

The Chrome team has declared a goal to decrease the number of web compatibility issues, including scroll compatibility.

The first three compatibility issues to focus on:

Horizontal scrolling compatibility.
overscroll-behavior cross browser.
Removing prefixes from -webkit-scrollbar and following the standard.

Education #

The survey results showed that there needs to be more education around touch-action and logical properties. The browser is at the forefront of international layout, and it's apparent it's underutilized or misunderstood.

Areas to focus on:

APIs #

Usage of scroll snapping is growing, and developers have responded that they want to use features interoperably with popular libraries and plugins. Shrinking this gap between CSS and plugin libraries will help the satisfaction of scroll snap developer and user experience.

We'll focus API work on scroll-snap:

API availability and compatibility across browsers.
Begin work on new CSS APIs like scroll-start.
Begin work on new JS events like snapChanged().

Features #

The survey results showed that users struggle with some specific types of scroll-related components on the web, as the platform doesn't provide the primitives they need to build them without plugins or a high level of effort. This is an area that we hope to explore more deeply.

The features developers struggle to build include:

Carousels
Virtual scroll
Infinite scroll

Resources #

Thumbnail image: photo by Taylor Wilcox on Unsplash.

Building a breadcrumbs component

2021-07-14T00:00:00Z

In this post I want to share thinking on a way to build breadcrumb components. Try the demo.

Demo

If you prefer video, here's a YouTube version of this post:

Overview #

A breadcrumbs component shows where in the site hierarchy the user is. The name is from Hansel and Gretel, who dropped breadcrumbs behind them in some dark woods and were able to find their way home by tracing crumbs backwards.

The breadcrumbs in this post are not standard breadcrumbs, they're breadcrumb-like. They offer additional functionality by putting sibling pages right into the navigation with a <select>, making multi-tiered access possible.

Background UX #

In the component demo video above, the placeholder categories are genres of video games. This trail is created by navigating the following path: home » rpg » indie » on sale, as shown below.

This breadcrumb component should enable users to move through this information hierarchy; jumping branches and selecting pages with speed and accuracy.

Information architecture #

I find it's helpful to think in terms of collections and items.

Collections #

A collection is an array of options to choose from. From the homepage of the breadcrumb prototype of this post, the collections are FPS, RPG, brawler, dungeon crawler, sports and puzzle.

Items #

A video game is an item, a specific collection could also be an item if it represents another collection. For example, RPG is an item and a valid collection. When it's an item, the user is on that collection page. For example, they are on the RPG page, which displays a list of RPG games, including the additional subcategories AAA, Indie and Self Published.

In computer science terms, this breadcrumbs component represents a multidimensional array:

const rawBreadcrumbData = {
  "FPS": {...},
  "RPG": {
    "AAA": {...},
    "indie": {
      "new": {...},
      "on sale": {...},
      "under 5": {...},
    },
    "self published": {...},
  },
  "brawler": {...},
  "dungeon crawler": {...},
  "sports": {...},
  "puzzle": {...},
}

Your app or website will have custom information architecture (IA) creating a different multidimensional array, but I hope the concept of collection landing pages and hierarchy traversal can make it into your breadcrumbs as well.

Layouts #

Markup #

Good components begin with appropriate HTML. In this next section I'll cover my markup choices and how they impact the overall component.

Dark and light scheme #

<meta name="color-scheme" content="dark light">

The color-scheme meta tag in the above snippet informs the browser that this page wants the light and dark browser styles. The example breadcrumbs don't include any CSS for these color schemes, and so the breadcrumbs will use the default colors provided by the browser.

<nav class="breadcrumbs" role="navigation"></nav>

It's appropriate to use the <nav> element for site navigation, which has an implicit ARIA role of navigation. In testing, I noticed that having the role attribute changed the way a screen reader interacted with the element, it was actually announced as navigation, and so I've chosen to add it.

Icons #

When an icon is repeated on a page, the SVG <use> element means that you can define the path once, and use it for all instances of the icon. This prevents the same path information from being repeated, causing larger documents and the potential of path inconsistency.

To use this technique, add a hidden SVG element to the page and wrap the icons in a <symbol> element with a unique ID:

<svg style="display: none;">

  <symbol id="icon-home">
    <title>A home icon</title>
    <path d="M3 12l2-2m0 0l7-7 7 7M5 10v10a1 1 0 001 1h3m10-11l2 2m-2-2v10a1 1 0 01-1 1h-3m-6 0a1 1 0 001-1v-4a1 1 0 011-1h2a1 1 0 011 1v4a1 1 0 001 1m-6 0h6"/>
  </symbol>

  <symbol id="icon-dropdown-arrow">
    <title>A down arrow</title>
    <path d="M19 9l-7 7-7-7"/>
  </symbol>

</svg>

The browser reads the SVG HTML, puts the icon information into memory, and continues with the rest of the page referencing the ID for additional uses of the icon, like this:

<svg viewBox="0 0 24 24" width="24" height="24" aria-hidden="true">
  <use href="#icon-home" />
</svg>

<svg viewBox="0 0 24 24" width="24" height="24" aria-hidden="true">
  <use href="#icon-dropdown-arrow" />
</svg>

Define once, use as many times as you like, with minimal page performance impact and flexible styling. Notice aria-hidden="true" is added to the SVG element. The icons are not useful to someone browsing who only hears the content, hiding them from those users stops them adding unnecessary noise.

Split-link `.crumb` #

This is where the traditional breadcrumb and those in this component diverge. Normally, this would only be an <a> link, but I've added traversal UX with a disguised select. The .crumb class is responsible for laying out the link and the icon, while the .crumbicon is responsible for stacking the icon and select element together. I've called it a split-link because its functions are very similar to a split-button, but for page navigation.

<span class="crumb">
  <a href="#sub-collection-b">Category B</a>
  <span class="crumbicon">
    <svg>...</svg>
    <select class="disguised-select" title="Navigate to another category">
      <option>Category A</option>
      <option selected>Category B</option>
      <option>Category C</option>
    </select>
  </span>
</span>

A link and some options is nothing special but adds more functionality to a simple breadcrumb. Adding a title to the <select> element is helpful for screen reader users, giving them information about the action of the button. However it provides the same help to everyone else too, you'll see it's front and center on iPad. One attribute provides button context to many users.

Separator decorations #

<span class="crumb-separator" aria-hidden="true">→</span>

Separators are optional, adding just one works great too (see the third example in the video above). I then give each aria-hidden="true" since they are decorative and not something a screen reader needs to announce.

The gap property, covered next, makes the spacing of these straightforward.

Styles #

Since the color uses system colors, it's mostly gaps and stacks for styles!

Layout direction and flow #

The primary navigation element nav.breadcrumbs sets a scoped custom property for children to use, and otherwise establishes a horizontal vertically aligned layout. This ensures that the crumbs, dividers, and icons align.

.breadcrumbs {
  --nav-gap: 2ch;

  display: flex;
  align-items: center;
  gap: var(--nav-gap);
  padding: calc(var(--nav-gap) / 2);
}

Each .crumb also establishes a horizontal vertically aligned layout with some gap, but specially targets its link children and specifies the style white-space: nowrap. This is crucial for multi-word breadcrumbs as we dont want them to go multi-line. Later in this post we'll add styles to handle the horizontal overflow this white-space property caused.

.crumb {
  display: inline-flex;
  align-items: center;
  gap: calc(var(--nav-gap) / 4);

  & > a {
    white-space: nowrap;

    &[aria-current="page"] {
      font-weight: bold;
    }
  }
}

aria-current="page" is added to help the current page link stand out from the rest. Not only will screen reader users have a clear indicator that the link is for the current page, we've visually styled the element to help sighted users get a similar user experience.

The .crumbicon component uses grid to stack an SVG icon with a "nearly invisible" <select> element.

.crumbicon {
  --crumbicon-size: 3ch;

  display: grid;
  grid: [stack] var(--crumbicon-size) / [stack] var(--crumbicon-size);
  place-items: center;

  & > * {
    grid-area: stack;
  }
}

The <select> element is last in the DOM, so it's on top of the stack, and interactive. Add a style of opacity: .01 so the element is still usable, and the result is a select box that fits perfectly to the shape of the icon. This is a nice way to customize the look of a <select> element while maintaining the built-in functionality.

.disguised-select {
  inline-size: 100%;
  block-size: 100%;
  opacity: .01;
  font-size: min(100%, 16px); /* Defaults to 16px; fixes iOS zoom */
}

Overflow #

Breadcrumbs should be able to represent a very long trail. I'm a fan of allowing things to go offscreen horizontally, when appropriate, and I felt this breadcrumbs component qualified well.

.breadcrumbs {
  overflow-x: auto;
  overscroll-behavior-x: contain;
  scroll-snap-type: x proximity;
  scroll-padding-inline: calc(var(--nav-gap) / 2);

  & > .crumb:last-of-type {
    scroll-snap-align: end;
  }

  @supports (-webkit-hyphens:none) { & {
    scroll-snap-type: none;
  }}
}

The overflow styles set up the following UX:

Horizontal scroll with overscroll containment.
Horizontal scroll padding.
One snap point on the last crumb. This means that on page load the first crumb loads snapped and in view.
Removes the snap point from Safari, which struggles with the horizontal scrolling and snap effect combinations.

Media queries #

One subtle adjustment for smaller viewports is to hide the "Home" label, leaving just the icon:

@media (width <= 480px) {
  .breadcrumbs .home-label {
    display: none;
  }
}

Accessibility #

Motion #

There isn't a whole lot of motion in this component, but by wrapping the transition in a prefers-reduced-motion check, we can prevent unwanted motion.

@media (prefers-reduced-motion: no-preference) {
  .crumbicon {
    transition: box-shadow .2s ease;
  }
}

None of the other styles need to change, the hover and focus effects are great and meaningful without a transition, but if motion is okay, we'll add a subtle transition to the interaction.

JavaScript #

First, regardless of the type of router you use in your site or application, when a user changes the breadcrumbs, the URL needs to be updated and the user shown the appropriate page. Second, to normalize the user experience, make sure no unexpected navigations happen when users are just browsing <select> options.

Two critical user experience measures to be handled by JavaScript: select has changed and eager <select> change event firing prevention.

The eager event prevention is needed due to the use of a <select> element. On Windows Edge, and probably other browsers too, the select changed event fires as the user browses options with the keyboard. This is why I called it eager, as the user has only pseudo selected the option, like a hover or focus, yet hasn't confirmed the choice with enter or a click. The eager event makes this component category change feature inaccessible, because opening the select box and simply browsing an item will fire the event and change the page, before the user is ready.

A better `<select>` changed event #

const crumbs = document.querySelectorAll('.breadcrumbs select')
const allowedKeys = new Set(['Tab', 'Enter', ' '])
const preventedKeys = new Set(['ArrowUp', 'ArrowDown'])

// watch crumbs for changes,
// ensures it's a full value change, not a user exploring options via keyboard
crumbs.forEach(nav => {
  let ignoreChange = false

  nav.addEventListener('change', e => {
    if (ignoreChange) return
    // it's actually changed!
  })

  nav.addEventListener('keydown', ({ key }) => {
    if (preventedKeys.has(key))
      ignoreChange = true
    else if (allowedKeys.has(key))
      ignoreChange = false
  })
})

The strategy for this is to watch for keyboard down events on each <select> element and determine if the key pressed was navigation confirmation (Tab or Enter) or spatial navigation (ArrowUp or ArrowDown). With this determination, the component can decide to wait or go, when the event for the <select> element fires.

Conclusion #

Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Tux Solbakk as a web component: demo and code

CSS `size-adjust` for `@font-face`

2021-06-09T00:00:00Z

Consider the following demo where the font-size is a consistent 64px, and the only difference between each of these headers is the font-family. The examples on the left have not been adjusted and have an inconsistent final size. The examples on the right use size-adjust to ensure 64px is the consistent final size.

In this example Chrome DevTools CSS grid layout debug tools are used to show heights.

This post explores a new CSS font-face descriptor called size-adjust. It also demonstrates a few ways to correct and normalize font sizes for smoother user experience, consistent design systems and more predictable page layout. One important use case is optimizing web font rendering to prevent cumulative layout shift (CLS).

Browser support

Chrome 92, Supported 92
Firefox 92, Supported 92
Edge 92, Supported 92
Safari, Not supported

Source

Here's an interactive demo of the problem space. Try changing the typeface with the dropdown and observe:

The height differences in the results.
Visually jarring content shifts.
Moving interactive target areas (the dropdown jumps around!).

See the Pen Pen WNpzRKd by web-dot-dev on Codepen

How to scale fonts with `size-adjust` #

An introduction to the syntax:

@font-face {
  font-family: "Adjusted Typeface";
  size-adjust: 150%;
  src: url(some/path/to/typeface.woff2) format('woff2');
}

Creates a custom typeface named Adjusted Typeface.
Uses size-adjust to scale up each glyph to 150% their default size.
Affects only the single imported typeface.

Use the above custom typeface like this:

h1 {
  font-family: "Adjusted Typeface";
}

See the Pen Pen yLMKgRx by web-dot-dev on Codepen

Mitigating CLS with seamless font swapping #

In the following gif, watch the examples on the left and how there's a shift when the font is changed. This is just a small example with a single headline element and the issue is very noticeable.

The example on the left has layout shift, the one on the right does not.

To improve font rendering, a great technique is font swapping. Render a quick-loading system font to show the content first, then swap that with a web font when the web font finishes loading. This gives you the best of both worlds: the content is visible as soon as possible, and you get a nicely styled page without sacrificing your user's time to content. The problem however, is that sometimes when the web font loads, it shifts the entire page around since it presents at a slightly different box height size.

more content equals more potential layout shift when font swaps

By putting size-adjust in the @font-face rule, it sets a global glyph adjustment for the font face. Timing this right will lead to minimal visual change, a seamless swap. To create a seamless swap, hand adjust or try this size-adjust calculator by Malte Ubl.

Choose a Google Web Font, get back a pre-adjusted @font-face snippet.

At the beginning of this post, fixing the font size issue was done by trial and error. size-adjust was nudged in the source code until the same header in Cookie and Arial rendered the same 64px as Press Start 2P did naturally. I aligned two fonts to a target font size.

@font-face {
  font-family: 'Adjusted Arial';
  size-adjust: 86%;
  src: local(Arial);
}

@font-face {
  font-family: 'Cookie';
  size-adjust: 90.25%;
  src: url(...woff2) format('woff2');
}

See the Pen Pen jOBzyop by web-dot-dev on Codepen

Calibrating fonts #

You as the author determine the calibration target(s) for normalizing font scale. You might normalize on Times, Arial, or a system font, then adjust custom fonts to match. Or, you might adjust local fonts to match what you download.

Strategies for size-adjust calibration:

Remote target:
Adjust local fonts towards downloaded fonts.
Local target:
Adjust downloaded fonts towards local target fonts.

Example 1: Remote target #

Consider the following snippet which adjusts a locally available font to size match a remote src custom font. A remote custom font is the target for calibration, a brand font perhaps:

@font-face {
  font-family: "Adjusted Regular Arial For Brand";
  src: local(Arial);
  size-adjust: 90%;
}

@font-face {
  font-family: "Rad Brand";
  src: url(some/path/to/a.woff2) format('woff2');
}

html {
  font-family: "Rad Brand", "Adjusted Regular Arial For Brand";
}

In this example, local font Arial is adjusting in anticipation of a loaded custom font, for a seamless swap.

This strategy has an advantage of offering designers and developers the same font for sizing and typography. The brand is the calibration target. This is great news for design systems.

Having a brand typeface as the target is also how Malte's calculator works. Choose a Google Font and it will calculate how to adjust Arial to seamlessly swap with it. Here's an example of Roboto CSS from the calculator, where Arial is loaded and named "Roboto-fallback":

@font-face {
    font-family: "Roboto-fallback";
    size-adjust: 100.06%;
    src: local("Arial");
}

To create a fully cross platform adjustment, see the following example which provides 2 adjusted local fallback fonts in anticipation of a brand font.

@font-face {
    font-family: "Roboto-fallback-1";
    size-adjust: 100.06%;
    src: local("Arial");
}

@font-face {
    font-family: "Roboto-fallback-2";
    size-adjust: 99.94%;
    src: local("Arimo");
}

@font-face {
  font-family: "Roboto Regular";
  src: url(some/path/to/roboto.woff2) format('woff2');
}

html {
  font-family: "Roboto Regular", "Roboto-fallback-1", "Roboto-fallback-2";
}

Example 2: Local target #

Consider the following snippet which adjusts a brand custom font to match Arial:

@font-face {
  font-family: "Rad Brand - Adjusted For Arial";
  src: url(some/path/to/a.woff2) format('woff2');
  size-adjust: 110%;
}

html {
  font-family: "Rad Brand - Adjusted For Arial", Arial;
}

This strategy has the advantage of rendering without any adjustments, then adjusting any incoming fonts to match.

Finer tuning with `ascent-override`, `descent-override` and `line-gap-override` #

If generic scaling of glyphs isn't enough adjustment for your design or loading strategies, here are some finer tuning options that work along with size-adjust. The ascent-override, descent-override, and line-gap-override properties are currently implemented in Chromium 87+, and Firefox 89+.

`ascent-override` #

Browser support

Chrome 87, Supported 87
Firefox 89, Supported 89
Edge 87, Supported 87
Safari, Not supported

Source

The ascent-override descriptor defines the height above the baseline of a font.

@font-face {
  font-family: "Ascent Adjusted Arial Bold";
  src: local(Arial Bold);
  ascent-override: 71%;
}

See the Pen Pen ZEexebZ by web-dot-dev on Codepen

The red headline (unadjusted) has space above it's capital letter A and O, while the blue headline has been adjusted so it's cap height fits snug against the overall bounding box.

`descent-override` #

Browser support

Chrome 87, Supported 87
Firefox 89, Supported 89
Edge 87, Supported 87
Safari, Not supported

Source

The descent-override descriptor defines the height below the baseline of the font.

@font-face {
  font-family: "Ascent Adjusted Arial Bold";
  src: local(Arial Bold);
  descent-override: 0%;
}

See the Pen Pen OJpvpNQ by web-dot-dev on Codepen

The red headline (unadjusted) has space below it's D and O baselines, while the blue headline has been adjusted so it's letters rest snug on the baseline.

`line-gap-override` #

Browser support

Chrome 87, Supported 87
Firefox 89, Supported 89
Edge 87, Supported 87
Safari, Not supported

Source

The line-gap-override descriptor defines the line-gap metric for the font. This is the font recommended line-gap or external leading.

@font-face {
  font-family: "Line Gap Adjusted Arial";
  src: local(Arial);
  line-gap-override: 50%;
}

See the Pen Pen xxqWqOw by web-dot-dev on Codepen

The red headline (unadjusted) has no line-gap-override, essentially it's at 0%, while the blue headline has been adjusted up by 50%, creating space above and below the letters accordingly.

Putting it all together #

Each of these overrides offer an additional way to trim excess from the web's safe text bounding box. You can tailor the text box for precise presentation.

See the Pen Pen poeLebG by web-dot-dev on Codepen

Conclusion #

The @font-face size-adjust CSS feature is an exciting way to customize the text bounding box of your web layouts to improve the font swapping experience thus avoiding layout shift for your users. To learn more, check out these resources:

Photo by Kristian Strand on Unsplash

Building a color scheme

2021-06-09T00:00:00Z

In this post I want to share thinking on ways to manage multiple color schemes in CSS. Try the demo.

Demo

If you prefer video, here's a YouTube version of this post:

Overview #

We'll build an accessible color system with custom properties and calc(), to make a webpage that's adaptive to user preferences while keeping the authoring experience minimal. We start with a base brand color and build a system of variants from it: 2 text colors, 4 surface colors and a matching shadow.

This guide begins with defining all of the colors for each color scheme up front. Not until the very end are they used to change the page.

The Brand #

Often, a brand color has already been established and is delivered as hex or rgb. This GUI Challenge has a base brand color of #0af. Firstly, for this color system, the hex value needs converted to hsl.

* {
  --brand: #0af;
  --brand: hsl(200 100% 50%);
}

In order to enable a concept of darkening or lightening the brand color, by say 20%, the 3 channels of the hsl color value need extracted into their own custom properties, like this:

* {
  --brand-hue: 200;
  --brand-saturation: 100%;
  --brand-lightness: 50%;
}

CSS can do math on those color properties, for example calc(var(--brand-lightness) - 20%) to decrease the lightness value by 20%. This is foundational to building a color scheme as CSS can keep all colors in the same hue family by adjusting the hsl saturation and lightness amounts.

Light theme #

Each color variant will be marked with its matching scheme, in this case, each is appended with -light.

Brand #

Starting with the brand color, it's rebuilt by wrapping --brand-hue, --brand-saturation and --brand-lightness custom properties inside the hsl () function parenthesis, without any calculations:

* {
  --brand-light: hsl(var(--brand-hue) var(--brand-saturation) var(--brand-lightness));
}

Text colors #

Next, the essentials of a color scheme need text colors. In a light theme, text should be very dark. Notice how the lightness of the following colors is low, well under 50%.

* {
  --text1-light: hsl(var(--brand-hue) var(--brand-saturation) 10%);
  --text2-light: hsl(var(--brand-hue) 30% 30%);
}

--text1-light, since it's very dark at 10% lightness, keeps the heavy 100% saturation so the brand color can still peek through into the dark dark navy.

--text2-light, it's not quite as dark as the 1st color, which is good as it's a secondary color, and it's also much less saturated.

Surface colors #

Surface colors are the backgrounds, borders and other decorative surfaces that text sits upon or within. In a light theme, these are the light colors, as opposed to the text colors which were dark. To create light colors with hsl, we'll use higher percentage values in the third lightness value. We'll also lower the saturation, so the light greys don't look too tinted.

* {
  --surface1-light: hsl(var(--brand-hue) 25% 90%);
  --surface2-light: hsl(var(--brand-hue) 20% 99%);
  --surface3-light: hsl(var(--brand-hue) 20% 92%);
  --surface4-light: hsl(var(--brand-hue) 20% 85%);
}

4 surface colors were created since decorative colors tend to need more variants, for interactive moments like :focus or :hover or to create the appearance of paper layers. In these scenarios, it's nice to transition --surface2-light on hover to --surface3-light, so a hover results in an increase of contrast (99% lightness to 92% lightness; making it darker).

Shadows #

Shadows within a color scheme are above and beyond, but add a lifelike nature to the effect and help it stand out from unrealistic black based shadows. To do this, the color of the shadow will use the hue custom property, be slightly saturated with the hue but still very dark. Essentially building a very dark slightly blue shadow.

* {
  --surface-shadow-light: var(--brand-hue) 10% 20%;
  --shadow-strength-light: .02;
}

--surface-shadow-light is not wrapped in an hsl function. This is because the --shadow-strength value will be combined to create some opacity, and CSS needs the pieces in order to perform calculations. Skip to the rad shadow section to learn more.

Light colors all together #

No need to hunt around to find how any of the light colors are made, they are all in one place in the CSS.

* {
  --brand-light: hsl(var(--brand-hue) var(--brand-saturation) var(--brand-lightness));
  --text1-light: hsl(var(--brand-hue) var(--brand-saturation) 10%);
  --text2-light: hsl(var(--brand-hue) 30% 30%);
  --surface1-light: hsl(var(--brand-hue) 25% 90%);
  --surface2-light: hsl(var(--brand-hue) 20% 99%);
  --surface3-light: hsl(var(--brand-hue) 20% 92%);
  --surface4-light: hsl(var(--brand-hue) 20% 85%);
  --surface-shadow-light: var(--brand-hue) 10% calc(var(--brand-lightness) / 5);
  --shadow-strength-light: .02;
}

Sandbox on CodePen

Dark theme #

Most brands don't begin with a dark theme, it's a variant of their primary, usually lighter, theme. Users, on the other hand, often choose a dark theme for different contexts, like night time. These factors have led me to keeping two things in mind with dark themes:

Users will generally be in the dark while using this theme, so test in the dark.
Colors should desaturate as to not vibrate on the screen due to being over-intense.

Brand #

The light theme used the 3 brand hsl color channels values without alteration, the dark theme does not. The saturation is cut in half and the lightness reduced a relative 50%.

* {
  --brand-dark: hsl(
    var(--brand-hue)
    calc(var(--brand-saturation) / 2)
    calc(var(--brand-lightness) / 1.5)
  );
}

Text colors #

In a dark theme, the text colors should be light. The following colors have high values for lightness, putting them closer to white.

* {
  --text1-dark: hsl(var(--brand-hue) 15% 85%);
  --text2-dark: hsl(var(--brand-hue) 5% 65%);
}

Surface colors #

In a dark theme, the surface colors should be dark. The following colors have low lightness and saturation, with the 1st surface being the darkest at 10%.

* {
  --surface1-dark: hsl(var(--brand-hue) 10% 10%);
  --surface2-dark: hsl(var(--brand-hue) 10% 15%);
  --surface3-dark: hsl(var(--brand-hue) 5%  20%);
  --surface4-dark: hsl(var(--brand-hue) 5% 25%);
}

Shadows #

In a dark theme, shadows can be very hard to see. Makes sense since it's hard to darken something that's already fairly dark. This is where --shadow-strength-dark comes in super handy as it allows us to darken the shadows by changing one variable.

* {
  --surface-shadow-dark: var(--brand-hue) 50% 3%;
  --shadow-strength-dark: .8;
}

Also, look at how much saturation is in that shadow. Can you notice the color when you're looking at the interface? Try removing the saturation from the devtools, which do you prefer?!

Dark colors all together #

* {
  --brand-dark: hsl(var(--brand-hue) calc(var(--brand-saturation) / 2) calc(var(--brand-lightness) / 1.5));
  --text1-dark: hsl(var(--brand-hue) 15% 85%);
  --text2-dark: hsl(var(--brand-hue) 5% 65%);
  --surface1-dark: hsl(var(--brand-hue) 10% 10%);
  --surface2-dark: hsl(var(--brand-hue) 10% 15%);
  --surface3-dark: hsl(var(--brand-hue) 5%  20%);
  --surface4-dark: hsl(var(--brand-hue) 5% 25%);
  --surface-shadow-dark: var(--brand-hue) 50% 3%;
  --shadow-strength-dark: .8;
}

Sandbox on CodePen

Dim theme #

This color scheme is all about orchestrating lightness and saturation. There should be enough saturation present to still have a hue visible, but should also just barely pass contrast scores since it's intended to be dim and low contrast anyway.

Brand #

* {
  --brand-dim: hsl(
    var(--brand-hue)
    calc(var(--brand-saturation) / 1.25)
    calc(var(--brand-lightness) / 1.25)
  );
}

Text colors #

* {
  --text1-dim: hsl(var(--brand-hue) 15% 75%);
  --text2-dim: hsl(var(--brand-hue) 10% 61%);
}

Surface colors #

* {
  --surface1-dim: hsl(var(--brand-hue) 10% 20%);
  --surface2-dim: hsl(var(--brand-hue) 10% 25%);
  --surface3-dim: hsl(var(--brand-hue) 5%  30%);
  --surface4-dim: hsl(var(--brand-hue) 5% 35%);
}

Shadows #

* {
  --surface-shadow-dim: var(--brand-hue) 30% 13%;
  --shadow-strength-dim: .2;
}

Dim colors all together #

* {
  --brand-dim: hsl(var(--brand-hue) calc(var(--brand-saturation) / 1.25) calc(var(--brand-lightness) / 1.25));
  --text1-dim: hsl(var(--brand-hue) 15% 75%);
  --text2-dim: hsl(var(--brand-hue) 10% 61%);
  --surface1-dim: hsl(var(--brand-hue) 10% 20%);
  --surface2-dim: hsl(var(--brand-hue) 10% 25%);
  --surface3-dim: hsl(var(--brand-hue) 5%  30%);
  --surface4-dim: hsl(var(--brand-hue) 5% 35%);
  --surface-shadow-dim: var(--brand-hue) 30% 13%;
  --shadow-strength-dim: .2;
}

Sandbox on CodePen

Accessible colors #

Notice how the lowest lightness in the dark text color set is 65% and the highlest lightness in the dark surfaces is 25%. That's 40% of lightness breathing room between them. In the light theme, there's 55% breathing room in the light theme. Keeping lightness differences between text and surface colors at around 40-50% can help keep color contrast ratios high, while also being a subtle lever to adjust in case scores are poor.

I call it "bump bump til ya pass", which is the interaction of bumping the lightness value until a tool shows I'm passing.

shift + down arrow is pressed to lower the lightness and increase contrast until passing

Each of the themes created in this challenge pass contrast scores. The dim color scheme has the lowest contrast of them, but still passes the minimum requirements. To help others on the team use good contrasting colors, it's a good idea to create a classname that pairs a surface color with an accessible text color.

.surface1 {
  background-color: var(--surface1);
  color: var(--text2);
}

.surface2 {
  background-color: var(--surface2);
  color: var(--text2);
}

.surface3 {
  background-color: var(--surface3);
  color: var(--text1);
}

.surface4 {
  background-color: var(--surface4);
  color: var(--text1);
}

Screenshot of the dim surface and text pairings with VisBug

Rad Shadow #

The themes use a utility class called .rad-shadow. This shadow was generated at this Smooth Shadow tool, which I appreciate very much. I took its generated snippet and customized it with my own colors and, opacity calculations. The reason for this was to create a shadow I could adjust within each color scheme.

To accomplish this, I created 2 variables for each color scheme to adjust, a shadow color and a shadow strength. The color is for saturation and darkness adjustments, while the strength is for an easy way to drive up the shadow intensity when it's a dark color scheme. End result was something like this.

:root {
  --surface-shadow-light: var(--brand-hue) 10% 20%;
  --shadow-strength-light: .02;
}

.rad-shadow {
  box-shadow:
    0 2.8px 2.2px hsl(var(--surface-shadow) / calc(var(--shadow-strength) + .03)),
    0 6.7px 5.3px hsl(var(--surface-shadow) / calc(var(--shadow-strength) + .01)),
    0 12.5px 10px hsl(var(--surface-shadow) / calc(var(--shadow-strength) + .02)),
    0 22.3px 17.9px hsl(var(--surface-shadow) / calc(var(--shadow-strength) + .02)),
    0 41.8px 33.4px hsl(var(--surface-shadow) / calc(var(--shadow-strength) + .03)),
    0 100px 80px hsl(var(--surface-shadow) / var(--shadow-strength))
  ;
}

If I were to go further with shadows in my color scheme, I'd make the shadow angles a design token constant too, as the light direction should be the same between all the shadows of the design.

Using of the color schemes #

With the predefining of colors complete, it's time to turn them into scheme agnostic properties. What I mean is, as a CSS author inside this color scheme project, one should rarely need to access a specific color scheme's value. I want to make it easy to stay within the theme.

To accomplish this, usage of the color scheme should be exclusively done through the generic custom properties, which we'll be defining in a moment. This way, folks using the design variables never need to worry about which color scheme is currently set, they just need to use the surface and text colors. Instead of color: var(--text1-light) use color: var(--text1). All adapting and pivoting of colors is done much higher level in the CSS.

Diving in, the light theme's connective styles in the following code block, connect a generic custom property with the light theme specific color. Now all uses of var(--brand) will use the light brand color.

Light theme (auto) #

:root {
  color-scheme: light;
  --brand: var(--brand-light);
  --text1: var(--text1-light);
  --text2: var(--text2-light);
  --surface1: var(--surface1-light);
  --surface2: var(--surface2-light);
  --surface3: var(--surface3-light);
  --surface4: var(--surface4-light);
  --surface-shadow: var(--surface-shadow-light);
  --shadow-strength: var(--shadow-strength-light);
}

The site is now using the light theme. This is a very fun successful moment! Let's have a few more of those moments as we use our predefined colors in other color scheme contexts.

Dark theme (auto) #

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

    --brand: var(--brand-dark);
    --text1: var(--text1-dark);
    --text2: var(--text2-dark);
    --surface1: var(--surface1-dark);
    --surface2: var(--surface2-dark);
    --surface3: var(--surface3-dark);
    --surface4: var(--surface4-dark);
    --surface-shadow: var(--surface-shadow-dark);
    --shadow-strength: var(--shadow-strength-dark);
  }
}

Light theme #

[color-scheme="light"] {
  color-scheme: light;

  --brand: var(--brand-light);
  --text1: var(--text1-light);
  --text2: var(--text2-light);
  --surface1: var(--surface1-light);
  --surface2: var(--surface2-light);
  --surface3: var(--surface3-light);
  --surface4: var(--surface4-light);
  --surface-shadow: var(--surface-shadow-light);
  --shadow-strength: var(--shadow-strength-light);
}

Dark theme #

[color-scheme="dark"] {
  color-scheme: dark;

  --brand: var(--brand-dark);
  --text1: var(--text1-dark);
  --text2: var(--text2-dark);
  --surface1: var(--surface1-dark);
  --surface2: var(--surface2-dark);
  --surface3: var(--surface3-dark);
  --surface4: var(--surface4-dark);
  --surface-shadow: var(--surface-shadow-dark);
  --shadow-strength: var(--shadow-strength-dark);
}

Dim theme #

[color-scheme="dim"] {
  color-scheme: dark;

  --brand: var(--brand-dim);
  --text1: var(--text1-dim);
  --text2: var(--text2-dim);
  --surface1: var(--surface1-dim);
  --surface2: var(--surface2-dim);
  --surface3: var(--surface3-dim);
  --surface4: var(--surface4-dim);
  --surface-shadow: var(--surface-shadow-dim);
  --shadow-strength: var(--shadow-strength-dim);
}

At this point, authors are free to use the provided color scheme generics as needed, and should never need to worry about themes again.

See the Pen Pen vYxrrpd by argyleink on Codepen

Conclusion #

Now that you know how I did it, how would you?! 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a Codepen or host your own demo, tweet me with it, and I'll add it to the Community remixes section below.

Source #

Community remixes

@chris-kruining added a hue slider, status colors and contrast modes for no-preference, more and less: demo.

New CSS functional pseudo-class selectors `:is()` and `:where()`

2021-05-27T00:00:00Z

When writing CSS, you can sometimes end up with long selector lists to target multiple elements with the same style rules. For example, if you want to color adjust any <b> tags found inside a heading element, you could write:

h1 > b, h2 > b, h3 > b, h4 > b, h5 > b, h6 > b {
  color: hotpink;
}

Instead, you could use :is() and improve legibility while avoiding a long selector:

:is(h1,h2,h3,h4,h5,h6) > b {
  color: hotpink;
}

Legibility and shorter selector conveniences are only a piece of the value that :is() and :where() bring to CSS. In this post, you'll discover the syntax and value of these two functional pseudo selectors.

An infinite visual of before and after using :is()

Browser compatibility #

`:is()` #

Browser support

Chrome 88, Supported 88
Firefox 78, Supported 78
Edge 88, Supported 88
Safari 14, Supported 14

Source

`:where()` #

Browser support

Chrome 88, Supported 88
Firefox 78, Supported 78
Edge 88, Supported 88
Safari 14, Supported 14

Source

Meet `:is()` and `:where()` #

These are functional pseudo-class selectors, notice the () at the end and the way they start with :. Think of these as runtime dynamic function calls that match elements. When writing CSS, they give you a way to group elements together in the middle, beginning or end of a selector. They also can change specificity, giving you power to nullify or increase specificity.

Selector grouping #

Anything that :is() can do regarding grouping, so can :where(). This includes being used anywhere in the selector, nesting, and stacking them. Full CSS flexibility you know and love. Here's a few examples:

/* at the beginning */
:where(h1,h2,h3,h4,h5,h6) > b {
  color: hotpink;
}

/* in the middle */
article :is(header,footer) > p {
  color: gray;
}

/* at the end */
.dark-theme :where(button,a) {
  color: rebeccapurple;
}

/* multiple */
:is(.dark-theme, .dim-theme) :where(button,a) {
  color: rebeccapurple;
}

/* stacked */
:is(h1,h2):where(.hero,.subtitle) {
  text-transform: uppercase;
}

/* nested */
.hero:is(h1,h2,:is(.header,.boldest)) {
  font-weight: 900;
}

Each of the above selector examples demonstrates the flexibility of these two functional pseudo-classes. To find areas of your code that could benefit from :is() or :where(), look for selectors with multiple commas and selector repetition.

Using simple and complex selectors with `:is()` #

For a brush up on selectors, check out the selectors module on Learn CSS. Here's a few examples of simple and complex selectors to help illustrate the ability:

article > :is(p,blockquote) {
  color: black;
}

:is(.dark-theme.hero > h1) {
  font-weight: bold;
}

article:is(.dark-theme:not(main .hero)) {
  font-size: 2rem;
}

So far, :is() and :where() are syntactically interchangeable. It's time to look at how they're different.

The difference between `:is()` and `:where()` #

When it comes to specificity, :is() and :where() strongly diverge. For a brush up on specificity, see the specificity module on Learn CSS.

In short

:where() has no specificity.
:where() squashes all the specificity in the selector list passed as functional parameters. This is a first of its kind selector feature.
:is() takes the specificity of its most specific selector.
:is(a,div,#id) has a specificity score of an ID, 100 points.

Taking on the highest specificity selector from the list has only been a gotcha for me when I was getting too excited about grouping. I was always able to improve legibility by moving the high specificity selector to it's own selector where it wouldn't have so much impact. Here's an example of what I mean:

article > :is(header, #nav) {
  background: white;
}

/* better as */
article > header,
article > #nav {
  background: white;
}

With :where(), I'm waiting to see libraries offer versions with no specificity. The specificity competition between author styles and library styles could come to an end. There would be no specificity to compete with when writing CSS. CSS has been working on a grouping feature like this for quite some time, it's here, and it's still largely unexplored territory. Have fun making smaller stylesheets and removing commas.

Photo by Markus Winkler on Unsplash

Building a media scroller component

2021-05-12T00:00:00Z

In this post I want to share thinking on ways to create horizontal scrolling experiences for the web that are minimal, responsive, accessible and work across browsers and platforms (like TVs!). Try the demo.

Demo

If you prefer video, here's a YouTube version of this post:

Overview #

We'll be building a horizontal scroll layout meant for hosting thumbnails of media or products. The component begins as a humble <ul> list but is transformed with CSS into a satisfying and smooth scroll experience, showcasing images and snapping them to a grid. JavaScript is added to facilitate roving-index interactions, helping keyboard users skip traversing 100+ items. Plus an experimental media query, prefers-reduced-data, is used to turn the media scroller into a lightweight title scroller experience.

Start with accessible markup #

A media scroller is made of just a couple of core components, a list with items. A list, in its simplest form, can travel all over the world and be clearly consumed by all. A user landing at this page can browse a list and click a link to view an item. This is our accessible base.

Deliver a list with a <ul> element:

<ul class="horizontal-media-scroller">
  <li></li>
  <li></li>
  <li></li>
  ...
<ul>

Make the list items interactive with an <a> element:

<li>
  <a href="#">
    ...
  </a>
</li>

Use a <figure> element to semantically represent an image and its caption:

<figure>
  <picture>
    <img alt="..." loading="lazy" src="https://picsum.photos/500/500?1">
  </picture>
  <figcaption>Legends</figcaption>
</figure>

Notice the alt and loading attributes on the <img>. Alt text for a media scroller is a UX opportunity to help bring the thumbnail extra context, or as fallback text if the image didn't load, or it provides a spoken UI for users relying on assistive technology like a screen reader. Learn more with Five golden rules for compliant alt text.

The loading attribute accepts the keyword lazy as a way to signal this image source should be fetched only when the image is within the viewport. This can be really nice for large lists, as users will only download images for items they scrolled into view.

Support the user's color scheme preference #

Use color-scheme as a <meta> tag to signal to the browser that your page wants both the light and dark provided user-agent styles. It's a free dark mode or light mode, depending on how you look at it:

<meta name="color-scheme" content="dark light">

The meta tag provides the earliest signal possible, so the browser can select a dark default canvas color if the user has a dark theme preference. This means that navigations between pages of the site won't flash a white canvas background between loads. Seamless dark theme between loads, much nicer on the eyes.

Learn much more from Thomas Steiner at https://web.dev/color-scheme/.

Add content #

Given the above content structure of ul > li > a > figure > picture > img, the next task is to add images and titles to scroll through. I've packed the demo with static placeholder images and text, but feel free to power this from your favorite data source.

Add style with CSS #

Now it's time for CSS to take this generic list of content and turn it into an experience. Netflix, App stores and many more sites and apps use horizontal scrolling areas to pack the viewport with categories and options.

Creating the scroller layout #

It's important to avoid cutting off content in layouts or leaning on text truncation with ellipsis. Many television sets have media scrollers just like this one, but all too often resort to ellipsing content. This layout does not! It also lets the media content override the column size, making 1 layout flexible enough to handle many interesting combinations.

The container allows overriding the column size by providing the default size as a custom property. This grid layout is opinionated about column size, it's managing spacing and direction only:

.horizontal-media-scroller {
  --size: 150px;

  display: grid;
  grid-auto-flow: column;
  gap: calc(var(--gap) / 2); /* parent owned value for children to be relative to*/
  margin: 0;
}

The custom property is then used by the <picture> element to create our base aspect ratio: a box:

.horizontal-media-scroller {
  --size: 150px;

  display: grid;
  grid-auto-flow: column;
  gap: calc(var(--gap) / 2);
  margin: 0;

  & picture {
    inline-size: var(--size);
    block-size: var(--size);
  }
}

With only a few more minor styles, complete the barebones of the media scroller:

.horizontal-media-scroller {
  --size: 150px;

  display: grid;
  grid-auto-flow: column;
  gap: calc(var(--gap) / 2);
  margin: 0;

  overflow-x: auto;
  overscroll-behavior-inline: contain;

  & > li {
    display: inline-block; /* removes the list-item bullet */
  }

  & picture {
    inline-size: var(--size);
    block-size: var(--size);
  }
}

Setting overflow sets the <ul> up to allow scrolling and keyboard navigation through its list, then each direct child <li> element has its ::marker removed by getting a new display type of inline-block.

The images aren't responsive yet though, and burst right out of the boxes they're inside. Tame them with some sizes, fit, and border styles, and a background gradient for when they're lazy loading:

img {
  /* smash into whatever box it's in */
  inline-size: 100%;
  block-size: 100%;

  /* don't squish but do cover the space */
  object-fit: cover;

  /* soften the edges */
  border-radius: 1ex;
  overflow: hidden;

  /* if empty, show a gradient placeholder */
  background-image:
    linear-gradient(
      to bottom,
      hsl(0 0% 40%),
      hsl(0 0% 20%)
    );
}

Scroll padding #

Alignment to page content, plus an edge-to-edge scrolling surface area, are critical to a harmonious and minimal component.

To accomplish the edge-to-edge scroll layout which aligns with our typography and layout lines, use padding that matches the scroll-padding:

.horizontal-media-scroller {
  --size: 150px;

  display: grid;
  grid-auto-flow: column;
  gap: calc(var(--gap) / 2);
  margin: 0;

  overflow-x: auto;
  overscroll-behavior-inline: contain;

  padding-inline: var(--gap);
  scroll-padding-inline: var(--gap);
  padding-block: calc(var(--gap) / 2); /* make space for scrollbar and focus outline */
}

Horizontal scroll padding bug fix The above shows how easy it should be to pad a scroll container, but there's outstanding compatibility issues with it (fixed in Chromium 91+ though!). See here for a bit of the history, but the short version is that padding wasn't always accounted for in a scroll view.

To trick browsers into putting the padding at the end of the scroller I'll target the last figure in each list and append a pseudo element that's the amount of padding desired.

.horizontal-media-scroller > li:last-of-type figure {
  position: relative;

  &::after {
    content: "";
    position: absolute;

    inline-size: var(--gap);
    block-size: 100%;

    inset-block-start: 0;
    inset-inline-end: calc(var(--gap) * -1);
  }
}

Using logical properties enables the media scroller to work in any writing mode and document direction.

Scroll snapping #

A scrolling container with overflow can become a snapping viewport with one line of CSS, then it's on children to specify how they'd like to align with that viewport.

.horizontal-media-scroller {
  --size: 150px;

  display: grid;
  grid-auto-flow: column;
  gap: calc(var(--gap) / 2);
  margin: 0;

  overflow-x: auto;
  overscroll-behavior-inline: contain;

  padding-inline: var(--gap);
  scroll-padding-inline: var(--gap);
  padding-block-end: calc(var(--gap) / 2);

  scroll-snap-type: inline mandatory;

  & figure {
    scroll-snap-align: start;
  }
}

Focus #

The inspiration for this component comes from its massive popularity on TVs, in App Stores, and more. Many video game platforms use a media scroller very similar to this one, as their primary home screen layout. Focus is a huge UX moment here, not just a small addition. Imagine using this media scroller from your couch with a remote, give that interaction some small enhancements:

.horizontal-media-scroller a {
  outline-offset: 12px;

  &:focus {
    outline-offset: 7px;
  }

  @media (prefers-reduced-motion: no-preference) {
    & {
      transition: outline-offset .25s ease;
    }
  }
}

This sets the focus outline style 7px away from the box, giving it some nice space. If the user has no motion preferences around reducing motion, the offset is transitioned, giving subtle motion to the focus event.

Roving index #

Gamepad and keyboard users need special attention in these longs lists of scrolling content and options. The common pattern for solving this is called roving index. It's when a container of items is keyboard focused but only 1 child is allowed to hold focus at a time. This single focusable item at a time experience is designed to allow bypassing the potentially long list of items, as opposed to pressing tab 50+ times to reach the end.

There's 300 items in that first scroller of the demo. We can do better than make them traverse all of them to reach the next section.

To create this experience, JavaScript needs to observe keyboard events and focus events. I created a small open source library on npm to help make this user experience easy to achieve. Here's how to use it for the 3 scrollers:

import {rovingIndex} from 'roving-ux';

rovingIndex({
  element: someElement
});

This demo queries the document for the scrollers and for each of them calls the rovingIndex() function. Pass the rovingIndex() the element to get the roving experience, like a list container, and a target query selector, in case the focus targets aren't direct descendants.

document.querySelectorAll('.horizontal-media-scroller')
  .forEach(scroller =>
    rovingIndex({
      element: scroller,
      target: 'a',
}))

To learn more about this effect, see the open source library roving-ux.

Aspect-ratio #

As of writing this post, the support for aspect-ratio is behind a flag in Firefox but available in Chromium browsers or set top boxes. Since the media scroller grid layout only specifies direction and spacing, the sizing can change inside a media query which feature checks for aspect-ratio support. Progressive enhancement into some more dynamic media scrollers.

@supports (aspect-ratio: 1) {
  .horizontal-media-scroller figure > picture {
    inline-size: auto; /* for a block-size driven ratio */
    aspect-ratio: 1; /* boxes by default */

    @nest section:nth-child(2) & {
      aspect-ratio: 16/9;
    }

    @nest section:nth-child(3) & {
      /* double the size of the others */
      block-size: calc(var(--size) * 2);
      aspect-ratio: 4/3;

      /* adjust size to fit more items into the viewport */
      @media (width <= 480px) {
        block-size: calc(var(--size) * 1.5);
      }
    }
  }
}

If the browser supports aspect-ratio syntax, the media scroller pictures are upgraded to aspect-ratio sizing. Using the draft nesting syntax, each picture changes its aspect ratio depending if it's the first, second, or third rows. The nest syntax also allows setting some small viewport adjustments, right there with the other sizing logic.

With that CSS, as the feature is available in more browser engines, an easy to manage but more visually appealing layout will render.

Prefers reduced data #

While this next technique is only available behind a flag in Canary, I wanted to share how I could save a considerable amount of page load time and data use with a few lines of CSS. The prefers-reduced-data media query from level 5 allows asking if the device is in any reduced data states, like a data saver mode. If it is, I can modify the document, and in this case, hide the images.

figure {
  @media (prefers-reduced-data: reduce) {
    & {
      min-inline-size: var(--size);

      & > picture {
        display: none;
      }
    }
  }
}

The content is still navigable but without the cost of the heavy images being downloaded. Here's the site before adding the prefers-reduced-data CSS:

(7 requests, 100kb of resources in 131ms)

Here's the site performance after adding the prefers-reduced-data CSS:

(71 requests, 1.2mb of resources in 1.07s)

64 fewer requests, that would be the ~60 images within the viewport (tests taken on a wide screen display) of this browser tab, a page load boost of ~80%, and 10% of the data over the wire. Pretty powerful CSS.

Conclusion #

Now that you know how I did it, how would you?! 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a Codepen or host your own demo, tweet me with it, and I'll add it to the Community remixes section below.

Source

Community remixes #

Nothing to see here yet!

Building split text animations

2021-04-20T00:00:00Z

In this post I want to share thinking on ways to solve split text animations and interactions for the web that are minimal, accessible, and work across browsers. Try the demo.

Demo

If you prefer video, here's a YouTube version of this post:

Overview #

Split text animations can be amazing. We'll be barely scratching the surface of animation potential in this post, but it does provide a foundation to build upon. The goal is to animate progressively. The text should be readable by default, with the animation built on top. Split text motion effects can get extravagant and potentially disruptive, so we will only manipulate HTML, or apply motion styles if the user is OK with motion.

Here's a general overview of the workflow and results:

Prepare reduced motion conditional variables for CSS and JS.
Prepare split text utilities in JavaScript.
Orchestrate the conditionals and utilities on page load.
Write CSS transitions and animations for letters and words (the rad part!).

Here's a preview of the conditional results we're going for:

User prefers reduced motion: text is legible / unsplit

If a user prefers reduced motion, we leave the HTML document alone and do no animation. If motion is OK, we go ahead and chop it up into pieces. Here's a preview of the HTML after JavaScript has split the text by letter.

User is OK with motion; text split into multiple <span> elements

Preparing motion conditionals #

The conveniently available @media (prefers-reduced-motion: reduce) media query will be used from CSS and JavaScript in this project. This media query is our primary conditional for deciding to split text or not. The CSS media query will be used to withhold transitions and animations, while the JavaScript media query will be used to withhold the HTML manipulation.

Preparing the CSS conditional #

I used PostCSS to enable the syntax of Media Queries Level 5, where I can store a media query boolean into a variable:

@custom-media --motionOK (prefers-reduced-motion: no-preference);

Preparing the JS conditional #

In JavaScript, the browser provides a way to check media queries, I used destructuring to extract and rename the boolean result from the media query check:

const {matches:motionOK} = window.matchMedia(
  '(prefers-reduced-motion: no-preference)'
)

I can then test for motionOK, and only change the document if the user has not requested to reduce motion.

if (motionOK) {
  // document split manipulations
}

I can check the same value by using PostCSS to enable the @nest syntax from Nesting Draft 1. This allows me to store all the logic about the animation and it's style requirements for the parent and children, in one place:

letter-animation {
  @media (--motionOK) {
    /* animation styles */
  }
}

With the PostCSS custom property and a JavaScript boolean, we're ready to conditionally upgrade the effect. That rolls us into the next section where I break down the JavaScript for transforming strings into elements.

Splitting Text #

Text letters, words, lines, etc., cannot be individually animated with CSS or JS. To achieve the effect, we need boxes. If we want to animate each letter, then each letter needs to be an element. If we want to animate each word, then each word needs to be an element.

Create JavaScript utility functions for splitting strings into elements
Orchestrate the usage of these utilities

Splitting letters utility function #

A fun place to start is with a function which takes a string and returns each letter in an array.

export const byLetter = text =>
  [...text].map(span)

The spread syntax from ES6 really helped make that a swift task.

Splitting words utility function #

Similar to splitting letters, this function takes a string and returns each word in an array.

export const byWord = text =>
  text.split(' ').map(span)

The split() method on JavaScript strings allows us to specify which characters to slice at. I passed an empty space, indicating a split between words.

Making boxes utility function #

The effect requires boxes for each letter, and we see in those functions, that map() is being called with a span() function. Here is the span() function.

const span = (text, index) => {
  const node = document.createElement('span')

  node.textContent = text
  node.style.setProperty('--index', index)

  return node
}

It's crucial to note that a custom property called --index is being set with the array position. Having the boxes for the letter animations is great, but having an index to use in CSS is a seemingly small addition with a large impact. Most notable in this large impact is staggering. We'll be able to use --index as a way of offsetting animations for a staggered look.

Utilities conclusion #

The splitting.js module in completion:

const span = (text, index) => {
  const node = document.createElement('span')

  node.textContent = text
  node.style.setProperty('--index', index)

  return node
}

export const byLetter = text =>
  [...text].map(span)

export const byWord = text =>
  text.split(' ').map(span)

Next is importing and using these byLetter() and byWord() functions.

Split orchestration #

With the splitting utilities ready to use, putting it all together means:

Finding which elements to split
Splitting them and replacing text with HTML

After that, CSS takes over and will animate the elements / boxes.

Finding Elements #

I chose to use attributes and values to store information about the desired animation and how to split the text. I liked putting these declarative options into the HTML. The attribute split-by is used from JavaScript, to find elements and create boxes for either letters or words. The attribute letter-animation or word-animation is used from CSS, to target element children and apply transforms and animations.

Here's a sample of HTML that demonstrates the two attributes:

<h1 split-by="letter" letter-animation="breath">animated letters</h1>
<h1 split-by="word" word-animation="trampoline">hover the words</h1>

Finding elements from JavaScript #

I used the CSS selector syntax for attribute presence to gather the list of elements which want their text split:

const splitTargets = document.querySelectorAll('[split-by]')

Finding elements from CSS #

I also used the attribute presence selector in CSS to give all letter animations the same base styles. Later, we'll use the attribute value to add more specific styles to achieve an effect.

letter-animation {
  @media (--motionOK) {
    /* animation styles */
  }
}

Splitting text in place #

For each of the split targets we find in JavaScript, we'll split their text based on the value of the attribute and map each string to a <span>. We can then replace the text of the element with the boxes we made:

splitTargets.forEach(node => {
  const type = node.getAttribute('split-by')
  let nodes = null

  if (type === 'letter') {
    nodes = byLetter(node.innerText)
  }
  else if (type === 'word') {
    nodes = byWord(node.innerText)
  }

  if (nodes) {
    node.firstChild.replaceWith(...nodes)
  }
})

Orchestration conclusion #

index.js in completion:

import {byLetter, byWord} from './splitting.js'

const {matches:motionOK} = window.matchMedia(
  '(prefers-reduced-motion: no-preference)'
)

if (motionOK) {
  const splitTargets = document.querySelectorAll('[split-by]')

  splitTargets.forEach(node => {
    const type = node.getAttribute('split-by')
    let nodes = null

    if (type === 'letter')
      nodes = byLetter(node.innerText)
    else if (type === 'word')
      nodes = byWord(node.innerText)

    if (nodes)
      node.firstChild.replaceWith(...nodes)
  })
}

The JavaScript could be read in the following English:

Import some helper utility functions.
Check if motion is ok for this user, if not do nothing.
For each element that wants to be split.
1. Split them based on how they want to be split.
2. Replace text with elements.

Splitting animations and transitions #

The above splitting document manipulation has just unlocked a multitude of potential animations and effects with CSS or JavaScript. There are a few links at the bottom of this article to help inspire your splitting potential.

Time to show what you can do with this! I'll share 4 CSS driven animations and transitions. 🤓

Split letters #

As a foundation for the split letter effects, I found the following CSS to be helpful. I put all transitions and animations behind the motion media query and then give each new child letter span a display property plus a style for what to do with white spaces:

[letter-animation] > span {
  display: inline-block;
  white-space: break-spaces;
}

The white spaces style is important so that the spans which are only a space, aren't collapsed by the layout engine. Now onto the stateful fun stuff.

Transition split letters example #

This example uses CSS transitions to the split text effect. With transitions we need states for the engine to animate between, and I chose three states: no hover, hover in sentence, hover on a letter.

When the user hovers the sentence, aka the container, I scale back all the children as if the user pushed them further away. Then, as the user hovers a letter, I bring it forward.

@media (--motionOK) {
  [letter-animation="hover"] {
    &:hover > span {
      transform: scale(.75);
    }

    & > span {
      transition: transform .3s ease;
      cursor: pointer;

      &:hover {
        transform: scale(1.25);
      }
    }
  }
}

Animate split letters example #

This example uses a predefined @keyframe animation to infinitely animated each letter, and leverages the inline custom property index to create a stagger effect.

@media (--motionOK) {
  [letter-animation="breath"] > span {
    animation:
      breath 1200ms ease
      calc(var(--index) * 100 * 1ms)
      infinite alternate;
  }
}

@keyframes breath {
  from {
    animation-timing-function: ease-out;
  }
  to {
    transform: translateY(-5px) scale(1.25);
    text-shadow: 0 0 25px var(--glow-color);
    animation-timing-function: ease-in-out;
  }
}

Split words #

Flexbox worked as a container type for me here in these examples, nicely leveraging the ch unit as a healthy gap length.

word-animation {
  display: inline-flex;
  flex-wrap: wrap;
  gap: 1ch;
}

Flexbox devtools showing the gap between words

Transition split words example #

In this transition example I use hover again. As the effect initially hides the content until hover, I ensured that the interaction and styles were only applied if the device had the capability to hover.

@media (hover) {
  [word-animation="hover"] {
    overflow: hidden;
    overflow: clip;

    & > span {
      transition: transform .3s ease;
      cursor: pointer;

      &:not(:hover) {
        transform: translateY(50%);
      }
    }
  }
}

Animate split words example #

In this animation example I use CSS @keyframes again to create a staggered infinite animation on a regular paragraph of text.

[word-animation="trampoline"] > span {
  display: inline-block;
  transform: translateY(100%);
  animation:
    trampoline 3s ease
    calc(var(--index) * 150 * 1ms)
    infinite alternate;
}

@keyframes trampoline {
  0% {
    transform: translateY(100%);
    animation-timing-function: ease-out;
  }
  50% {
    transform: translateY(0);
    animation-timing-function: ease-in;
  }
}

Conclusion #

Now that you know how I did it, how would you?! 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a Codepen or host your own demo, tweet me with it, and I'll add it to the Community remixes section below.

Source

More demos and inspiration

Community remixes #

<text-hover> web component by gnehcwu on CodeSandbox

Take the 2021 scroll survey to help improve scrolling on the web

2021-04-15T00:00:00Z

We've been analyzing the results of the 2019 Mozilla Developer Network Web DNA Report for action items and follow up strategies to improve the top reported issues. A small sub-group on the Chrome team identified a group of issues related to scrolling, scroll-snap, and touch-action. Those issues were researched, evaluated, and synthesized into a new, follow-up survey with more precise questions about issues related to these topics.

2021 Scroll Survey #

We believe that there are many ways to improve scrolling on the web for developers, designers, and users alike. We've created a survey which we hope is respectful of your time. It should take no more than 10 minutes to complete. The results will help browser vendors and standards groups understand how to make scrolling better.

You can take part in the survey at 2021 Web Scrolling Survey.

Building a Settings component

2021-03-17T00:00:00Z

In this post I want to share thinking on building a Settings component for the web that is responsive, supports multiple device inputs, and works across browsers. Try the demo.

Demo

If you prefer video, or want a UI/UX preview of what we're building, here's a shorter walkthrough on YouTube:

Overview #

I've broken out the aspects of this component into the following sections:

Layouts #

This is the first GUI Challenge demo to be all CSS Grid! Here's each grid highlighted with the Chrome DevTools for grid:

Just for gap #

The most common layout:

foo {
  display: grid;
  gap: var(--something);
}

I call this layout "just for gap" because it only uses grid to add gaps between blocks.

Five layouts use this strategy, here's all of them displayed:

The fieldset element, which contains each input group (.fieldset-item), is using gap: 1px to create the hairline borders between elements. No tricky border solution!

Filled gap

.grid {
  display: grid;
  gap: 1px;
  background: var(--bg-surface-1);

  & > .fieldset-item {
    background: var(--bg-surface-2);
  }
}

Border trick

.grid {
  display: grid;

  & > .fieldset-item {
    background: var(--bg-surface-2);

    &:not(:last-child) {
      border-bottom: 1px solid var(--bg-surface-1);
    }
  }
}

Natural grid wrapping #

The most complex layout ended up being the macro layout, the logical layout system between <main> and <form>.

Centering wrapping content #

Flexbox and grid both provide abilities to align-items or align-content, and when dealing with wrapping elements, content layout alignments will distribute space amongst the children as a group.

main {
  display: grid;
  gap: var(--space-xl);
  place-content: center;
}

The main element is using place-content: center alignment shorthand so that the children are centered vertically and horizontally in both one and two column layouts.

Watch in the above video how the "content" stays centered, even though wrapping has occurred.

Repeat auto-fit minmax #

The <form> uses an adaptive grid layout for each section. This layout switches from one to two columns based on available space.

form {
  display: grid;
  gap: var(--space-xl) var(--space-xxl);
  grid-template-columns: repeat(auto-fit, minmax(min(10ch, 100%), 35ch));
  align-items: flex-start;
  max-width: 89vw;
}

This grid has a different value for row-gap (--space-xl) than column-gap (--space-xxl) to put that custom touch on the responsive layout. When the columns stack, we want a large gap, but not as large as if we're on a wide screen.

The grid-template-columns property uses 3 CSS functions: repeat(), minmax() and min(). Una Kravets has a great layout blog post about this, calling it RAM.

There's 3 special additions in our layout, if you compare it to Una's:

We pass an extra min() function.
We specify align-items: flex-start.
There's a max-width: 89vw style.

The extra min() function is well described by Evan Minto on their blog in the post Intrinsically Responsive CSS Grid with minmax() and min(). I recommend giving that a read. The flex-start alignment correction is to remove the default stretching effect, so that the children of this layout don't need to have equal heights, they can have natural, intrinsic heights. The YouTube video has a quick breakdown of this alignment addition.

max-width: 89vw is worth a small breakdown in this post. Let me show you the layout with and without the style applied:

What's happening? When max-width is specified, it's providing context, explicit sizing or definite sizing for the auto-fit layout algorithm to know how many repetitions it can fit into the space. While it seems obvious that the space is "full width", per the CSS grid spec, a definite size or max-size must be provided. I've provided a max-size.

So, why 89vw? Because "it worked" for my layout. Me and a couple of other Chrome folks are investigating why a more reasonable value, like 100vw isn't sufficient, and if this is in fact a bug.

Spacing #

A majority of the harmony of this layout is from a limited palette of spacing, 7 to be exact.

:root {
  --space-xxs: .25rem;
  --space-xs:  .5rem;
  --space-sm:  1rem;
  --space-md:  1.5rem;
  --space-lg:  2rem;
  --space-xl:  3rem;
  --space-xxl: 6rem;
}

Usage of these flows really nicely with grid, CSS @nest, and level 5 syntax of @media. Here's an example, the fully <main> layout set of styles.

main {
  display: grid;
  gap: var(--space-xl);
  place-content: center;
  padding: var(--space-sm);

  @media (width >= 540px) {
    & {
      padding: var(--space-lg);
    }
  }

  @media (width >= 800px) {
    & {
      padding: var(--space-xl);
    }
  }
}

A grid with centered content, moderately padded by default (like on mobile). But as more viewport space becomes available, it spreads out by increasing padding. 2021 CSS is looking pretty good!

Remember the earlier layout, "just for gap"? Here's a more complete version of how they look in this component:

header {
  display: grid;
  gap: var(--space-xxs);
}

section {
  display: grid;
  gap: var(--space-md);
}

Color #

A controlled use of color helped this design stand out as expressive yet minimal. I do it like this:

:root {
  --surface1: lch(10 0 0);
  --surface2: lch(15 0 0);
  --surface3: lch(20 0 0);
  --surface4: lch(25 0 0);

  --text1: lch(95 0 0);
  --text2: lch(75 0 0);
}

I name my surface and text colors with numbers as opposed to names like surface-dark and surface-darker because in a media query, I'll be flipping them, and light and dark won't be meaningful.

I flip them in a preference media query like this:

:root {
  ...

  @media (prefers-color-scheme: light) {
    & {
      --surface1: lch(90 0 0);
      --surface2: lch(100 0 0);
      --surface3: lch(98 0 0);
      --surface4: lch(85 0 0);

      --text1: lch(20 0 0);
      --text2: lch(40 0 0);
    }
  }
}

It's important to get a quick glimpse at the overall picture and strategy before we dive into color syntax details. But, since I've gotten a bit ahead of myself, let me back up a bit.

LCH? #

Without getting too deep into color theory land, LCH is a human oriented syntax, that caters to how we percieve color, not how we measure color with math (like 255). This gives it a distinct advantage as humans can write it more easily and other humans will be in tune with these adjustments.

Learn about perceptual color (and more!) on the CSS Podcast

For today, in this demo, let's focus on the syntax and the values I'm flipping to make light and dark. Let's look at 1 surface and 1 text color:

:root {
  --surface1: lch(10 0 0);
  --text1:    lch(95 0 0);

  @media (prefers-color-scheme: light) {
    & {
      --surface1: lch(90 0 0);
      --text1:    lch(40 0 0);
    }
  }
}

--surface1: lch(10 0 0) translates to 10% lightness, 0 chroma and 0 hue: a very dark colorless gray. Then, in the media query for light mode, the lightness is flipped to 90% with --surface1: lch(90 0 0);. And that's the gist of the strategy. Start by just changing lightness between the 2 themes, maintaining the contrast ratios the design calls for or what can maintain accessibility.

The bonus with lch() here is that lightness is human oriented, and we can feel good about a % change to it, that it will be perceptually and consistently that % different. hsl() for example is not as reliable.

There's more to learn about color spaces and lch() if you're interested. It's coming!

CSS right now cannot access these colors at all. Let me repeat: We have no access to one third of the colors in most modern monitors. And these are not just any colors, but the most vivid colors the screen can display. Our websites are washed out because monitor hardware evolved faster than CSS specs and browser implementations.

Lea Verou

Adaptive form controls with color-scheme #

Many browsers ship dark theme controls, currently Safari and Chromium, but you have to specify in CSS or HTML that your design uses them.

The above is demonstrating the effect of the property from the Styles panel of DevTools. The demo uses the HTML tag, which in my opinion is generally a better location:

<meta name="color-scheme" content="dark light">

Learn all about it in this color-scheme article by Thomas Steiner. There's a lot more to gain than dark checkbox inputs!

CSS `accent-color` #

There's been recent activity around accent-color on form elements, being a single CSS style that can change the tint color used in the browsers input element. Read more about it here on GitHub. I've included it in my styles for this component. As browsers support it, my checkboxes will be more on theme with the pink and purple color pops.

input[type="checkbox"] {
  accent-color: var(--brand);
}

Color pops with fixed gradients and focus-within #

Color pops most when it's used sparingly, and one of the ways I like to achieve that is through colorful UI interactions.

There are many layers of UI feedback and interaction in the above video, which help give personality to the interaction by:

Highlighting context.
Providing UI feedback of "how full" the value is in the range.
Providing UI feedback that a field is accepting input.

To provide feedback when an element is being interacted with, CSS is using the :focus-within pseudo class to change the appearance of various elements, let's break down the .fieldset-item, it's super interesting:

.fieldset-item {
  ...

  &:focus-within {
    background: var(--surface2);

    & svg {
      fill: white;
    }

    & picture {
      clip-path: circle(50%);
      background: var(--brand-bg-gradient) fixed;
    }
  }
}

When one of the children of this element has focus-within:

The .fieldset-item background is assigned a higher contrast surface color.
The nested svg is filled white for higher contrast.
The nested <picture> clip-path expands to a full circle and the background is filled with the bright fixed gradient.

Custom range #

Given the following HTML input element, I'll show you how I customized its appearance:

<input type="range">

There's 3 parts to this element we need to customize:

Range element styles #

input[type="range"] {
  /* style setting variables */
  --track-height: .5ex;
  --track-fill: 0%;
  --thumb-size: 3ex;
  --thumb-offset: -1.25ex;
  --thumb-highlight-size: 0px;

  appearance: none;         /* clear styles, make way for mine */
  display: block;
  inline-size: 100%;        /* fill container */
  margin: 1ex 0;            /* ensure thumb isn't colliding with sibling content */
  background: transparent;  /* bg is in the track */
  outline-offset: 5px;      /* focus styles have space */
}

The first few lines of CSS are the custom parts of the styles, and I hope that clearly labeling them helps. The rest of the styles are mostly reset styles, to provide a consistent foundation for building the tricky parts of the component.

Track styles #

input[type="range"]::-webkit-slider-runnable-track {
  appearance: none; /* clear styles, make way for mine */
  block-size: var(--track-height);
  border-radius: 5ex;
  background:
    /* hard stop gradient:
        - half transparent (where colorful fill we be)
        - half dark track fill
        - 1st background image is on top
    */
    linear-gradient(
      to right,
      transparent var(--track-fill),
      var(--surface1) 0%
    ),
    /* colorful fill effect, behind track surface fill */
    var(--brand-bg-gradient) fixed;
}

The trick to this is "revealing" the vibrant fill color. This is done with the hard stop gradient on top. The gradient is transparent up to the fill percentage, and after that uses the unfilled track surface color. Behind that unfilled surface, is a full width color, waiting for transparency to reveal it.

Track fill style #

My design does require JavaScript in order to maintain the fill style. There are CSS only strategies but they require the thumb element to be the same height as the track, and I wasn't able to find a harmony within those limits.

/* grab sliders on page */
const sliders = document.querySelectorAll('input[type="range"]')

/* take a slider element, return a percentage string for use in CSS */
const rangeToPercent = slider => {
  const max = slider.getAttribute('max') || 10;
  const percent = slider.value / max * 100;

  return `${parseInt(percent)}%`;
};

/* on page load, set the fill amount */
sliders.forEach(slider => {
  slider.style.setProperty('--track-fill', rangeToPercent(slider));

  /* when a slider changes, update the fill prop */
  slider.addEventListener('input', e => {
    e.target.style.setProperty('--track-fill', rangeToPercent(e.target));
  })
})

I think this makes for a nice visual upgrade. The slider works great without JavaScript, the --track-fill prop is not required, it simply will not have a fill style if not present. If JavaScript is available, populate the custom property while also observing any user changes, syncing the custom property with the value.

Here's a great post on CSS-Tricks by Ana Tudor, that demonstrates a CSS only solution for track fill. I also found this range element very inspiring.

Thumb styles #

input[type="range"]::-webkit-slider-thumb {
  appearance: none; /* clear styles, make way for mine */
  cursor: ew-resize; /* cursor style to support drag direction */
  border: 3px solid var(--surface3);
  block-size: var(--thumb-size);
  inline-size: var(--thumb-size);
  margin-top: var(--thumb-offset);
  border-radius: 50%;
  background: var(--brand-bg-gradient) fixed;
}

The majority of these styles are to make a nice circle. Again you see the fixed background gradient there that unifies the dynamic colors of the thumbs, tracks and associated SVG elements. I separated the styles for the interaction to help isolate the box-shadow technique being used for the hover highlight:

@custom-media --motionOK (prefers-reduced-motion: no-preference);

::-webkit-slider-thumb {
  …

  /* shadow spread is initally 0 */
  box-shadow: 0 0 0 var(--thumb-highlight-size) var(--thumb-highlight-color);

  /* if motion is OK, transition the box-shadow change */
  @media (--motionOK) {
    & {
      transition: box-shadow .1s ease;
    }
  }

  /* on hover/active state of parent, increase size prop */
  @nest input[type="range"]:is(:hover,:active) & {
    --thumb-highlight-size: 10px;
  }
}

The goal was an easy to manage and animated visual highlight for user feedback. By using a box shadow I can avoid triggering layout with the effect. I do this by creating a shadow that's not blurred and matches the circular shape of the thumb element. Then I change and transition it's spread size on hover.

If only the highlight effect was so easy on checkboxes…

Cross browser selectors #

I found I needed these -webkit- and -moz- selectors to achieve cross browser consistency:

input[type="range"] {
  &::-webkit-slider-runnable-track {}
  &::-moz-range-track {}
  &::-webkit-slider-thumb {}
  &::-moz-range-thumb {}
}

Custom Checkbox #

Given the following HTML input element, I'll show you how I customized its appearance:

<input type="checkbox">

There's 3 parts to this element we need to customize:

Checkbox element #

input[type="checkbox"] {
  inline-size: var(--space-sm);   /* increase width */
  block-size: var(--space-sm);    /* increase height */
  outline-offset: 5px;            /* focus style enhancement */
  accent-color: var(--brand);     /* tint the input */
  position: relative;             /* prepare for an absolute pseudo element */
  transform-style: preserve-3d;   /* create a 3d z-space stacking context */
  margin: 0;
  cursor: pointer;
}

The transform-style and position styles prepare for the pseudo-element we will introduce later to style the highlight. Otherwise, it's mostly minor opinionated style stuff from me. I like the cursor to be pointer, I like outline offsets, default checkboxes are too tiny, and if accent-color is supported, bring these checkboxes into the brand color scheme.

Checkbox labels #

It's important to provide labels for checkboxes for 2 reasons. The first is to represent what the checkbox value is used for, to answer "on or off for what?" Second is for UX, web users have become accustomed to interacting with checkboxes via their associated labels.

input

<input
  type="checkbox"
  id="text-notifications"
  name="text-notifications"
>

label

<label for="text-notifications">
  <h3>Text Messages</h3>
  <small>Get notified about all text messages sent to your device</small>
</label>

On your label, put a for attribute that points to a checkbox by ID: <label for="text-notifications">. On your checkbox, double up both the name and id to ensure it's found with varying tools and tech, like a mouse or screenreader: <input type="checkbox" id="text-notifications" name="text-notifications">. :hover, :active and more come for free with the connection, increasing the ways your form can be interacted with.

Checkbox highlight #

I want to keep my interfaces consistent, and the slider element has a nice thumbnail highlight that I'd like to use with the checkbox. The thumbnail was able to use box-shadow and it's spread property to scale a shadow up and down. However, that effect doesn't work here because our checkboxes are, and should be, square.

I was able to achieve the same visual effect with a pseudo element, and an unfortunate amount of tricky CSS:

@custom-media --motionOK (prefers-reduced-motion: no-preference);

input[type="checkbox"]::before {
  --thumb-scale: .01;                        /* initial scale of highlight */
  --thumb-highlight-size: var(--space-xl);

  content: "";
  inline-size: var(--thumb-highlight-size);
  block-size: var(--thumb-highlight-size);
  clip-path: circle(50%);                     /* circle shape */
  position: absolute;                         /* this is why position relative on parent */
  top: 50%;                                   /* pop and plop technique (https://web.dev/centering-in-css/#5-pop-and-plop) */
  left: 50%;
  background: var(--thumb-highlight-color);
  transform-origin: center center;            /* goal is a centered scaling circle */
  transform:                                  /* order here matters!! */
    translateX(-50%)                          /* counter balances left: 50% */
    translateY(-50%)                          /* counter balances top: 50% */
    translateZ(-1px)                          /* PUTS IT BEHIND THE CHECKBOX */
    scale(var(--thumb-scale))                 /* value we toggle for animation */
  ;
  will-change: transform;

  @media (--motionOK) {                       /* transition only if motion is OK */
    & {
      transition: transform .2s ease;
    }
  }
}

/* on hover, set scale custom property to "in" state */
input[type="checkbox"]:hover::before {
  --thumb-scale: 1;
}

Creating a circle psuedo-element is straightforward work, but placing it behind the element it's attached to was harder. Here's before and after I fixed it:

It's definitely a micro interaction, but important to me to keep the visual consistency. The animation scaling technique is the same as we've been using in other places. We set a custom property to a new value and let CSS transition it based on motion preferences. The key feature here is translateZ(-1px). The parent created a 3D space and this pseudo-element child tapped into it by placing itself slightly back in z-space.

Accessibility #

The YouTube video does a great demonstration of the mouse, keyboard and screenreader interactions for this settings component. I'll call out some of the details here.

HTML Element Choices #

<form>
<header>
<fieldset>
<picture>
<label>
<input>

Each of these holds hints and tips to the user's browsing tool. Some elements provide interaction hints, some connect interactivity, and some help shape the acccessibility tree that a screenreader navigates.

HTML Attributes #

We can hide elements that are not needed by screenreaders, in this case the icon next to the slider:

<picture aria-hidden="true">

The above video demonstrates the screenreader flow on Mac OS. Notice how input focus moves straight from one slider to the next. This is because we've hidden the icon that may have been a stop on the way to the next slider. Without this attribute, a user would need to stop, listen and move past the picture which they may not be able to see.

The SVG is a bunch of math, let's add a <title> element for a free mouse hover title and a human readable comment about what the math is creating:

<svg viewBox="0 0 24 24">
  <title>A note icon</title>
  <path d="M12 3v10.55c-.59-.34-1.27-.55-2-.55-2.21 0-4 1.79-4 4s1.79 4 4 4 4-1.79 4-4V7h4V3h-6z"/>
</svg>

Other than that, we've used enough clearly marked HTML, that the form tests really well across mouse, keyboard, video game controllers and screenreaders.

JavaScript #

I've already covered how the track fill color was being managed from JavaScript, so let's look at the <form> related JavaScript now:

const form = document.querySelector('form');

form.addEventListener('input', event => {
  const formData = Object.fromEntries(new FormData(form));
  console.table(formData);
})

Everytime the form is interacted with and changed, the console logs the form as an object into a table for easy review before submitting to a server.

Conclusion #

Now that you know how I did it, how would you?! This makes for some fun component architecture! Who's going to make the 1st version with slots in their favorite framework? 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a demo, tweet me links, and I'll add it to the Community remixes section below!

Community remixes #

@tomayac with their style regarding the hover area for the checkbox labels! This version has no hover gap between elements: demo and source.

Building a Tabs component

2021-02-17T00:00:00Z

In this post I want to share thinking on building a Tabs component for the web that is responsive, supports multiple device inputs, and works across browsers. Try the demo.

Demo

If you prefer video, here's a YouTube version of this post:

Overview #

Tabs are a common component of design systems but can take many shapes and forms. First there were desktop tabs built on <frame> element, and now we have buttery mobile components that animate content based on physics properties. They're all trying to do the same thing: save space.

Today, the essentials of a tabs user experience is a button navigation area which toggles the visibility of content in a display frame. Many different content areas share the same space, but are conditionally presented based on the button selected in the navigation.

A collage of tab component web design styles from over the past 10 years

Web Tactics #

All in all I found this component pretty straightforward to build, thanks to a few critical web platform features:

scroll-snap-points for elegant swipe and keyboard interactions with appropriate scroll stop positions
Deep links via URL hashes for browser handled in-page scroll anchoring and sharing support
Screen reader support with <a> and id="#hash" element markup
prefers-reduced-motion for enabling crossfade transitions and instant in-page scrolling
The in-draft @scroll-timeline web feature for dynamically underlining and color changing the selected tab

The HTML #

Fundamentally, the UX here is: click a link, have the URL represent the nested page state, and then see the content area update as the browser scrolls to the matching element.

There are some structural content members in there: links and :targets. We need a list of links, which a <nav> is great for, and a list of <article> elements, which a <section> is great for. Each link hash will match a section, letting the browser scroll things via anchoring.

A link button is clicked, sliding in focused content

For example, clicking a link automatically focuses the :target article in Chrome 89, no JS required. The user can then scroll the article content with their input device as always. It's complimentary content, as indicated in the markup.

I used the following markup to organize the tabs:

<snap-tabs>
  <header>
    <nav>
      <a></a>
      <a></a>
      <a></a>
      <a></a>
    </nav>
  </header>
  <section>
    <article></article>
    <article></article>
    <article></article>
    <article></article>
  </section>
</snap-tabs>

I can establish connections between the <a> and <article> elements with href and id properties like this:

<snap-tabs>
  <header>
    <nav>
      <a href="#responsive"></a>
      <a href="#accessible"></a>
      <a href="#overscroll"></a>
      <a href="#more"></a>
    </nav>
  </header>
  <section>
    <article id="responsive"></article>
    <article id="accessible"></article>
    <article id="overscroll"></article>
    <article id="more"></article>
  </section>
</snap-tabs>

I next filled the articles with mixed amounts of lorem, and the links with a mixed length and image set of titles. With content to work with, we can begin layout.

Scrolling layouts #

There are 3 different types of scroll areas in this component:

The navigation (pink) is horizontally scrollable
The content area (blue) is horizontally scrollable
Each article item (green) is vertically scrollable.

There's 2 different types of elements involved with scrolling:

A window
A box with defined dimensions that has the overflow property style.
An oversized surface
In this layout, it's the list containers: nav links, section articles, and article contents.

`<snap-tabs>` layout #

The top level layout I chose was flex (Flexbox). I set the direction to column, so the header and section are vertically ordered. This is our first scroll window, and it hides everything with overflow hidden. The header and section will employ overscroll soon, as individual zones.

HTML

<snap-tabs>
  <header></header>
  <section></section>
</snap-tabs>

CSS

snap-tabs {
  display: flex;
  flex-direction: column;

  /* establish primary containing box */
  overflow: hidden;
  position: relative;

  & > section {
    /* be pushy about consuming all space */
    block-size: 100%;
  }

  & > header {
    /* defend against <section> needing 100% */
    flex-shrink: 0;
    /* fixes cross browser quarks */
    min-block-size: fit-content;
  }
}

Pointing back to the colorful 3-scroll diagram:

<header> is now prepared to be the (pink) scroll container.
<section> is prepared to be the (blue) scroll container.

The frames I've highlighted below with VisBug help us see the windows the scroll containers have created.

Tabs `<header>` layout #

The next layout is nearly the same: I use flex to create vertical ordering.

HTML

<snap-tabs>
  <header>
    <nav></nav>
    <span class="snap-indicator"></span>
  </header>
  <section></section>
</snap-tabs>

CSS

header {
  display: flex;
  flex-direction: column;
}

The .snap-indicator should travel horizontally with the group of links, and this header layout helps set that stage. No absolute positioned elements here!

Next, the scroll styles. It turns out that we can share the scroll styles between our 2 horizontal scroll areas (header and section), so I made a utility class, .scroll-snap-x.

.scroll-snap-x {
  /* browser decide if x is ok to scroll and show bars on, y hidden */
  overflow: auto hidden;
  /* prevent scroll chaining on x scroll */
  overscroll-behavior-x: contain;
  /* scrolling should snap children on x */
  scroll-snap-type: x mandatory;

  @media (hover: none) {
    scrollbar-width: none;

    &::-webkit-scrollbar {
      width: 0;
      height: 0;
    }
  }
}

Each needs overflow on the x axis, scroll containment to trap overscroll, hidden scrollbars for touch devices and lastly scroll-snap for locking content presentation areas. Our keyboard tab order is accessible and any interactions guide focus naturally. Scroll snap containers also get a nice carousel style interaction from their keyboard.

Tabs header `<nav>` layout #

The nav links need to be laid out in a line, with no line breaks, vertically centered, and each link item should snap to the scroll-snap container. Swift work for 2021 CSS!

HTML

<nav>
  <a></a>
  <a></a>
  <a></a>
  <a></a>
</nav>

CSS

nav {
  display: flex;

  & a {
    scroll-snap-align: start;

    display: inline-flex;
    align-items: center;
    white-space: nowrap;
  }
}

Each link styles and sizes itself, so the nav layout only needs to specify direction and flow. Unique widths on nav items makes the transition between tabs fun as the indicator adjusts its width to the new target. Depending on how many elements are in here, the browser will render a scrollbar or not.

Tabs `<section>` layout #

This section is a flex item and needs to be the dominant consumer of space. It also needs to create columns for the articles to be placed into. Again, swift work for CSS 2021! The block-size: 100% stretches this element to fill the parent as much as possible, then for its own layout, it creates a series of columns that are 100% the width of the parent. Percentages work great here because we've written strong constraints on the parent.

HTML

<section>
  <article></article>
  <article></article>
  <article></article>
  <article></article>
</section>

CSS

section {
  block-size: 100%;

  display: grid;
  grid-auto-flow: column;
  grid-auto-columns: 100%;
}

It's as if we're saying "expand vertically as much as possible, in a pushy way" (remember the header we set to flex-shrink: 0: it is a defense against this expansion push), which sets the row height for a set of full height columns. The auto-flow style tells the grid to always lay children out in a horizontal line, no wrapping, exactly what we want; to overflow the parent window.

I find these difficult to wrap my head around sometimes! This section element is fitting into a box, but also created a set of boxes. I hope the visuals and explanations are helping.

Tabs `<article>` layout #

The user should be able to scroll the article content, and the scrollbars should only show up if there is overflow. These article elements are in a neat position. They are simultaneously a scroll parent and a scroll child. The browser is really handling some tricky touch, mouse, and keyboard interactions for us here.

HTML

<article>
  <h2></h2>
  <p></p>
  <p></p>
  <h2></h2>
  <p></p>
  <p></p>
  ...
</article>

CSS

article {
  scroll-snap-align: start;

  overflow-y: auto;
  overscroll-behavior-y: contain;
}

I chose to have the articles snap within their parent scroller. I really like how the navigation link items and the article elements snap to the inline-start of their respective scroll containers. It looks and feels like a harmonious relationship.

The article is a grid child, and it's size is predetermined to be the viewport area we want to provide scroll UX. This means I don't need any height or width styles here, I just need to define how it overflows. I set overflow-y to auto, and then also trap the scroll interactions with the handy overscroll-behavior property.

3 scroll areas recap #

Below I've chosen in my system settings to "always show scrollbars". I think it's doubly important for the layout to work with this setting turned on, as it is for me to review the layout and the scroll orchestration.

I think seeing the scrollbar gutter in this component helps clearly show where the scroll areas are, the direction they support, and how they interact with each other. Consider how each of these scroll window frames also are flex or grid parents to a layout.

DevTools can help us visualize this:

Chromium Devtools, showing the flexbox nav element layout full of anchor elements, the grid section layout full of article elements, and the article elements full of paragraphs and a heading element.

The scroll layouts are complete: snapping, deep linkable, and keyboard accessible. Strong foundation for UX enhancements, style and delight.

Feature highlight #

Scroll snapped children maintain their locked position during resize. This means JavaScript won't need to bring anything into view on device rotate or browser resize. Try it out in Chromium DevTools Device Mode by selecting any mode other than Responsive, and then resizing the device frame. Notice the element stays in view and locked with its content. This has been available since Chromium updated their implementation to match the spec. Here's a blog post about it.

Animation #

The goal of the animation work here is to clearly link interactions with UI feedback. This helps guide or assist the user through to their (hopefully) seamless discovery of all the content. I'll be adding motion with purpose and conditionally. Users can now specify their motion preferences in their operating system, and I thoroughly enjoy responding to their preferences in my interfaces.

I'll be linking a tab underline with the article scroll position. Snapping isn't only pretty alignment, it's also anchoring the start and end of an animation. This keeps the <nav>, which acts like a mini-map, connected to the content. We'll be checking the user's motion preference from both CSS and JS. There's a few great places to be considerate!

Scroll behavior #

There's an opportunity to enhance the motion behavior of both :target and element.scrollIntoView(). By default, it's instant. The browser just sets the scroll position. Well, what if we want to transition to that scroll position, instead of blink there?

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

Since we're introducing motion here, and motion that the user doesn't control (like scrolling), we only apply this style if the user has no preference in their operating system around reduced motion. This way, we only introduce scroll motion for folks who are OK with it.

Tabs indicator #

The purpose of this animation is to help associate the indicator with the state of the content. I decided to color crossfade border-bottom styles for users who prefer reduced motion, and a scroll linked sliding + color fade animation for users who are OK with motion.

In Chromium Devtools, I can toggle the preference and demonstrate the 2 different transition styles. I had a ton of fun building this.

@media (prefers-reduced-motion: reduce) {
  snap-tabs > header a {
    border-block-end: var(--indicator-size) solid hsl(var(--accent) / 0%);
    transition: color .7s ease, border-color .5s ease;

    &:is(:target,:active,[active]) {
      color: var(--text-active-color);
      border-block-end-color: hsl(var(--accent));
    }
  }

  snap-tabs .snap-indicator {
    visibility: hidden;
  }
}

I hide the .snap-indicator when the user prefers reduced motion since I don't need it anymore. Then I replace it with border-block-end styles and a transition. Also notice in the tabs interaction that the active nav item not only has a brand underline highlight, but it's text color also is darker. The active element has higher text color contrast and a bright underlight accent.

Just a few extra lines of CSS will make someone feel seen (in the sense that we're thoughtfully respecting their motion preferences). I love it.

`@scroll-timeline` #

In the above section I showed you how I handle the reduced motion crossfade styles, and in this section I'll show you how I linked the indicator and a scroll area together. This is some fun experimental stuff up next. I hope you're as excited as me.

const { matches:motionOK } = window.matchMedia(
  '(prefers-reduced-motion: no-preference)'
);

I first check the user's motion preference from JavaScript. If the result of this is false, meaning the user prefers reduced motion, then we'll not run any of the scroll linking motion effects.

if (motionOK) {
  // motion based animation code
}

At the time of writing this, the browser support for @scroll-timeline is none. It's a draft spec with only experimental implementations. It has a polyfill though, which I use in this demo.

`ScrollTimeline` #

While CSS and JavaScript can both create scroll timelines, I opted into JavaScript so I could use live element measurements in the animation.

const sectionScrollTimeline = new ScrollTimeline({
  scrollSource: tabsection,  // snap-tabs > section
  orientation: 'inline',     // scroll in the direction letters flow
  fill: 'both',              // bi-directional linking
});

I want 1 thing to follow another's scroll position, and by creating a ScrollTimeline I define the driver of the scroll link, the scrollSource. Normally an animation on the web runs against a global time frame tick, but with a custom sectionScrollTimeline in memory, I can change all that.

tabindicator.animate({
    transform: ...,
    width: ...,
  }, {
    duration: 1000,
    fill: 'both',
    timeline: sectionScrollTimeline,
  }
);

Before I get into the keyframes of the animation, I think it's important to point out the follower of the scrolling, tabindicator, will be animated based on a custom timeline, our section's scroll. This completes the linkage, but is missing the final ingredient, stateful points to animate between, also known as keyframes.

Dynamic keyframes #

There's a really powerful pure declarative CSS way to animate with @scroll-timeline, but the animation I chose to do was too dynamic. There's no way to transition between auto width, and there's no way to dynamically create a number of keyframes based on children length.

JavaScript knows how to get that information though, so we'll iterate over the children ourselves and grab the computed values at runtime:

tabindicator.animate({
    transform: [...tabnavitems].map(({offsetLeft}) =>
      `translateX(${offsetLeft}px)`),
    width: [...tabnavitems].map(({offsetWidth}) =>
      `${offsetWidth}px`)
  }, {
    duration: 1000,
    fill: 'both',
    timeline: sectionScrollTimeline,
  }
);

For each tabnavitem, destructure the offsetLeft position and return a string that uses it as a translateX value. This creates 4 transform keyframes for the animation. The same is done for width, each is asked what its dynamic width is and then it's used as a keyframe value.

Here's example output, based on my fonts and browser preferences:

TranslateX Keyframes:

[...tabnavitems].map(({offsetLeft}) =>
  `translateX(${offsetLeft}px)`)

// results in 4 array items, which represent 4 keyframe states
// ["translateX(0px)", "translateX(121px)", "translateX(238px)", "translateX(464px)"]

Width Keyframes:

[...tabnavitems].map(({offsetWidth}) =>
  `${offsetWidth}px`)

// results in 4 array items, which represent 4 keyframe states
// ["121px", "117px", "226px", "67px"]

To summarize the strategy, the tab indicator will now animate across 4 keyframes depending on the scroll snap position of the section scroller. The snap points create clear delineation between our keyframes and really add to the synchronized feel of the animation.

The user drives the animation with their interaction, seeing the width and position of the indicator change from one section to the next, tracking perfectly with scroll.

You may not have noticed, but I'm very proud of the transition of color as the highlighted navigation item becomes selected.

The unselected lighter grey appears even more pushed back when the highlighted item has more contrast. It's common to transition color for text, like on hover and when selected, but it's next-level to transition that color on scroll, synchronized with the underline indicator.

Here's how I did it:

tabnavitems.forEach(navitem => {
  navitem.animate({
      color: [...tabnavitems].map(item =>
        item === navitem
          ? `var(--text-active-color)`
          : `var(--text-color)`)
    }, {
      duration: 1000,
      fill: 'both',
      timeline: sectionScrollTimeline,
    }
  );
});

Each tab nav link needs this new color animation, tracking the same scroll timeline as the underline indicator. I use the same timeline as before: since it's role is to emit a tick on scroll, we can use that tick in any type of animation we want. As I did before, I create 4 keyframes in the loop, and return colors.

[...tabnavitems].map(item =>
  item === navitem
    ? `var(--text-active-color)`
    : `var(--text-color)`)

// results in 4 array items, which represent 4 keyframe states
// [
  "var(--text-active-color)",
  "var(--text-color)",
  "var(--text-color)",
  "var(--text-color)",
]

The keyframe with the color var(--text-active-color) highlights the link, and it's otherwise a standard text color. The nested loop there makes it relatively straightforward, as the outer loop is each nav item, and the inner loop is each navitem's personal keyframes. I check if the outer loop element is the same as the inner loop one, and use that to know when it's selected.

I had a lot of fun writing this. So much.

Even more JavaScript enhancements #

It's worth a reminder that the core of what I'm showing you here works without JavaScript. With that said, let's see how we can enhance it when JS is available.

Deep links #

Deep links are more of a mobile term, but I think the intent of the deep link is met here with tabs in that you can share a URL directly to a tab's contents. The browser will in-page navigate to the ID that is matched in the URL hash. I found this onload handler made the effect across platforms.

window.onload = () => {
  if (location.hash) {
    tabsection.scrollLeft = document
      .querySelector(location.hash)
      .offsetLeft;
  }
}

Scroll end synchronization #

Our users aren't always clicking or using a keyboard, sometimes they're just free scrolling, as they should be able to. When the section scroller stops scrolling, wherever it lands needs to be matched in the top navigation bar.

Here's how I wait for scroll end:

tabsection.addEventListener('scroll', () => {
  clearTimeout(tabsection.scrollEndTimer);
  tabsection.scrollEndTimer = setTimeout(determineActiveTabSection, 100);
});

Whenever the sections are being scrolled, clear the section timeout if there, and start a new one. When sections stop being scrolled, don't clear the timeout, and fire 100ms after resting. When it fires, call function that seeks to figure out where the user stopped.

const determineActiveTabSection = () => {
  const i = tabsection.scrollLeft / tabsection.clientWidth;
  const matchingNavItem = tabnavitems[i];

  matchingNavItem && setActiveTab(matchingNavItem);
};

Assuming the scroll snapped, dividing the current scroll position from the width of the scroll area should result in an integer and not a decimal. I then try to grab a navitem from our cache via this calculated index, and if it finds something, I send the match to be set active.

const setActiveTab = tabbtn => {
  tabnav
    .querySelector(':scope a[active]')
    .removeAttribute('active');

  tabbtn.setAttribute('active', '');
  tabbtn.scrollIntoView();
};

Setting the active tab starts by clearing any currently active tab, then giving the incoming nav item the active state attribute. The call to scrollIntoView() has a fun interaction with CSS that is worth noting.

.scroll-snap-x {
  overflow: auto hidden;
  overscroll-behavior-x: contain;
  scroll-snap-type: x mandatory;

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

In the horizontal scroll snap utility CSS, we've nested a media query which applies smooth scrolling if the user is motion tolerant. JavaScript can freely make calls to scroll elements into view, and CSS can manage the UX declaratively. Quite the delightful little match they make sometimes.

Conclusion #

Now that you know how I did it, how would you?! This makes for some fun component architecture! Who's going to make the 1st version with slots in their favorite framework? 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a Glitch, tweet me your version, and I'll add it to the Community remixes section below.

Community remixes #

@devnook, @rob_dodson, and @DasSurma with Web Components: article.
@jhvanderschee with buttons: Codepen.

Building a sidenav component

2021-01-21T00:00:00Z

In this post I want to share with you how I prototyped a Sidenav component for the web that is responsive, stateful, supports keyboard navigation, works with and without JavaScript, and works across browsers. Try the demo.

If you prefer video, here's a YouTube version of this post:

Overview #

It's tough building a responsive navigation system. Some users will be on a keyboard, some will have powerful desktops, and some will visit from a small mobile device. Everyone visiting should be able to open and close the menu.

Desktop to mobile responsive layout demo

Light and dark theme down on iOS and Android

Web Tactics #

In this component exploration I had the joy of combining a few critical web platform features:

CSS :target
CSS grid
CSS transforms
CSS Media Queries for viewport and user preference
JS for focus UX enhancements

My solution has one sidebar and toggles only when at a "mobile" viewport of 540px or less. 540px will be our breakpoint for switching between the mobile interactive layout and the static desktop layout.

CSS `:target` pseudo-class #

One <a> link sets the url hash to #sidenav-open and the other to empty (''). Lastly, an element has the id to match the hash:

<a href="#sidenav-open" id="sidenav-button" title="Open Menu" aria-label="Open Menu">

<a href="#" id="sidenav-close" title="Close Menu" aria-label="Close Menu"></a>

<aside id="sidenav-open">
  …
</aside>

Clicking each of these links changes the hash state of our page URL, then with a pseudo-class I show and hide the sidenav:

@media (max-width: 540px) {
  #sidenav-open {
    visibility: hidden;
  }

  #sidenav-open:target {
    visibility: visible;
  }
}

CSS Grid #

In the past, I only used absolute or fixed position sidenav layouts and components. Grid though, with its grid-area syntax, lets us assign multiple elements to the same row or column.

Stacks #

The primary layout element #sidenav-container is a grid that creates 1 row and 2 columns, 1 of each are named stack. When space is constrained, CSS assigns all of the <main> element's children to the same grid name, placing all elements into the same space, creating a stack.

#sidenav-container {
  display: grid;
  grid: [stack] 1fr / min-content [stack] 1fr;
  min-height: 100vh;
}

@media (max-width: 540px) {
  #sidenav-container > * {
    grid-area: stack;
  }
}

The <aside> is the animating element that contains the side navigation. It has 2 children: the navigation container <nav> named [nav] and a backdrop <a> named [escape], which is used to close the menu.

#sidenav-open {
  display: grid;
  grid-template-columns: [nav] 2fr [escape] 1fr;
}

Adjust 2fr & 1fr to find the ratio you like for the menu overlay and its negative space close button.

A demo of what happens when you change the ratio.

CSS 3D transforms & transitions #

Our layout is now stacked at a mobile viewport size. Until I add some new styles, it's overlaying our article by default. Here's some UX I'm shooting for in this next section:

Animate open and close
Only animate with motion if the user is OK with that
Animate visibility so keyboard focus doesn't enter the offscreen element

As I begin to implement motion animations, I want to start with accessibility top of mind.

Accessible motion #

Not everyone will want a slide out motion experience. In our solution this preference is applied by adjusting a --duration CSS variable inside a media query. This media query value represents a user's operating system preference for motion (if available).

#sidenav-open {
  --duration: .6s;
}

@media (prefers-reduced-motion: reduce) {
  #sidenav-open {
    --duration: 1ms;
  }
}

A demo of the interaction with and without duration applied.

Now when our sidenav is sliding open and closed, if a user prefers reduced motion, I instantly move the element into view, maintaining state without motion.

Transition, transform, translate #

Sidenav out (default) #

To set the default state of our sidenav on mobile to an offscreen state, I position the element with transform: translateX(-110vw).

Note, I added another 10vw to the typical offscreen code of -100vw, to ensure the box-shadow of the sidenav doesn't peek into the main viewport when it's hidden.

@media (max-width: 540px) {
  #sidenav-open {
    visibility: hidden;
    transform: translateX(-110vw);
    will-change: transform;
    transition:
      transform var(--duration) var(--easeOutExpo),
      visibility 0s linear var(--duration);
  }
}

Sidenav in #

When the #sidenav element matches as :target, set the translateX() position to homebase 0, and watch as CSS slides the element from its out position of -110vw, to its "in" position of 0 over var(--duration) when the URL hash is changed.

@media (max-width: 540px) {
  #sidenav-open:target {
    visibility: visible;
    transform: translateX(0);
    transition:
      transform var(--duration) var(--easeOutExpo);
  }
}

Transition visibility #

The goal now is to hide the menu from screenreaders when it's out, so systems don't put focus into an offscreen menu. I accomplish this by setting a visibility transition when the :target changes.

When going in, don't transition visibility; be visible right away so I can see the element slide in and accept focus.
When going out, transition visibility but delay it, so it flips to hidden at the end of the transition out.

Accessibility UX enhancements #

Links #

This solution relies on changing the URL in order for the state to be managed. Naturally, the <a> element should be used here, and it gets some nice accessibility features for free. Let's adorn our interactive elements with labels clearly articulating intent.

<a href="#" id="sidenav-close" title="Close Menu" aria-label="Close Menu"></a>

<a href="#sidenav-open" id="sidenav-button" class="hamburger" title="Open Menu" aria-label="Open Menu">
  <svg>...</svg>
</a>

A demo of the voiceover and keyboard interaction UX.

Now our primary interaction buttons clearly state their intent for both mouse and keyboard.

`:is(:hover, :focus)` #

This handy CSS functional pseudo-selector lets us swiftly be inclusive with our hover styles by sharing them with focus as well.

.hamburger:is(:hover, :focus) svg > line {
  stroke: hsl(var(--brandHSL));
}

Sprinkle on JavaScript #

Press `escape` to close #

The Escape key on your keyboard should close the menu right? Let's wire that up.

const sidenav = document.querySelector('#sidenav-open');

sidenav.addEventListener('keyup', event => {
  if (event.code === 'Escape') document.location.hash = '';
});

Browser history #

In order to prevent the open and close interaction from stacking multiple entries into the browser history, add the following JavaScript inline to the close button:

<a href="#" id="sidenav-close" title="Close Menu" aria-label="Close Menu" onchange="history.go(-1)"></a>

This will remove the URL history entry on close, making it as if the menu was never opened.

Focus UX #

The next snippet helps us put focus on the open and close buttons after they open or close. I want to make toggling easy.

sidenav.addEventListener('transitionend', e => {
  const isOpen = document.location.hash === '#sidenav-open';

  isOpen
      ? document.querySelector('#sidenav-close').focus()
      : document.querySelector('#sidenav-button').focus();
})

When the sidenav opens, focus the close button. When the sidenav closes, focus the open button. I do this by calling focus() on the element in JavaScript.

Conclusion #

Now that you know how I did it, how would you?! This makes for some fun component architecture! Who's going to make the 1st version with slots? 🙂

Let's diversify our approaches and learn all the ways to build on the web. Create a Glitch, tweet me your version, and I'll add it to the Community remixes section below.

Community remixes #

@_developit with custom elements: demo & code
@mayeedwin1 with HTML/CSS/JS: demo & code
@a_nurella with a Glitch Remix: demo & code
@EvroMalarkey with HTML/CSS/JS: demo & code

Codelab: Building a Sidenav component

2021-01-21T00:00:00Z

This codelab teaches you how to build a responsive slide out side navigation layout component on the web. We'll build the component as we go, starting with HTML, then CSS, then JavaScript.

Check out my blog post Building a Sidenav component to learn about the CSS web platform features chosen for building this component.

Setup #

Click Remix to Edit to make the project editable.
Open app/index.html.

HTML #

First, get the essentials of the HTML setup so there's content and some boxes to work with.

Drop the following HTML into the <body> tag.

<aside></aside>
<main></main>

The <aside> holds the navigation menu as a complimentary element to <main>, which holds the primary page content.

Next we'll fill in those semantic elements with the rest of the page content.

Add a navigation element, some navigation links and a close link inside the <aside> element.

<aside>
  <nav>
    <h4>My</h4>
    <a href="#">Dashboard</a>
    <a href="#">Profile</a>
    <a href="#">Preferences</a>
    <a href="#">Archive</a>

    <h4>Settings</h4>
    <a href="#">Accessibility</a>
    <a href="#">Theme</a>
    <a href="#">Admin</a>
  </nav>

  <a href="#"></a>
</aside>

Links go great inside <nav> elements, and <nav> elements go great in <aside> sidebars. Still, there's more we can do to improve.

In the main content element, add a header and an article to semantically hold the layout content.

<main>
  <header>
    <a href="#sidenav-open" class="hamburger">
      <svg viewBox="0 0 50 40">
        <line x1="0" x2="100%" y1="10%" y2="10%" />
        <line x1="0" x2="100%" y1="50%" y2="50%" />
        <line x1="0" x2="100%" y1="90%" y2="90%" />
      </svg>
    </a>
    <h1>Site Title</h1>
  </header>

  <article>
    {put some placeholder content here}
  </article>
</main>

The header has the menu open link. The aside has the close button. We'll show and hide elements based on viewport size soon.

In the <article> element, we pasted a placeholder sentence. Replace `` with your own stuff, or paste the lorem provided below:

<h2>Totam Header</h2>
<p>Lorem ipsum dolor, sit amet consectetur adipisicing elit. Cum consectetur, necessitatibus velit officia ut impedit veritatis temporibus soluta? Totam odit cupiditate facilis nisi sunt hic necessitatibus voluptatem nihil doloribus! Enim.</p>
<p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Fugit rerum, amet odio explicabo voluptas eos cum libero, ex esse quasi optio incidunt soluta eligendi labore error corrupti! Dolore, cupiditate porro.</p>

<h3>Subhead Totam Odit</h3>
<p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Fugit rerum, amet odio explicabo voluptas eos cum libero, ex esse quasi optio incidunt soluta eligendi labore error corrupti! Dolore, cupiditate porro.</p>
<p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Fugit rerum, amet odio explicabo voluptas eos cum libero, ex esse quasi optio incidunt soluta eligendi labore error corrupti! Dolore, cupiditate porro.</p>

<h3>Subhead</h3>
<p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Fugit rerum, amet odio explicabo voluptas eos cum libero, ex esse quasi optio incidunt soluta eligendi labore error corrupti! Dolore, cupiditate porro.</p>
<p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Fugit rerum, amet odio explicabo voluptas eos cum libero, ex esse quasi optio incidunt soluta eligendi labore error corrupti! Dolore, cupiditate porro.</p>

This content, and it's length, are what will cause the page to be scrollable when it exceeds your viewport height.

So far you've added an aside element, with a nav, links and a way to close the sidenav. You also added a header, a way to open the sidenav, and an article to the main element. This is clean, semantic and pretty timeless already, but we can make it cleaner and clearer for everyone. The open link in the sidenav could be more clearly marked.

Add attributes title and aria-label to the header open link element:

<a href="#sidenav-open" class="hamburger">
<a href="#sidenav-open" title="Open Menu" aria-label="Open Menu" class="hamburger">

The open SVG icon could be more clearly marked as well. Add the following attributes to the SVG inside the open link element:

<svg viewBox="0 0 50 40">
<svg viewBox="0 0 50 40" role="presentation" focusable="false" aria-label="trigram for heaven symbol">

The close link in the sidenav could be more clearly marked. Add attributes title and aria-label to the sidenav close link element:

<a href="#"></a>
<a href="#" title="Close Menu" aria-label="Close Menu"></a>

CSS #

Time to layout the elements. The main content and sidenav are direct children of the <body> tag, so that's a good place to start.

Add the following CSS into css/sidenav.css so the <body> element lays out the children.

body {
  display: grid;
  grid: [stack] 1fr / min-content [stack] 1fr;

  @media (max-width: 540px) {
    & > :matches(aside, main) {
      grid-area: stack;
    }
  }
}

This layout essentially says: Create a named row stack with everything in it, and 2 columns in that row, the 2nd of which is named stack also. The 1st column should be sized by its minimal content needs, and the 2nd column can take up the rest. Then, if in a constrained viewport of 540px or less, put the sidenav and main content elements into the same row and column, resulting in them being on top of each other in a 1x1 grid.

With this responsive stacking functionality as a base, we can now leverage the state of the URL bar to toggle the visibility and transition style of the sidenav.

Update the <aside> element back in app/index.html:

<aside>
<aside id="sidenav-open">

This enables CSS to match an element and the URL hash together. This is important for :target usage. Now the element's ID can match the URL hash we'll be setting with <a> tags.

In addition, for easier JavaScript targeting, add IDs for key elements that control the sidenav. First, add an ID to the sidenav open link:

<a href="#sidenav-open" class="hamburger" title="Open Menu" aria-label="Open Menu">
<a href="#sidenav-open" id="sidenav-button" class="hamburger" title="Open Menu" aria-label="Open Menu">

Next, add an ID to the sidenav close link:

<a href="#" title="Close Menu" aria-label="Close Menu"></a>
<a href="#" id="sidenav-close" title="Close Menu" aria-label="Close Menu"></a>

That wraps up the macro <body> responsive stacking layout, plus ties us into the URL bar. Let's keep going!

The <aside> has a neat layout too. It has 2 children, a <nav> which is the paper-like looking component that slides out, and a closing <a> link element that sets the url has to #. The link is invisible to the right of the paper slide out nav; it's so folks can "click off" the visual component to dismiss it.

Add the following CSS to css/sidenav.css:

#sidenav-open {
  display: grid;
  grid-template-columns: [nav] 2fr [escape] 1fr;
}

I thought the ratio and names were a really nice touch here, where grid could shine and give a designer a lot of control.

Next I need to conditionally overlay the main content and persist my position through any document scrolling. This is a great job for position: sticky and some overscroll-behavior.

Add the following styles for the sidenav:

#sidenav-open {
  display: grid;
  grid-template-columns: [nav] 2fr [escape] 1fr;

  @media (max-width: 540px) {
    position: sticky;
    top: 0;
    max-height: 100vh;
    overflow: hidden auto;
    overscroll-behavior: contain;

    visibility: hidden; /* not keyboard accessible when closed */
  }
}

Those styles ensure the sidenav is the viewport height, scrolls vertically and contains the scroll. Very importantly, it hides the element. By default, when the viewport is 540px or smaller, hide that sidenav. Unless!

Add a :target pseudo-selector to the #sidenav-open element:

#sidenav-open {

  @media (max-width: 540px) {

    &:target {
      visibility: visible;
    }
  }
}

When the ID of that element and the URL bar are the same, set visibility to visible. Go ahead and open the side menu after scrolling the page, or try scrolling the page while the sidenav is open. What do you think?

Add the following CSS to the bottom of app/sidenav.css:

#sidenav-button,
#sidenav-close {
  -webkit-tap-highlight-color: transparent;
  -webkit-touch-callout: none;
  user-select: none;
  touch-action: manipulation;

  @media (min-width: 540px) {
    display: none;
  }
}

These styles target our open and close buttons, specifies their tap and touch styles, and also hides them when viewports are 540px or larger.

For some flair, let's add CSS transforms with respectful accessibility. Add the following CSS to css/sidenav.css:

#sidenav-open {
  --easeOutExpo: cubic-bezier(0.16, 1, 0.3, 1);
  --duration: .6s;

  ...

  @media (max-width: 540px) {
    ...

    transform: translateX(-110vw);
    will-change: transform;
    transition:
      transform var(--duration) var(--easeOutExpo),
      visibility 0s linear var(--duration);

    &:target {
      visibility: visible;
      transform: translateX(0);
      transition: transform var(--duration) var(--easeOutExpo);
    }
  }

  @media (prefers-reduced-motion: reduce) {
    --duration: 1ms;
  }
}

A demo of the interaction with and without duration applied based on the `prefers-reduced-motion` media query.

Sprinkle in some JavaScript #

The Escape key should close the menu. Add this JS to js/index.js:

const sidenav = document.querySelector('#sidenav-open');

sidenav.addEventListener('keyup', e => {
  if (e.code === 'Escape') {
    document.location.hash = '';
  }
});

This listens for a key event on the sidenav element. If it's Escape, it sets the URL hash to empty, making the sidenav transition out.

This next piece of UX JS is focus management. I want to make opening and closing easy, so I wait until the sidenav has finished a transition of some kind, then cross check it against the URL hash to determine if it's in or out. I then use JavaScript to set the focus on the button complimentary to the one they just pressed.

Add the following JavaScript to js/index.js:

const closenav = document.querySelector('#sidenav-close');
const opennav = document.querySelector('#sidenav-button');

sidenav.addEventListener('transitionend', e => {
  if (e.propertyName !== 'transform') {
    return;
  }

  const isOpen = document.location.hash === '#sidenav-open';

  isOpen
    ? closenav.focus()
    : opennav.focus();
});

Try it out #

To preview the site, press View App. Then press Fullscreen .

Conclusion #

That's a wrap up for the needs I had with the component. Feel free to build upon it, drive it with JavaScript state instead of the URL, and in general make it yours! There's always more to add or more use cases to cover.

Open up css/brandnav.css to check out the non-layout related styles that I applied to this component. I didn't feel it was important to the feature set I was focusing on, and I hoped that separating styles from layout would encourage copy and paste. There could be more learning for you there!

How do you make slide out responsive sidenav components? Do you ever have more than 1, like one on both sides? I'd love to feature your solution in a YouTube video, make sure to tweet at me or comment in YouTube with your code, it'll help everyone out!

Centering in CSS

2020-12-16T00:00:00Z

Centering in CSS is a notorious challenge, fraught with jokes and mockery. 2020 CSS is all grown up and now we can laugh at those jokes honestly, not through clenched teeth.

If you prefer video, here's a YouTube version of this post:

The challenge #

There are different types of centering. From differing use cases, number of things to center, etc. In order to demonstrate a rationale behind "a winning" centering technique, I created The Resilience Ringer. It's a series of stress tests for each centering strategy to balance within and you to observe their performance. At the end, I reveal the highest scoring technique, as well as a "most valuable." Hopefully you walk away with new centering techniques and solutions.

The Resilience Ringer #

The Resilience Ringer is a representation of my beliefs that a centering strategy should be resilient to international layouts, variable sized viewports, text edits and dynamic content. These tenets helped shape the following resilience tests for the centering techniques to endure:

Squished: centering should be able to handle changes to width
Squashed: centering should be able to handle changes to height
Duplicate: centering should be dynamic to number of items
Edit: centering should be dynamic to length and language of content
Flow: centering should be document direction and writing mode agnostic

The winning solution should demonstrate its resilience by keeping contents in center while being squished, squashed, duplicated, edited, and swapped to various language modes and directions. Trustworthy and resilient center, a safe center.

Legend #

I've provided some visual color hinting to help you keep some meta information in context:

A pink border indicates ownership of centering styles
The grey box is the background on the container which seeks to have centered items
Each child has a white background color so you can see any effects the centering technique has on child box sizes (if any)

The 5 Contestants #

5 centering techniques enter the Resilience Ringer, only one will receive the Resilience Crown 👸.

1. Content Center #

Editing and duplicating content with VisBug

Squish: great!
Squash: great!
Duplicate: great!
Edit: great!
Flow: great!

It's going to be hard to beat the conciseness of display: grid and the place-content shorthand. Since it centers and justifies children collectively, it's a solid centering technique for groups of elements meant to be read.

.content-center {
  display: grid;
  place-content: center;
  gap: 1ch;
}

Pros

Content is centered even under constrained space and overflow
Centering edits and maintenance are all in one spot
Gap guarantees equal spacing amongst n children
Grid creates rows by default

Cons

The widest child (max-content) sets the width for all the rest. This will be discussed more in Gentle Flex.

Great for macro layouts containing paragraphs and headlines, prototypes, or generally things that need legible centering.

2. Gentle Flex #

Squish: great!
Squash: great!
Duplicate: great!
Edit: great!
Flow: great!

Gentle Flex is a truer centering-only strategy. It's soft and gentle, because unlike place-content: center, no children's box sizes are changed during the centering. As gently as possible, all items are stacked, centered, and spaced.

.gentle-flex {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  gap: 1ch;
}

Pros

Only handles alignment, direction, and distribution
Edits and maintenance are all in one spot
Gap guarantees equal spacing amongst n children

Cons

Most lines of code

Great for both macro and micro layouts.

3. Autobot #

Squish: great
Squash: great
Duplicate: fine
Edit: great
Flow: great

The container is set to flex with no alignment styles, while the direct children are styled with auto margins. There's something nostalgic and wonderful about margin: auto working on all sides of the element.

.autobot {
  display: flex;
}
.autobot > * {
  margin: auto;
}

Pros

Fun trick
Quick and dirty

Cons

Awkward results when overflowing
Reliance on distribution instead of gap means layouts can occur with children touching sides
Being "pushed" into position doesn't seem optimal and can result in a change to the child's box size

Great for centering icons or pseudo-elements.

4. Fluffy Center #

Squish: bad
Squash: bad
Duplicate: bad
Edit: great!
Flow: great! (so long as you use logical properties)

Contestant "fluffy center" is by far our tastiest sounding contender, and is the only centering technique that's entirely element/child owned. See our solo inner pink border!?

.fluffy-center {
  padding: 10ch;
}

Pros

Protects content
Atomic
Every test is secretly containing this centering strategy
Word space is gap

Cons

Illusion of not being useful
There's a clash between the container and the items, naturally since each are being very firm about their sizing

Great for word or phrase-centric centering, tags, pills, buttons, chips, and more.

5. Pop & Plop #

Squish: okay
Squash: okay
Duplicate: bad
Edit: fine
Flow: fine

This "pops" because the absolute positioning pops the element out of normal flow. The "plop" part of the names comes from when I find it most useful: plopping it on top of other stuff. It's a classic and handy overlay centering technique that's flexible and dynamic to content size. Sometimes you just need to plop UI on top of other UI.

Pros

Useful
Reliable
When you need it, it’s invaluable

Cons

Code with negative percentage values
Requires position: relative to force a containing block
Early and awkward line breaks
There can be only 1 per containing block without additional effort

Great for modals, toasts and messages, stacks and depth effects, popovers.

The winner #

If I was on an island and could only have 1 centering technique, it would be…

[drum roll]

Gentle Flex 🎉

.gentle-flex {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  gap: 1ch;
}

You can always find it in my stylesheets because it's useful for both macro and micro layouts. It's an all-around reliable solution with results that match my expectations. Also, because I'm an intrinsic sizing junkie, I tend to graduate into this solution. True, it's a lot to type out, but the benefits it provides outweighs the extra code.

MVP #

Fluffy Center

.fluffy-center {
  padding: 2ch;
}

Fluffy Center is so micro that it's easy to overlook as a centering technique, but it's a staple of my centering strategies. It's so atomic that sometimes I forget I'm using it.

Conclusion #

What types of things break your centering strategies? What other challenges could be added to the resilience ringer? I considered translation and an auto-height switch on the container… what else!?

Now that you know how I did it, how would you?! Let's diversify our approaches and learn all the ways to build on the web. Follow the codelab with this post to create your own centering example, just like the ones in this post. Tweet me your version, and I'll add it to the Community remixes section below.

Community remixes #

CSS Tricks with a blog post

Codelab: Centering in CSS

2020-12-16T00:00:00Z

This codelab sets you up to share and showcase your favorite way of centering in CSS.

Check out my blog post Centering in CSS to learn about 5 of my favorite ways to center in CSS. Or watch this video!

Setup #

Click Remix to Edit to make the project editable.
Open app/index.html
At line 23, replace /* your centering CSS here /* with your CSS
(optional) Name your centering technique and replace the text in the <h1>

Styles #

Create a new file in the app/css/ folder
Create a selector to hold your centering solution, like .turbo-center or [floaty-mcfloat]
Within that new selector, write your centering technique (feel free to look at the other's in app/css/ as examples)
(optional) write some "support styles" so we can see which children need styles to support the centering
Open app/css/index.css and import your new file at the bottom

Tie it all up #

Open app/index.html again
Find the <article> and give it your custom selector you made in step #2 of the previous section.
Tweet me your Glitch and I'll feature it on the blog post!

Building a Stories component

2020-11-25T00:00:00Z

In this post I want to share thinking on building a Stories component for the web that is responsive, supports keyboard navigation, and works across browsers.

Demo

If you would prefer a hands-on demonstration of building this Stories component yourself, check out the Stories component codelab.

If you prefer video, here's a YouTube version of this post:

Overview #

Two popular examples of the Stories UX are Snapchat Stories and Instagram Stories (not to mention fleets). In general UX terms, Stories are usually a mobile-only, tap-centric pattern for navigating multiple subscriptions. For example, on Instagram, users open a friend's story and go through the pictures in it. They generally do this many friends at a time. By tapping on the right side of the device, a user skips ahead to that friend's next story. By swiping right, a user skips ahead to a different friend. A Story component is fairly similar to a carousel, but allows navigating a multi-dimensional array as opposed to a single-dimensional array. It's as if there's a carousel inside each carousel. 🤯

1st carousel of friends
2nd "stacked" carousel of stories
👍 List in a list, aka: a multi-dimensional array

Picking the right tools for the job #

All in all I found this component pretty straightforward to build, thanks to a few critical web platform features. Let's cover them!

CSS Grid #

Our layout turned out to be no tall order for CSS Grid as it's equipped with some powerful ways to wrangle content.

Friends layout #

Our primary .stories component wrapper is a mobile-first horizontal scrollview:

.stories {
  inline-size: 100vw;
  block-size: 100vh;

  display: grid;
  grid: 1fr / auto-flow 100%;
  gap: 1ch;

  overflow-x: auto;
  scroll-snap-type: x mandatory;
  overscroll-behavior: contain;
  touch-action: pan-x;
}

/* desktop constraint */
@media (hover: hover) and (min-width: 480px) {
  max-inline-size: 480px;
  max-block-size: 848px;
}

Using Chrome DevTools' Device Mode to highlight the columns created by Grid

Let's breakdown that grid layout:

We explicitly fill the viewport on mobile with 100vh and 100vw and constrain the size on desktop
/ separates our row and column templates
auto-flow translates to grid-auto-flow: column
The autoflow template is 100%, which in this case is whatever the scroll window width is

On a mobile phone, think of this like the row size being the viewport height and each column being the viewport width. Continuing with the Snapchat Stories and Instagram Stories example, each column will be a friend's story. We want friends stories to continue outside of the viewport so we have somewhere to scroll to. Grid will make however many columns it needs to layout your HTML for each friend story, creating a dynamic and responsive scrolling container for us. Grid enabled us to centralize the whole effect.

Stacking #

For each friend we need their stories in a pagination-ready state. In preparation for animation and other fun patterns, I chose a stack. When I say stack, I mean like you're looking down on a sandwich, not like you're looking from the side.

With CSS grid, we can define a single-cell grid (i.e. a square), where the rows and columns share an alias ([story]), and then each child gets assigned to that aliased single-cell space:

.user {
  display: grid;
  grid: [story] 1fr / [story] 1fr;
  scroll-snap-align: start;
  scroll-snap-stop: always;
}

.story {
  grid-area: story;
  background-size: cover;
  …
}

This puts our HTML in control of the stacking order and also keeps all elements in flow. Notice how we didn't need to do anything with absolute positioning or z-index and we didn't need to box correct with height: 100% or width: 100%. The parent grid already defined the size of the story picture viewport, so none of these story components needed to be told to fill it!

CSS Scroll Snap Points #

The CSS Scroll Snap Points spec makes it a cinch to lock elements into the viewport on scroll. Before these CSS properties existed, you had to use JavaScript, and it was… tricky, to say the least. Check out Introducing CSS Scroll Snap Points by Sarah Drasner for a great breakdown of how to use them.

Horizontal scrolling without and with scroll-snap-points styles. Without it, users can free scroll as normal. With it, the browser rests gently on each item.

parent

.stories {
  display: grid;
  grid: 1fr / auto-flow 100%;
  gap: 1ch;
  overflow-x: auto;
  scroll-snap-type: x mandatory;
  overscroll-behavior: contain;
  touch-action: pan-x;
}

Parent with overscroll defines snap behavior.

child

.user {
  display: grid;
  grid: [story] 1fr / [story] 1fr;
  scroll-snap-align: start;
  scroll-snap-stop: always;
}

Children opt into being a snap target.

I chose Scroll Snap Points for a few reasons:

Free accessibility. The Scroll Snap Points spec states that pressing the Left Arrow and Right Arrow keys should move through the snap points by default.
A growing spec. The Scroll Snap Points spec is getting new features and improvements all the time, which means that my Stories component will probably only get better from here on out.
Ease of implementation. Scroll Snap Points are practically built for the touch-centric horizontal-pagination use case.
Free platform-style inertia. Every platform will scroll and rest in its style, as opposed to normalized inertia which can have an uncanny scrolling and resting style.

Cross-browser compatibility #

We tested on Opera, Firefox, Safari, and Chrome, plus Android and iOS. Here's a brief rundown of the web features where we found differences in capabilities and support.

We did though have some CSS not apply, so some platforms are currently missing out on UX optimizations. I did enjoy not needing to manage these features and feel confident that they'll eventually reach other browsers and platforms.

`scroll-snap-stop` #

Carousels were one of the major UX use cases that prompted the creation of the CSS Scroll Snap Points spec. Unlike Stories, a carousel doesn't always need to stop on each image after a user interacts with it. It might be fine or encouraged to quickly cycle through the carousel. Stories, on the other hand, are best navigated one-by-one, and that's exactly what scroll-snap-stop provides.

.user {
  scroll-snap-align: start;
  scroll-snap-stop: always;
}

At the time of writing this post, scroll-snap-stop is only supported on Chromium-based browsers. Check out Browser compatibility for updates. It's not a blocker, though. It just means that on unsupported browsers users can accidentally skip a friend. So users will just have to be more careful, or we'll need to write JavaScript to ensure that a skipped friend isn't marked as viewed.

Read more in the spec if you're interested.

`overscroll-behavior` #

Have you ever been scrolling through a modal when all of a sudden you start scrolling the content behind the modal? overscroll-behavior lets the developer trap that scroll and never let it leave. It's nice for all sorts of occasions. My Stories component uses it to prevent additional swipes and scrolling gestures from leaving the component.

.stories {
  overflow-x: auto;
  overscroll-behavior: contain;
}

Safari and Opera were the 2 browsers that didn't support this, and that's totally OK. Those users will get an overscroll experience like they're used to and may never notice this enhancement. I'm personally a big fan and like including it as part of nearly every overscroll feature I implement. It's a harmless addition that can only lead to improved UX.

`scrollIntoView({behavior: 'smooth'})` #

When a user taps or clicks and has reached the end of a friend's set of stories, it's time to move to the next friend in the scroll snap point set. With JavaScript, we were able to reference the next friend and request for it to be scrolled into view. The support for the basics of this are great; every browser scrolled it into view. But, not every browser did it 'smooth'. This just means it's scrolled into view instead of snapped.

element.scrollIntoView({
  behavior: 'smooth'
})

Safari was the only browser not to support behavior: 'smooth' here. Check out Browser compatibility for updates.

Hands-on #

Now that you know how I did it, how would you?! Let's diversify our approaches and learn all the ways to build on the web. Create a Glitch, tweet me your version, and I'll add it to the Community remixes section below.

Community remixes #

Codelab: Building a Stories component

2020-11-25T00:00:00Z

This codelab teaches you how to build an experience like Instagram Stories on the web. We'll build the component as we go, starting with HTML, then CSS, then JavaScript.

Check out my blog post Building a Stories component to learn about the progressive enhancements made while building this component.

Setup #

Click Remix to Edit to make the project editable.
Open app/index.html.

HTML #

I always aim to use semantic HTML. Since each friend can have any number of stories, I thought it was meaningful to use a <section> element for each friend and an <article> element for each story. Let's start from the beginning though. First, we need a container for our stories component.

Add a <div> element to your <body>:

<div class="stories">

</div>

Add some <section> elements to represent friends:

<div class="stories">
  <section class="user"></section>
  <section class="user"></section>
  <section class="user"></section>
  <section class="user"></section>
</div>

Add some <article> elements to represent stories:

<div class="stories">
  <section class="user">
    <article class="story" style="--bg: url(https://picsum.photos/480/840);"></article>
    <article class="story" style="--bg: url(https://picsum.photos/480/841);"></article>
  </section>
  <section class="user">
    <article class="story" style="--bg: url(https://picsum.photos/481/840);"></article>
  </section>
  <section class="user">
    <article class="story" style="--bg: url(https://picsum.photos/481/841);"></article>
  </section>
  <section class="user">
    <article class="story" style="--bg: url(https://picsum.photos/482/840);"></article>
    <article class="story" style="--bg: url(https://picsum.photos/482/843);"></article>
    <article class="story" style="--bg: url(https://picsum.photos/482/844);"></article>
  </section>
</div>

We're using an image service (picsum.com) to help prototype stories.
The style attribute on each <article> is part of a placeholder loading technique, which you'll learn more about in the next section.

CSS #

Our content is ready for style. Let's turn those bones into something folks will want to interact with. We'll be working mobile-first today.

`.stories` #

For our <div class="stories"> container we want a horizontal scrolling container. We can achieve this by:

Making the container a Grid
Setting each child to fill the row track
Making the width of each child the width of a mobile device viewport

Grid will continue placing new 100vw-wide columns to the right of the previous one, until it's placed all the HTML elements in your markup.

Chrome DevTools showing grid column overflow, making a horizontal scroller.

Add the following CSS to the bottom of app/css/index.css:

.stories {
  display: grid;
  grid: 1fr / auto-flow 100%;
  gap: 1ch;
}

Now that we have content extending beyond the viewport, it's time to tell that container how to handle it. Add the highlighted lines of code to your .stories ruleset:

.stories {
  display: grid;
  grid: 1fr / auto-flow 100%;
  gap: 1ch;
  overflow-x: auto;
  scroll-snap-type: x mandatory;
  overscroll-behavior: contain;
  touch-action: pan-x;
}

We want horizontal scrolling, so we'll set overflow-x to auto. When the user scrolls we want the component to gently rest on the next story, so we'll use scroll-snap-type: x mandatory. Read more about this CSS in the CSS Scroll Snap Points and overscroll-behavior sections of my blog post.

It takes both the parent container and the children to agree to scroll snapping, so let's handle that now. Add the following code to the bottom of app/css/index.css:

.user {
  scroll-snap-align: start;
  scroll-snap-stop: always;
}

Your app doesn't work yet, but the video below shows what happens when scroll-snap-type is enabled and disabled. When enabled, each horizontal scroll snaps to the next story. When disabled, the browser uses its default scrolling behavior.

That will get you scrolling through your friends, but we still have an issue with the stories to solve.

`.user` #

Let's create a layout in the .user section that wrangles those child story elements into place. We're going to use a handy stacking trick to solve this. We're essentially creating a 1x1 grid where the row and column have the same Grid alias of [story], and each story grid item is going to try and claim that space, resulting in a stack.

Add the highlighted code to your .user ruleset:

.user {
  scroll-snap-align: start;
  scroll-snap-stop: always;
  display: grid;
  grid: [story] 1fr / [story] 1fr;
}

Add the following ruleset to the bottom of app/css/index.css:

.story {
  grid-area: story;
}

Now, without absolute positioning, floats, or other layout directives that take an element out of flow, we're still in flow. Plus, it's like barely any code, look at that! This gets broken down in the video and the blog post in more detail.

`.story` #

Now we just need to style the story item itself.

Earlier we mentioned that the style attribute on each <article> element is part of a placeholder loading technique:

<article class="story" style="--bg: url(https://picsum.photos/480/840);"></article>

We're going to use CSS's background-image property, which allows us to specify more than one background image. We can put them in an order so that our user picture is on top and will show up automatically when it's done loading. To enable this, we'll put our image URL into a custom property (--bg), and use it within our CSS to layer with the loading placeholder.

First, let's update the .story ruleset to replace a gradient with a background image once it's done loading. Add the highlighted code to your .story ruleset:

.story {
  grid-area: story;

  background-size: cover;
  background-image:
    var(--bg),
    linear-gradient(to top, lch(98 0 0), lch(90 0 0));
}

Setting background-size to cover ensures there's no empty space in the viewport because our image will be filling it up. Defining 2 background images enables us to pull a neat CSS web trick called the loading tombstone:

Background image 1 (var(--bg)) is the URL we passed inline in the HTML
Background image 2 (linear-gradient(to top, lch(98 0 0), lch(90 0 0)) is a gradient to show while the URL is loading

CSS will automatically replace the gradient with the image, once the image is done downloading.

Next we'll add some CSS to remove some behavior, freeing up the browser to move faster. Add the highlighted code to your .story ruleset:

.story {
  grid-area: story;

  background-size: cover;
  background-image:
    var(--bg),
    linear-gradient(to top, lch(98 0 0), lch(90 0 0));

  user-select: none;
  touch-action: manipulation;
}

user-select: none prevents users from accidentally selecting text
touch-action: manipulation instructs the browser that these interactions should be treated as touch events, which frees up the browser from trying to decide whether you're clicking a URL or not

Last, let's add a little CSS to animate the transition between stories. Add the highlighted code to your .story ruleset:

.story {
  grid-area: story;

  background-size: cover;
  background-image:
    var(--bg),
    linear-gradient(to top, lch(98 0 0), lch(90 0 0));

  user-select: none;
  touch-action: manipulation;

  transition: opacity .3s cubic-bezier(0.4, 0.0, 1, 1);

  &.seen {
    opacity: 0;
    pointer-events: none;
  }
}

The .seen class will be added to a story that needs an exit. I got the custom easing function (cubic-bezier(0.4, 0.0, 1,1)) from Material Design's Easing guide (scroll to the Accerlerated easing section).

If you've got a keen eye you probably noticed the pointer-events: none declaration and are scratching your head right now. I'd say this is the only downside of the solution so far. We need this because a .seen.story element will be on top and will receive taps, even though it's invisible. By setting the pointer-events to none, we turn the glass story into a window, and steal no more user interactions. Not too bad of a trade off, not too hard to manage here in our CSS right now. We're not juggling z-index. I'm feeling good about this still.

JavaScript #

The interactions of a Stories component are quite simple to the user: tap on the right to go forward, tap on the left to go back. Simple things for users tends to be hard work for developers. We'll take care of lots of it, though.

Setup #

To start out, let's compute and store as much information as we can. Add the following code to app/js/index.js:

const stories = document.querySelector('.stories')
const median = stories.offsetLeft + (stories.clientWidth / 2)

Our first line of JavaScript grabs and stores a reference to our primary HTML element root. The next line calculates where the middle of our element is, so we can decide if a tap is to go forward or backward.

State #

Next we make a small object with some state relevant to our logic. In this case, we're only interested in the current story. In our HTML markup, we can access it by grabbing the 1st friend and their most recent story. Add the highlighted code to your app/js/index.js:

const stories = document.querySelector('.stories')
const median = stories.offsetLeft + (stories.clientWidth / 2)

const state = {
  current_story: stories.firstElementChild.lastElementChild
}

Listeners #

We have enough logic now to start listening for user events and directing them.

Mouse #

Let's start by listening to the 'click' event on our stories container. Add the highlighted code to app/js/index.js:

const stories = document.querySelector('.stories')
const median = stories.offsetLeft + (stories.clientWidth / 2)

const state = {
  current_story: stories.firstElementChild.lastElementChild
}

stories.addEventListener('click', e => {
  if (e.target.nodeName !== 'ARTICLE')
    return

  navigateStories(
    e.clientX > median
      ? 'next'
      : 'prev')
})

If a click happens and it's not on a <article> element we bail and do nothing. If it is an article, we grab the horizontal position of the mouse or finger with clientX. We haven't implemented navigateStories yet, but the argument that it takes specifies what direction we need to go. If that user position is greater than the median, we know we need to navigate to next, otherwise prev (previous).

Keyboard #

Now, let's listen for keyboard presses. If the Down Arrow is pressed we navigate to next. If it's the Up Arrow, we go to prev.

Add the highlighted code to app/js/index.js:

const stories = document.querySelector('.stories')
const median = stories.offsetLeft + (stories.clientWidth / 2)

const state = {
  current_story: stories.firstElementChild.lastElementChild
}

stories.addEventListener('click', e => {
  if (e.target.nodeName !== 'ARTICLE')
    return

  navigateStories(
    e.clientX > median
      ? 'next'
      : 'prev')
})

document.addEventListener('keydown', ({key}) => {
  if (key !== 'ArrowDown' || key !== 'ArrowUp')
    navigateStories(
      key === 'ArrowDown'
        ? 'next'
        : 'prev')
})

Time to tackle the unique business logic of stories and the UX they've become famous for. This looks chunky and tricky, but I think if you take it line by line, you'll find it's quite digestible.

Upfront, we stash some selectors that help us decide whether to scroll to a friend or show/hide a story. Since the HTML is where we're working, we'll be querying it for presence of friends (users) or stories (story).

These variables will help us answer questions like, "given story x, does "next" mean move to another story from this same friend or to a different friend?" I did it by using the tree structure we built, reaching into parents and their children.

Add the following code to the bottom of app/js/index.js:

const navigateStories = direction => {
  const story = state.current_story
  const lastItemInUserStory = story.parentNode.firstElementChild
  const firstItemInUserStory = story.parentNode.lastElementChild
  const hasNextUserStory = story.parentElement.nextElementSibling
  const hasPrevUserStory = story.parentElement.previousElementSibling
}

Here's our business logic goal, as close to natural language as possible:

Decide how to handle the tap
- If there's a next/previous story: show that story
- If it's the last/first story of the friend: show a new friend
- If there's no story to go to in that direction: do nothing
Stash the new current story into state

Add the highlighted code to your navigateStories function:

const navigateStories = direction => {
  const story = state.current_story
  const lastItemInUserStory = story.parentNode.firstElementChild
  const firstItemInUserStory = story.parentNode.lastElementChild
  const hasNextUserStory = story.parentElement.nextElementSibling
  const hasPrevUserStory = story.parentElement.previousElementSibling

  if (direction === 'next') {
    if (lastItemInUserStory === story && !hasNextUserStory)
      return
    else if (lastItemInUserStory === story && hasNextUserStory) {
      state.current_story = story.parentElement.nextElementSibling.lastElementChild
      story.parentElement.nextElementSibling.scrollIntoView({
        behavior: 'smooth'
      })
    }
    else {
      story.classList.add('seen')
      state.current_story = story.previousElementSibling
    }
  }
  else if(direction === 'prev') {
    if (firstItemInUserStory === story && !hasPrevUserStory)
      return
    else if (firstItemInUserStory === story && hasPrevUserStory) {
      state.current_story = story.parentElement.previousElementSibling.firstElementChild
      story.parentElement.previousElementSibling.scrollIntoView({
        behavior: 'smooth'
      })
    }
    else {
      story.nextElementSibling.classList.remove('seen')
      state.current_story = story.nextElementSibling
    }
  }
}

Try it out #

To preview the site, press View App. Then press Fullscreen .

Conclusion #

That's a wrap up for the needs I had with the component. Feel free to build upon it, drive it with data, and in general make it yours!

Logical layout enhancements with flow-relative shorthands

2020-10-13T00:00:00Z

Since Chromium 69 (September 3rd 2018), logical properties and values have helped developers maintain control of their international layouts through logical, rather than physical, direction and dimension styles. In Chromium 87, shorthands and offsets have shipped to make these logical properties and values a bit easier to write. This catches Chromium up to Firefox, which has had support for the shorthands since 66. Safari has them ready in their tech preview.

Document flow #

If you're already familiar with logical properties, inline and block axes, and don't want a refresher, you can skip ahead. Otherwise, here's a short refresher.

In English, letters and words flow left to right while paragraphs are stacked top to bottom. In traditional Chinese, letters and words are top to bottom while paragraphs are stacked right to left. In just these 2 cases, if we write CSS that puts "margin top" on a paragraph, we're only appropriately spacing 1 language style. If the page is translated into traditional Chinese from English, the margin may well not make sense in the new vertical writing mode.

Therefore the physical side of the box isn't very useful internationally. Thus begins the process of supporting multiple languages; learning about physical versus logical sides of the box model.

Have you ever inspected the p element in Chrome DevTools? If so, you might have noticed that the default User Agent styles are not physical, but logical.

p {
  margin-block-start: 1em;
  margin-block-end: 1em;
  margin-inline-start: 0px;
  margin-inline-end: 0px;
}

CSS from Chromium's User Agent Stylesheet

The margin is not on the top or bottom like an English reader might believe. It's block-start and block-end! These logical properties are akin to an English reader's top and bottom, but also akin to a Japanese reader as right and left. Written once, works everywhere.

Normal flow is when the webpage is part of this multi-directionality intentionally. When page content updates according to document direction changes, the layout and its elements are considered in flow. Read more about "in" and "out" of flow on MDN or in the CSS Display Module spec. While logical properties are not required to be in flow, they do much of the heavy lifting for you as directionality changes. Flow implies direction, which letters, words and content need to travel along. This leads us to block and inline logical directions.

Block direction is the direction that new content blocks follow, like asking yourself, "where to put the next paragraph?". You might think of it as a "content block", or "block of text". Every language arranges their blocks and orders them along their respective block-axis. block-start is the side a paragraph is first placed, while block-end is the side new paragraphs flow towards.

In traditional Japanese handwriting, for example, block direction flows right to left:

Inline direction is the direction that letters and words go. Consider the direction your arm and hand travel when you write; they are traveling along the inline-axis. inline-start is the side where you start writing, while inline-end is the side where writing ends or wraps. The above video, the inline-axis is top to bottom, but in this next video the inline-axis flows right to left.

Being flow-relative means that the styles written for one language will be contextual and appropriately applied into other languages. Content will flow relative to the language it's being delivered for.

New shorthands #

Some of the following shorthands are not new features for the browser, rather, easier ways to write styles by taking advantage of being able to set values on both block or inline edges at once. The inset-* logical properties do bring new abilities, as there were no longhand ways to specify absolute positions with logical properties before it. Insets and shorthands flow (hehe) together so well though, I'm going to tell you about all of the new logical properties features landing in Chromium 87 at once.

Margin shorthands #

No new abilities shipped, but some super handy shorthands did:
margin-block and margin-inline.

Longhand

margin-block-start: 2ch;
margin-block-end: 2ch;

New shorthand

margin-block: 2ch;
/* or */
margin-block: 2ch 2ch;

There is no shorthand for "top and bottom" or "left and right"… until now! You probably reference all 4 sides using the shorthand of margin: 10px;, and now you can easily reference 2 complimentary sides by using the logical property shorthand.

Longhand

margin-inline-start: 4ch;
margin-inline-end: 2ch;

New shorthand

margin-inline: 4ch 2ch;

Padding shorthands #

No new abilities shipped, but more super handy shorthands did:
padding-block and padding-inline.

Longhand

padding-block-start: 2ch;
padding-block-end: 2ch;

New shorthand

padding-block: 2ch;
/* or */
padding-block: 2ch 2ch;

And the inline complimentary set of shorthands:

Longhand

padding-inline-start: 4ch;
padding-inline-end: 2ch;

New shorthand

padding-inline: 4ch 2ch;

Inset and shorthands #

The physical properties top, right, bottom and left can all be written as values for the inset property. Any value of position can benefit from setting sides with inset.

.cover {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  inset: 0;
}

Physical longhand

position: absolute;
top: 1px;
right: 2px;
bottom: 3px;
left: 4px;

New physical shorthand

position: absolute;
inset: 1px 2px 3px 4px;

That should look immediately convenient! Inset is shorthand for the physical sides, and it works just like margin and padding.

New features #

As exciting as the physical sides shorthand is, there's even more from the logical features brought by additional inset shorthands. These shorthands bring developer authoring convenience (they're shorter to type) but also increase the potential reach for the layout because they're flow-relative.

Physical longhand

position: absolute;
top: 10px;
bottom: 10px;

Logical shorthand

position: absolute;
inset-block: 10px;

Physical longhand

position: absolute;
left: 10px;
right: 20px;

Logical shorthand

position: absolute;
inset-inline: 10px 20px;

Further reading and a full list of inset shorthand and longhand is available on MDN.

Border shorthands #

Border, plus its nested color, style, and width properties have all got new logical shorthands as well.

Physical longhand

border-top-color: hotpink;
border-bottom-color: hotpink;

Logical shorthand

border-block-color: hotpink;
/* or */
border-block-color: hotpink hotpink;

Physical longhand

border-left-style: dashed;
border-right-style: dashed;

Logical shorthand

border-inline-style: dashed;
/* or */
border-inline-style: dashed dashed;

Physical longhand

border-left-width: 1px;
border-right-width: 1px;

Logical shorthand

border-inline-width: 1px;
/* or */
border-inline-width: 1px 1px;

Further reading and a full list of border shorthand and longhand is available on MDN.

Logical property `<figure>` example #

Let's put it all together in a small example. Logical properties can layout an image with a caption to handle different writing and document directions.

Or try it!

You don't have to do much to make a card internationally responsive with a <figure> and a few logical properties. If you're curious how all this internationally considerate CSS works together, I hope this is a small meaningful introduction.

Polyfilling and cross-browser support #

The Cascade or build tools are viable options to have old and new browsers alike, properly spaced with updated logical properties. For Cascade fallbacks, follow a physical property with a logical one and the browser will use the "last" property it found during style resolution.

p {
  /* for unsupporting browsers */
  margin-top: 1ch;
  margin-bottom: 2ch;

  /* for supporting browsers to use */
  /* and unsupporting browsers to ignore and go 🤷‍♂️ */
  margin-block: 1ch 2ch;
}

That's not quite a full solution for everyone though. Here's a handwritten fallback that leverages the :lang() pseudo-selector to target specific languages, adjusts their physical spacing appropriately, then at the end offers the logical spacing for supporting browsers:

/* physical side styles */
p {
  margin-top: 1ch;
  margin-bottom: 2ch;
}

/* adjusted physical side styles per language */
:lang(ja) {
  p {
    /* zero out styles not useful for traditional Japanese */
    margin-top: 0;
    margin-bottom: 0;

    /* add appropriate styles for traditional Japanese */
    margin-right: 1ch;
    margin-left: 2ch;
  }
}

/* add selectors and adjust for languages all supported */
:lang(he) {…}
:lang(mn) {…}

/* Logical Sides */
/* Then, for supporting browsers to use */
/* and unsupporting browsers to ignore #TheCascade */
p {
  /* remove any potential physical cruft.. */
  margin: 0;
  /* explicitly set logical value */
  margin-block: 1ch 2ch;
}

You could also use @supports to determine whether or not to provide physical property fallbacks:

p {
  margin-top: 1ch;
  margin-bottom: 2ch;
}

@supports (margin-block: 0) {
  p {
    margin-block: 1ch 2ch;
  }
}

Sass, PostCSS, Emotion and others have automated bundler and/or build time offerings that have a wide array of fallbacks or solutions. Check out each one to see which matches your toolchain and overall site strategy.

What's next #

More of CSS will offer logical properties, it's not done yet! There's one big missing set of shorthands though, and a resolution is still pending in this GitHub issue. There is a temporary solution in a draft. What if you want to style all logical sides of a box with a shorthand?

Physical shorthand

margin: 1px 2px 3px 4px;
margin: 1px 2px;
margin: 2px;

Logical shorthand

margin: logical 1px 2px 3px 4px;
margin: logical 1px 2px;
margin: logical 2px;

The current draft proposal would mean you have to write logical in every shorthand in order to get the logical equivalent applied, which doesn't sound very DRY to some.

There are other proposals to change it at the block or page level, but that could leak logical uses into styles still assuming physical sides.

html {
  flow-mode: physical;
  /* or */
  flow-mode: logical;
  /* now all margin/padding/etc references are logical */
}

/* hopefully no 3rd/1st party code is hard coded to top/left/etc ..? */

It's a tough one! Cast your vote, voice your opinion, we want to hear from you.

Want to learn or study logical properties more? Here's a detailed reference, along with guides and examples, on MDN 🤓

Feedback #

To propose changes to the CSS syntax of flow-relative shorthands, first check the existing issues on the csswg-drafts repository. If none of the existing issues match your proposal, create a new issue.
To report bugs on Chromium's implementation of flow-relative shorthands, first check the existing issues on Chromium Bug Tracker. If none of the existing issues match your bug, create a new issue.

Custom bullets with CSS ::marker

2020-09-02T00:00:00Z

Thanks to Igalia, sponsored by Bloomberg, we can finally put our hacks away for styling lists. See!

View Source

Thanks to CSS ::marker we can change the content and some of the styles of bullets and numbers.

Browser compatibility #

::marker is supported in Firefox for desktop and Android, desktop Safari and iOS Safari (but only the color and font-* properties, see Bug 204163), and Chromium-based desktop and Android browsers.

Browser support

Chrome 86, Supported 86
Firefox 68, Supported 68
Edge 86, Supported 86
Safari 11.1, Supported 11.1

Source

Pseudo-elements #

Consider the following essential HTML unordered list:

<ul>
  <li>Lorem ipsum dolor sit amet consectetur adipisicing elit</li>
  <li>Dolores quaerat illo totam porro</li>
  <li>Quidem aliquid perferendis voluptates</li>
  <li>Ipsa adipisci fugit assumenda dicta voluptates nihil reprehenderit consequatur alias facilis rem</li>
  <li>Fuga</li>
</ul>

Which results in the following unsurprising rendering:

The dot at the beginning of each <li> item is free! The browser is drawing and creating a generated marker box for you.

Today we're excited to talk about the ::marker pseudo-element, which gives the ability to style the bullet element that browsers create for you.

Creating a marker #

The ::marker pseudo-element marker box is automatically generated inside every list item element, preceding the actual contents and the ::before pseudo-element.

li::before {
  content: "::before";
  background: lightgray;
  border-radius: 1ch;
  padding-inline: 1ch;
  margin-inline-end: 1ch;
}

Typically, list items are <li> HTML elements, but other elements can also become list items with display: list-item.

<dl>
  <dt>Lorem</dt>
  <dd>Lorem ipsum dolor sit amet consectetur adipisicing elit</dd>
  <dd>Dolores quaerat illo totam porro</dd>

  <dt>Ipsum</dt>
  <dd>Quidem aliquid perferendis voluptates</dd>
</dl>

dd {
  display: list-item;
  list-style-type: "🤯";
  padding-inline-start: 1ch;
}

Styling a marker #

Until ::marker, lists could be styled using list-style-type and list-style-image to change the list item symbol with 1 line of CSS:

li {
  list-style-image: url(/right-arrow.svg);
  /* OR */
  list-style-type: '👉';
  padding-inline-start: 1ch;
}

That's handy but we need more. What about changing the color, size, spacing, etc!? That's where ::marker comes to the rescue. It allows individual and global targeting of these pseudo-elements from CSS:

li::marker {
  color: hotpink;
}

li:first-child::marker {
  font-size: 5rem;
}

The list-style-type property gives very limited styling possibilities. The ::marker pseudo-element means that you can target the marker itself and apply styles directly to it. This allows for far more control.

That said, you can't use every CSS property on a ::marker. The list of which properties are allowed and not allowed are clearly indicated in the spec. If you try something interesting with this pseudo-element and it doesn't work, the list below is your guide into what can and can't be done with CSS:

Allowed CSS `::marker` Properties #

animation-*
transition-*
color
direction
font-*
content
unicode-bidi
white-space

Changing the contents of a ::marker is done with content as opposed to list-style-type. In this next example the first item is styled using list-style-type and the second with ::marker. The properties in the first case apply to the entire list item, not just the marker, which means that the text is animating as well as the marker. When using ::marker we can target just the marker box and not the text.

Also, note how the disallowed background property has no effect.

List Styles

li:nth-child(1) {
  list-style-type: '?';
  font-size: 2rem;
  background: hsl(200 20% 88%);
  animation: color-change 3s ease-in-out infinite;
}

Mixed results between the marker and the list item

Marker Styles

li:nth-child(2)::marker {
  content: '!';
  font-size: 2rem;
  background: hsl(200 20% 88%);
  animation: color-change 3s ease-in-out infinite;
}

Focused results between marker and list item

Changing the content of a marker #

Here are some of the ways you could style your markers.

Changing all list items

li {
  list-style-type: "😍";
}

/* OR */

li::marker {
  content: "😍";
}

Changing just one list item

li:last-child::marker {
  content: "😍";
}

Changing a list item to SVG

li::marker {
  content: url(/heart.svg);
  content: url(#heart);
  content: url("data:image/svg+xml;charset=UTF-8,<svg xmlns='http://www.w3.org/2000/svg' version='1.1' height='24' width='24'><path d='M12 21.35l-1.45-1.32C5.4 15.36 2 12.28 2 8.5 2 5.42 4.42 3 7.5 3c1.74 0 3.41.81 4.5 2.09C13.09 3.81 14.76 3 16.5 3 19.58 3 22 5.42 22 8.5c0 3.78-3.4 6.86-8.55 11.54L12 21.35z' fill='none' stroke='hotpink' stroke-width='3'/></svg>");
}

Changing numbered lists What about an <ol> though? The marker on an ordered list item is a number and not a bullet by default. In CSS these are called Counters, and they're quite powerful. They even have properties to set and reset where the number starts and ends, or switching them to roman numerals. Can we style that? Yep, and we can even use the marker content value to build our own numbering presentation.

li::marker {
  content: counter(list-item) "› ";
  color: hotpink;
}

Debugging #

Chrome DevTools is ready to help you inspect, debug and modify the styles applying to ::marker pseudo elements.

Future Pseudo-element styling #

You can find out more about ::marker from:

CSS Lists, Markers and Counters from Smashing Magazine
Counting With CSS Counters and CSS Grid from CSS-Tricks
Using CSS Counters from MDN

It's great to get access to something which has been hard to style. You might wish that you could style other automatically generated elements. You might be frustrated with <details> or the search input autocomplete indicator, things that are not implemented in the same way across browsers. One way to share what you need is by creating a want at https://webwewant.fyi.

More variable font options for the macOS `system-ui` font in Chromium 83

2020-05-21T00:00:00Z

The 'system-ui' section of the CSS Fonts Module Level 4 spec defines a system-ui font keyword that allows developers to use the built-in, turbo-optimized, localized, mega-high-quality, no-download-needed, default operating system font right in their sites and apps.

body {
  font-family: system-ui;
}

This typography choice is akin to saying "use the default system font for the current locale of this user."

On macOS, the system-ui font is San Francisco, a font that a design team vetted, tested, and… recently upgraded! First we'll cover the new exciting variable font features in Catalina, then we'll cover a couple of bugs and how Chromium engineers resolved them.

This post assumes that you're already familiar with variable fonts. If not, check out Introduction to variable fonts on the web and the video below.

Browser compatibility #

At the time of writing, system-ui has support from Chromium (since 56), Edge (since 79), Safari (since 11), and from Firefox (since 43) but with the -apple-system keyword. See Can I use variable fonts? for updates.

New powers #

The new abilities that Catalina brought to the system font are now available to web developers as of Chromium 83. The system-ui font now has more variable settings: optical sizing and 2 unique weight adjustments:

Mojave

h1 {
  font-family: system-ui;
  font-weight: 700;
  font-variation-settings:
    'wght' 750
  ;
}

Catalina

h1 {
  font-family: system-ui;
  font-weight: 700;
  font-variation-settings:
    'wght' 750,
    'opsz' 20,
    'GRAD' 400,
    'YAXS' 400
  ;
}

On Mojave, system-ui is a variable font with only wght settings. While system-ui on Catalina is a variable font with wght, opsz, GRAD, and YAXS settings.

Looks like some neat progressive enhancement design opportunities to me! Really dig into the subtleties of the system font if you want.

`wght` #

Accepts a font weight between 0 and 900 and is applied equally to all characters.

/* 0-900 */
font-variation-settings: 'wght' 750;

`opsz` #

Optical sizing is similar to kerning or letter-spacing, but the spacing is done by a human eye instead of math. A value of 19 or below is intended for text and body copy spacing, while 20 or above is for spacing display headers and titles.

/* 19 or 20 */
font-variation-settings: 'opsz' 20;

`GRAD` #

Similar to weight, but without touching horizontal spacing. It accepts values between 400 and 1000.

/* 400-1000 */
font-variation-settings: 'GRAD' 500;

`YAXS` #

Stretches the glyph vertically. It accepts values between 400 and 1000.

/* 400-1000 */
font-variation-settings: 'YAXS' 500;

Combining the options #

With a few lines of CSS, we can tweak the font settings into a bold of our choice or try out other interesting combinations:

font-weight: 700;
font-weight: bold;
font-variation-settings: 'wght' 750, 'YAXS' 600, 'GRAD' 500, 'opsz' 20;

And just like that, Chromium users on macOS see your upgraded, custom 750 weight with some fun other tweaks 👍

Playground #

Click Remix to Edit in the Glitch below to get an editable copy of the Glitch, and then edit the new font-variation-settings options to see how it affects your font. Remember that this Glitch will only work if you're using a macOS Catalina device.

macOS 10.15 added new features to its system font, and in macOS 10.15 a tricky system-ui bug was logged in the Chromium bug tracker. I wonder if they are related!?

Appendix: The `system-ui` regression #

This story starts with a different bug: #1005969. This was reported against macOS 10.15 because the system-ui font spacing looked narrow and crammed.

Chrome on left (tighter tracking), Safari on right (better optical spacing)

Background #

Did you ever notice on macOS 10.14 how your paragraphs or headers "snapped" to a different looking font when the size went up or down?

On Mojave (macOS 10.14), the system-ui font switched between two fonts depending on the target font size. When text was under 20px, macOS used "San Francisco Text". When text was 20px or over, macOS used "San Francisco Display". Optical sizing was built statically into two separate fonts.

Catalina (macOS 10.15) shipped a new united variable font for San Francisco. No more managing "Text" and "Display". It also gained the new variation setting opsz described earlier.

h1 {
  font-variation-settings: 'opsz' 20;
}

Unfortunately, the default opsz value in the new Catalina font is 20, and Chromium engineers were not prepared to apply opsz to the system font. This led to smaller sizes displaying too narrow.

To fix that, Chromium needed to apply opsz correctly to the system font. This led to Issue #1005969 getting fixed. Victory! Or was it…?

Not done yet #

This is where it got tricky: Chromium applied opsz but something did not look right still. System fonts on Mac have an additional font table called trak, which tweaks horizontal spacing. While working on the fix, Chromium engineers noticed that on macOS, when retrieving horizontal metrics from a CTFontRef object, the trak metrics were already getting factored into the metrics results. Chromium's shaping library HarfBuzz needs metrics where the trak values are not yet factored in.

Left: Bold weights applied to font sizes 19 and below. Right: Font sizes 20 and up lose bold styling

Internally, Skia (the graphics library, not the typeface of the same name) uses both the CGFontRef class from CoreGraphics and the CTFontRef class from CoreText. Due to required internal conversions between those objects (used for keeping backwards compatibility and accessing needed APIs on both classes), Skia would lose weight information in certain circumstances and bold fonts would stop working. This was tracked in Issue #1057654.

Skia still needs to support macOS 10.11 because Chromium still supports it. On 10.11 the "San Francisco Text" and "San Francisco Display" fonts weren't even variable fonts. Rather, each was a family of separate fonts for every weight available. At some point their glyph IDs became out of sync with each other. So if Skia did text shaping (converting text into glyphs that can be drawn) with "San Francisco Text", it would be gibberish if drawn with "San Francisco Display", and vice versa. And even if Skia just asked for a different size macOS might switch to the other. It should be possible to always use one of the fonts and just scale it (using a matrix to scale it up instead of asking for a larger size) but CoreText has an issue where it will not scale sbix (color emoji) glyphs up (only down). It's a bit more complex than that. CoreText actually seems to cap the vertical extent after matrix application, which seems to be related to it not being able to draw emoji at 45 degree angles. In any event, if you want your emoji to be shown big, you need to make a copy of the font to get a big version.

So in order to create copies of CTFont objects at different sizes internally while ensuring that the same underlying font data is used, Chromium pulled the CGFont off the CTFont, then made a new CTFont from the CGFont (CGFont objects are size independent, the magic switching happens at the CoreText level). This worked fine until 10.154. In 10.15 this round trip ended up losing too much information, resulting in the weight issue. Flutter noticed the weight issue and an alternate fix for resizing was made to create the new CTFont directly from the original CTFont while controlling the optical size directly using an old but undocumented attribute in CoreText. This keeps things working on 10.11 and fixes other issues (like explicitly setting the optical size to the default value).

However, this preserves more of the CoreText 'magic' in the font. One of these seems to be that it still tweaks the glyph advances in some way other than just the trak table (the application of which Chromium was already trying to suppress through yet another undocumented attribute).

CGFont doesn't do any of this 'magic' so maybe Chromium could get the CGFont off the CTFont and just use it to get advances? Unfortunately this wouldn't work because CoreText is known to muck with fonts in other ways as well. For example, it makes small emoji slightly bigger than you actually requested (boosting their size a bit). CGFont doesn't know about this, so you'd end up with your sbix-based emoji too close to each other since you'd be measuring at one size but CoreText would draw them bigger by some amount. Chromium does want the CTFont advances, but it wants them without tracking, and preferably without any other mucking about.

Since the fix for the spacing issue required a set of interconnected Blink and Skia fixes, the Chromium engineers could not "just revert" to fix the problem. The Chromium engineers also tried using a different build flag for changing a font-related codepath in Skia, which fixed the bold fonts problem, but regressed the spacing problem.

The fix #

In the end, of course Chromium wanted to fix both things. Chromium now resorts to using HarfBuzz built-in font OpenType font metrics functions for retrieving horizontal metrics directly from the binary data in the system font's font tables. Using this, Chromium is sidestepping CoreText and Skia when the font has a trak table (except when it's the emoji font).

In the meantime there's still Skia Issue #10123 to track fixing this fully in Skia, and to go back to using Skia to retrieve the system font metrics from there, instead of the current fix that goes through HarfBuzz.

Chromium lands Flexbox `gap`

2020-05-07T00:00:00Z

CSS Gap #

gap is flow relative, meaning it changes dynamically based on the direction of content flow. For example, gap will automatically adjust for the different writing-mode or direction values that you set for your international users. This significantly eases the burden of spacing challenges for the component and CSS author. Less code scaling further.

Gap demonstrating localization support, as it handles changes to direction and writing-mode: Codepen | Tweet

Browser compatibility #

Browser support

Chrome 57, Supported 57
Firefox 52, Supported 52
Edge 16, Supported 16
Safari 10.1, Supported 10.1

Source

Usage #

gap accepts any CSS length or percentage as a value.

.gap-example {
  display: grid;
  gap: 10px;
  gap: 2ch;
  gap: 5%;
  gap: 1em;
  gap: 3vmax;
}

Gap can be passed 1 length, which will be used for both row and column.

Shorthand

.grid {
  display: grid;
  gap: 10px;
}

Set both rows and columns together at once

Expanded

.grid {
  display: grid;
  row-gap: 10px;
  column-gap: 10px;
}

Gap can be passed 2 lengths, which will be used for row and column.

Shorthand

.grid {
  display: grid;
  gap: 10px 5%;
}

Set both rows and columns separately at once

Expanded

.grid {
  display: grid;
  row-gap: 10px;
  column-gap: 5%;
}

Flexbox `gap` #

Before gap was in Flexbox, strategies involved negative margins, complex selectors, :last or :first type pseudo-class selectors, or other means to manage the space of a dynamically layed-out and wrapping set of children.

Previous Attempts #

The following are patterns that folks have used to get gap-like spacing.

pseudo-class selectors

.layout > :not(:last-child) {
  margin-bottom: 10px;
  margin-right: 10px;
}

lobotomized owl

.layout > * + * {
  margin-bottom: 10px;
  margin-right: 10px;
}

Source

The above are not a full replacement for gap though, and often need @media or :lang() adjustments to account for wrapping scenarios, writing modes or direction. Adding one or two media queries doesn't seem so bad, but they can add up and lead to complicated layout logic.

What the above author really intended was to have none of the child items touch.

The Antidote: gap #

.layout {
  display: flex;
  gap: 10px;
}

In the first 2 examples (without Flexbox gap), the children are targeted and assigned spacing from other elements. In the antidote gap example, the container owns the spacing. Each child can relieve itself of the burden, while also centralizing the spacing ownership. Simplifying consistency. Reorder, change viewports, remove elements, append new elements, etc. and spacing remains consistent. No new selectors, no new media queries, just space.

Chromium DevTools updates #

With these updates come changes to Chromium DevTools, notice how the Styles pane handles grid-gap and gap now 👍

Devtools shows the both grid-gap and gap, with gap shown used below grid-gap as to let the cascade use the latest syntax.

DevTools supports both grid-gap and gap, this is because gap is essentially an alias to the previous syntaxes.

New layout potential #

With Flexbox gap, we unlock more than convenience. We unlock powerful, perfectly spaced, intrinsic layouts. In the video and following code sample below, Grid cannot achieve the layout that Flexbox can. Grid must have equal rows and columns, even if they're intrinsically assigned.

Also, notice how dynamic the spacing between children is when they wrap intrinsically like that. Media queries can't detect wrapping like that to make intelligent adjustments. Flexbox gap can, and will, do it for you across all internationalizations.

Multi-column `gap` #

In addition to Flexbox supporting the gap syntax, multi-column layouts also support the shorter gap syntax.

article {
  column-width: 40ch;
  column-gap: 5ch;
  gap: 5ch;
}

Pretty rad.

Scroll snapping after layout changes

2020-02-22T00:00:00Z

CSS Scroll Snap allows web developers to create well-controlled scroll experiences by declaring scroll snapping positions. One shortcoming of the current implementation is that scroll snapping does not work well when the layout changes, such as when the viewport is resized or the device is rotated. This shortcoming is fixed in Chrome 81.

Interoperability #

Many browsers have basic support for CSS Scroll Snap. See Can I use CSS Scroll Snap? for more information.

Chrome is currently the only browser to implement scroll snapping after layout changes. Firefox has a ticket open for implementing this and Safari also has an open ticket for re-snapping after a scroller's content changes. For now, you can simulate this behaviour by adding the following code to event listeners to force a snapping to execute:

scroller.scrollBy(0,0);

However, this will not guarantee that the scroller snaps back to the same element.

Background #

CSS Scroll Snap #

The CSS Scroll Snap feature allows web developers to create well-controlled scroll experiences by declaring scroll snapping positions. These positions ensure that scrollable content is properly aligned with its container to overcome the issues of imprecise scrolling. In other words, scroll snapping:

Prevents awkward scroll positions when scrolling.
Creates the effect of paging through content.

Paginated articles and image carousels are two common use cases for scroll snaps.

Example of CSS scroll snap. At the end of scrolling an image's horizontal center is aligned with the horizontal center of the scroll container.

Shortcomings #

Snap positions get lost when resizing a window.

Scroll snapping allows users to effortlessly navigate through content, but its inability to adapt to changes in content and layout blocks some of its potential benefits. As shown in the example above, users have to re-adjust scroll positions whenever resizing a window to find the previously snapped element. Some common scenarios that cause layout change are:

Resizing a window
Rotating a device
Opening DevTools

The first two scenarios make CSS Scroll Snap less appealing for users and the third one is a nightmare for developers when debugging. Developers also need to consider these shortcomings when trying to make a dynamic experience that supports actions such as adding, removing, or moving content.

A common fix for this is to add listeners that execute a programmatic scroll via JavaScript to force snapping to execute whenever any of these mentioned layout changes happen. This workaround can be ineffective when the user expects the scroller to snap back to the same content as before. Any further handling with JavaScript seems to almost defeat the purpose of this CSS feature.

Built-in support for re-snapping after layout changes in Chrome 81 #

The mentioned shortcomings no longer exist in Chrome 81: scrollers will remain snapped even after changing layout. They will re-evaluate scroll positions after changing their layout, and re-snap to the closest snap position if necessary. If the scroller was previously snapped to an element that still exists after the layout change, then the scroller will try to snap back to it. Pay attention to what happens when the layout changes in the following example.

Snap position lost

Rotating a device does not preserve the snap positions in Chrome 80. After scrolling to the slide that says NOPE and changing the device orientation from portrait to landscape, a blank screen is shown, which indicates that the scroll snap position was lost.

Snap position preserved

Rotating a device does preserve the snap positions in Chrome 81. The slide that says NOPE remains in view even though the device orientation changes multiple times.

See the Re-snapping after layout changes specification for more details.

Example: Sticky scrollbars #

With "Snap after layout changes", developers can implement sticky scrollbars with a few lines of CSS:

.container {
  scroll-snap-type: y proximity;
}

.container::after {
  scroll-snap-align: end;
  display: block;
}

Want to learn more? See the following demo chat UI for visuals.

Adding a new message triggers re-snap which makes it stick to the bottom in Chrome 81.

Future work #

All re-snapping scroll effects are currently instant; a potential follow-up is to support re-snapping with smooth scrolling effects. See the specification issue for details.

Feedback #

Your feedback is invaluable in making re-snapping after layout changes better, so go on and try it out and let the Chromium engineers know what you think.

Next-generation web styling

2019-12-05T00:00:00Z

There are a ton of exciting things happening in CSS right now—and many of them are already supported in today's browsers! Our talk at CDS 2019, which you can watch below, covers several new and upcoming features we thought should get some attention.

This post focuses on the features you can use today, so be sure to watch the talk for a deeper discussion of upcoming features like Houdini. You can also find demos for all the features we discuss on our CSS@CDS page.

Contents #

Scroll Snap #

Scroll Snap lets you define snap points as the user scrolls your content vertically, horizontally, or both. It offers built-in scroll inertia and deceleration, and it's touch enabled.

This sample code sets up horizontal scrolling in a <section> element with snap points aligned to the left sides of child <picture> elements:

section {
  overflow-x: auto;
  overscroll-behavior-x: contain;
  scroll-snap-type: x mandatory;
}

section > picture {
  scroll-snap-align: start;
}

Here's how it works:

On the parent <section> element,
- overflow-x is set to auto to allow horizontal scrolling.
- overscroll-behavior-x is set to contain to prevent any parent elements from scrolling when the user reaches the boundaries of the <section> element's scroll area. (This isn't strictly necessary for snapping, but it's usually a good idea.)
- scroll-snap-type is set to x—for horizontal snapping—and mandatory—to ensure that the viewport always snaps to the closest snap point.
On the child <picture> elements, scroll-snap-align is set to start, which sets the snap points on the left side of each picture (assuming direction is set to ltr).

And here's a live demo:

See the Pen Awww Scroll Snap [horizontal] by Adam Argyle (@argyleink) on CodePen.

You can also take a look at demos for vertical scroll snap and matrix scroll snap.

`:focus-within` #

:focus-within addresses a long-standing accessibility issue: there are many cases when focusing a child element should affect the presentation of a parent element so that the UI is accessible to users of assistive technologies.

For example, if you have a dropdown menu with several items, the menu should remain visible while any of the items has focus. Otherwise, the menu disappears for keyboard users.

:focus-within tells the browser to apply a style when focus is on any child element of a specified element. Returning to the menu example, by setting :focus-within on the menu element, you can make sure it stays visible when a menu item has focus:

.menu:focus-within {
  display: block;
  opacity: 1;
  visibility: visible;
}

Try tabbing through the focusable elements in the demo below. You'll notice that the menus remain visible as you focus on the menu items:

See the Pen Simple CSS Dropdown Menu with Hover and :focus-within and Focus states by Una Kravets (@una) on CodePen.

Media Queries Level 5 #

New media queries give us powerful ways to adjust the user experience of our apps based on a user's device preferences. Basically, the browser serves as a proxy for system-level preferences that we can respond to in our CSS using the prefers-* group of media queries:

Here are the new queries we think developers will be most excited about:

These queries are a huge win for accessibility. Previously we had no way to know, for example, that a user had set their OS to high-contrast mode. If you wanted to provide a high-contrast mode for a web app that remained true to your brand, you had to ask users to choose it from UI within your app. Now you can detect the high-contrast setting from the OS using prefers-contrast.

One exciting implication of these media queries is that we can design for multiple combinations of system-level user preferences to accommodate the wide range of user preferences and accessibility needs. If a user wants high-contrast dark mode when in dimly lit environments, you can do that!

It's important to Adam that "prefers reduced motion" doesn't get implemented as "no motion." The user is saying they prefer less motion, not that they don't want any animation. He asserts reduced motion is not no motion. Here's an example that uses a crossfade animation when the user prefers reduced motion:

Logical properties #

Logical properties solve a problem that has gained visibility as more developers tackle internationalization. Many layout properties like margin and padding assume a language that is read top-to-bottom and left-to-right.

When designing pages for multiple languages with varying writing modes, developers have had to adjust all those properties individually across multiple elements, which quickly becomes a maintainability nightmare.

Logical properties let you maintain layout integrity across translations and writing modes. They dynamically update based on the semantic ordering of content rather than its spatial arrangement. With logical properties, each element has two dimensions:

The block dimension is perpendicular to the flow of text in a line. (In English, block-size is the same as height.)
The inline dimension is parallel to the flow of text in a line. (In English, inline-size is the same as width.)

These dimension names apply to all logical layout properties. So, for example, in English, block-start is the same as top, and inline-end is the same as right.

With logical properties, you can automatically update your layout for other languages by simply changing the writing-mode and direction properties for your page rather than updating dozens of layout properties on individual elements.

You can see how logical properties work in the demo below by setting the writing-mode property on the <body> element to different values:

See the Pen Logical Properties Demo by Una Kravets (@una) on CodePen.

`position: sticky` #

An element with position: sticky remains in block flow until it starts to go offscreen, at which point it stops scrolling with the rest of the page and sticks to the position specified by the element's top value. The space allocated for that element remains in the flow, and the element returns to it when the user scrolls back up.

Sticky positioning lets you create many useful effects that previously required JavaScript. To show some of the possibilities, we've created several demos. Each demo uses largely the same CSS and only slightly adjusts the HTML markup to create each effect.

Sticky Stack #

In this demo, all sticky elements share the same container. That means that each sticky element slides over the previous one as the user scrolls down. The sticky elements share the same stuck position.

Sticky Slide #

Here, the sticky elements are cousins. (That is, their parents are siblings.) When a sticky element hits the lower boundary of its container, it moves up with the container, creating the impression that lower sticky elements are pushing up higher ones. In other words, they appear to compete for the stuck position.

Sticky Desperado #

Like Sticky Slide, the sticky elements in this demo are cousins. However, they've been placed in containers set to a two-column grid layout.

`backdrop-filter` #

The backdrop-filter property lets you apply graphical effects to the area behind an element rather than to the element itself. This makes lots of cool effects that were previously only achievable using complicated CSS and JavaScript hacks doable with one line of CSS.

For example, this demo uses backdrop-filter to achieve OS-style blurring:

See the Pen mddjjor by Una Kravets (@una) on CodePen.

We already have a great post about backdrop-filter, so head there for more info.

`:is()` #

While the :is() pseudo-class is actually over ten years old, it still doesn't see as much use as we think it deserves. It takes a comma-separated list of selectors as its argument and matches any selectors in that list. That flexibility makes it incredibly handy and can significantly reduce the amount of CSS you ship.

Here's a quick example:

button.focus,
button:focus {
  …
}

article > h1,
article > h2,
article > h3,
article > h4,
article > h5,
article > h6 {
  …
}

/* selects the same elements as the code above */
button:is(.focus, :focus) {
  …
}

article > :is(h1,h2,h3,h4,h5,h6) {
  …
}

`gap` #

CSS grid layout has had gap (previously grid-gap) for some time. By specifying the internal spacing of a containing element rather than the spacing around child elements, gap solves many common layout issues. For example, with gap, you don't have to worry about margins on child elements causing unwanted whitespace around the edges of a containing element:

Even better news: gap is coming to flexbox, bringing all the same spacing perks that grid has:

There's one spacing declaration rather than many.
There's no need to establish conventions for your project about which child elements should own spacing—the containing element owns the spacing instead.
The code is more easily understandable than older strategies like the lobotomized owl.

The following video shows the benefits of using a single gap property for two elements, one with a grid layout and one with a flex layout:

Right now, only FireFox supports gap in flex layouts, but play around with this demo to see how it works:

See the Pen Gappy by Adam Argyle (@argyleink) on CodePen.

CSS Houdini #

Houdini is a set of low-level APIs for the browser's rendering engine that lets you tell the browser how to interpret custom CSS. In other words, it gives you access to the CSS Object Model, letting you extend CSS via JavaScript. This has several benefits:

It gives you much more power to create custom CSS features.
It's easier to separate rendering concerns from application logic.
It's more performant than the CSS polyfilling we currently do with JavaScript since the browser will no longer have to parse scripts and do a second rendering cycle; Houdini code is parsed in the first rendering cycle.

Houdini is an umbrella name for several APIs. If you want more information about them and their current status, take a look at Is Houdini Ready Yet? In our talk, we covered the Properties and Values API, the Paint API, and the Animation Worklet because they're currently the most supported. We could easily dedicate a full post to each of these exciting APIs, but, for now, check out our talk for an overview and some cool demos that start to give a sense of what you can do with the APIs.

Overflow #

There are a few more things on the horizon that we wanted to discuss but didn't have time to cover in depth, so we ran through them in a speed round.⚡ If you haven't heard of some of these features yet, be sure to watch the last part of the talk!

size: a property that will allow you to set height and width at the same time
aspect-ratio: a property that sets an aspect ratio for elements that don't have one intrinsically
min(), max(), and clamp(): functions that will let you set numeric constraints on any CSS property, not just width and height
list-style-type an existing property, but it will soon support a wider range of values, including emoji and SVGs
display: outer inner: The display property will soon accept two parameters, which will let you explicitly specify its outer and inner layouts rather than using compound keywords like inline-flex.
CSS regions: will let you fill a specified, non-rectangular area that content can flow into and out of
CSS modules: JavaScript will be able to request a CSS module and get a rich object back that's easy to perform operations on

Create OS-style backgrounds with backdrop-filter

2019-07-26T00:00:00Z

Translucence, blurring, and other effects are useful ways of creating depth while keeping the context of the background content. They support a host of use cases such as frosted glass, video overlays, translucent navigation headers, inappropriate image censoring, image loading, and so on. You may recognize these effects from two popular operating systems: Windows 10 and iOS.

An example of a frosted glass effect. Source.

Historically, these techniques were difficult to implement on the web, requiring less than perfect hacks or workarounds. In recent years both Safari and Edge have provided these capabilities through the background-filter (and alternatively, the -webkit-backdrop-filter) property, which dynamically blends foreground and background colors based on filter functions. Now Chrome supports background-filter, starting in version 76.

A demonstration of the filter functions for backdrop-filter. Try the example on CodePen.

Browser support #

Browser support

Chrome 76, Supported 76
Firefox 103, Supported 103
Edge 17, Supported 17
Safari 9, Supported 9

Source

For performance reasons, fall back to an image instead of a polyfill when backdrop-filter isn't supported. The example below shows this.

@supports (backdrop-filter: none) {
	.background {
		backdrop-filter: blur(10px);
	}
}

@supports not (backdrop-filter: none) {
  .background {
    background-image: blurred-hero.png;
  }
}

## Basics

- The `backdrop-filter` property applies one or more filters to an element, changing the appearance of anything behind the element.
- The overlaying element must be at least partially transparent.
- The overlaying element will get a new stacking context.

<aside class="aside flow bg-state-bad-bg color-state-bad-text"><p class="cluster color-state-bad-text"><span class="aside__icon box-block "><svg width="24" height="24" viewBox="0 0 24 24" fill="currentColor" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="Error sign">   <path fill-rule="evenodd" clip-rule="evenodd" d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm-1 15v-2h2v2h-2zm0-10v6h2V7h-2z" /> </svg></span><strong>Caution</strong></p><div class=" flow"> <code>backdrop-filter</code> may harm performance. Test it before deploying. </div></aside>

CSS `backdrop-filter` applies one or more effects to an element that is translucent or transparent. To understand that, consider the images below.

<div class="switcher">
<figure class="compare flow" data-type="worse" data-size="full"><p class="compare__label">No foreground transparency</p>

<img     alt="A triangle superimposed on a circle. The circle can&#x27;t be seen through the triangle."          decoding="async"          height="283"          loading="lazy"     sizes="(min-width: 480px) 480px, calc(100vw - 48px)"     src="https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format"     srcset="https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=200 200w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=228 228w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=260 260w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=296 296w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=338 338w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=385 385w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=439 439w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=500 500w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=571 571w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=650 650w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=741 741w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=845 845w,     https://web-dev.imgix.net/image/admin/LOqxvB3qqVkbZBmxMmKS.png?auto=format&w=960 960w"          width="480"   />

```css
.frosty-glass-pane {
  backdrop-filter: blur(2px);
}

Foreground transparency

.frosty-glass-pane {
  opacity: .9;
  backdrop-filter: blur(2px);
}

The image on the left shows how overlapping elements would be rendered if backdrop-filter were not used or supported. The image on the right applies a blurring effect using backdrop-filter. Notice that it uses opacity in addition to backdrop-filter. Without opacity, there would be nothing to apply blurring to. It almost goes without saying that if opacity is set to 1 (fully opaque) there will be no effect on the background.

The backdrop-filter property is like CSS filters in that all your favorite filter functions are supported: blur(), brightness(), contrast(), opacity(), drop-shadow(), and so on. It also supports the url() function if you want to use an external image as the filter, as well as the keywords none, inherit, initial, and unset. There are explanations for all of this on MDN, including descriptions of syntax, filters, and values.

When backdrop-filter is set to anything other than none, the browser creates a new stacking context. A containing block may also be created, but only if the element has absolute and fixed position descendants.

You can combine filters for rich and clever effects, or use just one filter for more subtle or precise effects. You can even combine them with SVG filters.

Examples #

Design techniques and styles previously reserved for operating systems are now performant and achievable with a single CSS declaration. Let's look at some examples.

Single filter #

In the following example, the frosted effect is achieved by combining color and blur. The blur is supplied by backdrop-filter, while the color comes from the element's semi-transparent background color.

.blur-behind-me {
  background-color: rgba(255, 255, 255, 0.3);
  backdrop-filter: blur(.5rem);
}

Try this example for yourself in CodePen.

Multiple filters #

Sometimes you'll need multiple filters to achieve the desired effect. To do this, provide a list of filters separated by a space. For example:

.brighten-saturate-and-blur-behind-me {
  backdrop-filter: brightness(150%) saturate(150%) blur(1rem);
}

In the following example, each of the four panes has a different combination of backdrop filters while the same set of shapes are animated behind them.

Try this example for yourself in CodePen.

Overlays #

This example shows how to blur a semi-transparent background to make text readable while stylistically blending with a page's background.

.modal {
  backdrop-filter: blur(10px);
  background-color: rgba(255, 255, 255, 0.5);
}

Try this example for yourself.

Text contrast on dynamic backgrounds #

As stated earlier, backdrop-filter allows performant effects that would be difficult or impossible on the web. An example of this is changing a background in response to an animation. In this example, backdrop-filter maintains the high contrast between the text and its background in spite of what's going on behind the text. It starts with the default background color darkslategray and uses backdrop-filter to invert the colors after the transformation.

.container::before {
  z-index: 1;
  background-color: darkslategray;
  filter: invert(1);
}

.container::after {
	backdrop-filter: invert(1);
  z-index: 3;
}

Try this example from Chen Hui Jing in Codrops.

Conclusion #

More than 560 of you have upvoted the Chromium bug over the past few years, clearly marking this as a long awaited CSS feature. Chrome's release of backdrop-filter in version 76 brings the web a step closer to truly OS-like UI presentation.

Adam Argyle on web.dev

CSS Subgrid

Subgrid basics #

Sharing a page level "macro" grid #

Checking for support #

Devtools #

Resources #

Adapting typography to user preferences with CSS

Getting setup #

Loading the Roboto Flex variable font #

CSS custom properties and media queries for the win #

Settings when there's no preferences (default) #

Settings when the preference is for high contrast #

Settings when the preference is for low contrast #

Settings when the preference is for dark mode #

All together now #

6 CSS snippets every front-end developer should know in 2023

1. A container query #

2. Scroll snap #

3. Grid pile #

4. Quick circle #

5. Control variants with @layer #

6. Memorize less and reach more with logical properties #

Example codelab

Adding a codelab #

Building a tooltip component

Overview #

Toggletip vs Tooltip #

Markup #

Accessibility #

Styles #

Theme adjustments #

Right to left #

Tooltip positioning #

Top and block-start alignment #

Right and inline-end alignment #

Bottom and block-end alignment #

Left and inline-start alignment #

Animation #

A safe and meaningful default transition #

Adding motion to the transition #

JavaScript #

Conclusion #

Community remixes #

Resources #

Building a floating action button (FAB) component

Overview #

Elements and styles #

FAB container #

FABs markup #

FABs style #

FAB buttons #

Default FAB #

FAB markup #

FAB style #

Mini FAB #

Mini FAB markup #

Mini FAB style #

Accessibility #

Animation #

A reduced motion strategy with custom properties #

Conclusion #

Community remixes #

Resources #

Testing Web Design Color Contrast

WCAG and color contrast #

What are the rules? #

Testing contrast between colors #

Pika (macOS application) #

Comparing any two colors #

Comparing colors with transparency #

Comparing colors with gradients #

VisBug #

Inspect across browsers (and even on mobile) #

Inspect one or many #

Chrome DevTools #

The Chrome DevTools color picker #

Color Picker autocorrection #

Inspection tooltip #

Bump bump 'til you pass 🎶 #