Una Kravets on web.dev

Container queries land in stable browsers

2023-02-14T00:00:00Z

Container query love is in the air! This Valentine’s day, size container queries and container query units are stable in all modern browsers.

Browser support

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

Source

With container queries you can query the styling information of a parent element, such as its inline-size. With media queries, you could query the size of the viewport, container queries enable components that can change based on where they are in the UI.

Container queries are especially handy for responsive design and reusable components. For example, enabling a card component that can lay out in one way when placed in a sidebar, and in a different configuration within a product grid.

Using container queries #

To use container queries, first set containment on a parent element. Do this by setting a container-type on the parent container, or use the container shorthand to give it both a type and name simultaneously:

.card-container {
  container: card / inline-size;
}

Setting the container-type to inline-size queries the inline-direction size of the parent. In latin languages like English, this would be the width of the card, as the text flows inline from left to right.

Now, you can use that container to apply styles to any of its children using @container:

.card-child {
  display: grid;
  grid-template-columns: 1fr 1fr;
}

@container (max-width: 400px) {
 .card-child {
  grid-template-columns: 1fr;
 }
}

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

Additionally, you can use container query length unit values in the same way that you would viewport-based unit values. The difference being that the container units correspond to the container rather than the viewport. The following example demonstrates responsive typography using container query units and the clamp() function to give a minimum and maximum size value:

.card-child h2 {
  font-size: clamp(2rem, 15cqi, 4rem);
}

The 15cqi above refers to 15% of the container’s inline size. The clamp() function gives this a minimum value of 2rem, and a maximum of 4rem. In the meantime, if 15cqi is between these values, the text will shrink and grow correspondingly.

A container query Valentine #

To celebrate the container query love this holiday, we’ve made a Valentine for you all to enjoy, regardless of what (latest version) stable browser you’re viewing this in!

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

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!

State of CSS 2021

2021-12-17T00:00:00Z

The State of CSS 2021 survey ran for the third year in a row, and reached over 8,000 developers worldwide. Let's look at some of the results and how they map to plans browsers have for adding CSS features in 2022.

Feature usage and awareness

For some features, there's a clear trend in usage and awareness year-over-year. CSS grid is an example of this.

This matches the trend for CSS Grid in the 2021 Web Almanac and in Chrome's usage metrics. If you haven't used CSS Grid, now is a great time to learn it.

As more developers use grid, awareness of subgrid is also growing. Subgrid is already available in Firefox and will land in Chrome as part of the work by the Microsoft Team on GridNG.

Other features with strong growth in usage and awareness are aspect-ratio, scroll snap, and custom properties.

Browser compatibility

Browser compatibility is a common pain point for web developers and, to learn more about what CSS features cause the most issues, the survey asked, "Are there any CSS features you have difficulties using because of differences between browsers?"

Survey results like these help guide prioritization for browser vendors. Many of the features are part of the Compat 2021 effort based on the MDN Browser Compatibility Report 2020, and others like subgrid are now being proposed as focus areas for Interop 2022.

What's missing in CSS?

The survey also asked, "Which feature would you most like to be able to use in CSS today?"

Container Queries was the overall "winner", matching the 2020 results. Container queries enable component-based responsive design by allowing elements to query their parent selector for style changes. This is a much more local, specified scope than is currently possible with media queries.

Chrome is currently working on an experimental implementation, and funding the work of Miriam Suzanne, as she develops the specification in the CSS Working Group. You can try it out by going to about:flags, searching for, and enabling, the Container Queries flag in Canary, or by using the container query polyfill. You can learn more about container queries, as well as see some demos that use them in the latest series of Designing in the Browser or trying them yourself here.

Learn more

Please see the full report to learn more, see recommended resources, or dig into the data yourself.

Thanks to Sacha Greif for running the survey, and to the over 8,000 web developers who generously took the time to answer it.

CSS for Web Vitals

2021-06-02T00:00:00Z

The way you write your styles and build layouts can have a major impact on Core Web Vitals. This is particularly true for Cumulative Layout Shift (CLS) and Largest Contentful Paint (LCP).

This article covers CSS-related techniques for optimizing Web Vitals. These optimizations are broken down by different aspects of a page: layout, images, fonts, animations, and loading. Along the way, we'll explore improving an example page:

Layout #

Inserting content into the DOM #

Inserting content into a page after the surrounding content has already loaded pushes everything else on the page down. This causes layout shifts.

Cookie notices, particularly those placed at the top of the page, are a common example of this problem. Other page elements that often cause this type of layout shift when they load include ads and embeds.

Identify #

The Lighthouse "Avoid large layout shifts" audit identifies page elements that have shifted. For this demo, the results look like this:

The cookie notice is not listed in these findings because the cookie notice itself isn't shifting when it loads. Rather, it causes the items below it on the page (that is, div.hero and article) to shift. For more information on identifying and fixing layout shifts, see Debugging Layout Shifts.

Fix #

Place the cookie notice at the bottom of the page using absolute or fixed positioning.

Before:

.banner {
  position: sticky;
  top: 0;
}

After:

.banner {
  position: fixed;
  bottom: 0;
}

Another way to fix this layout shift would be to reserve space for the cookie notice at the top of the screen. This approach is equally effective. For more information, see Cookie notice best practices.

Images #

Images and Largest Contentful Paint (LCP) #

Images are commonly the Largest Contentful Paint (LCP) element on a page. Other page elements that can be the LCP element include text blocks and video poster images. The time at which the LCP element loads determines LCP.

It's important to note that a page's LCP element can vary from page load to page load depending on the content that is visible to the user when the page is first displayed. For example, in this demo, the background of the cookie notice, the hero image, and the article text are some of the potential LCP elements.

In the example site, the background image of the cookie notice is actually a large image. To improve LCP, you could instead paint the gradient in CSS, rather than load an image to create the effect.

Fix #

Change the .banner CSS to use a CSS gradient rather than an image:

Before:

background: url("https://cdn.pixabay.com/photo/2015/07/15/06/14/gradient-845701\_960\_720.jpg")

After:

background: linear-gradient(135deg, #fbc6ff 20%, #bdfff9 90%);

Images and layout shifts #

Browsers can only determine the size of an image once the image loads. If the image load occurs after the page has been rendered, but no space has been reserved for the image, a layout shift occurs when the image appears. In the demo, the hero image is causing a layout shift when it loads.

Identify #

To identify images without explicit width and height, use Lighthouse's "Image elements have explicit width and height" audit.

In this example, both the hero image and article image are missing width and height attributes.

Fix #

Set the width and height attributes on these images to avoid layout shifts.

Before:

<img src="https://source.unsplash.com/random/2000x600" alt="image to load in">
<img src="https://source.unsplash.com/random/800x600" alt="image to load in">

After:

<img src="https://source.unsplash.com/random/2000x600" width="2000" height="600" alt="image to load in">
<img src="https://source.unsplash.com/random/800x600" width="800" height="600" alt="image to load in">

The image now loads without causing a layout shift.

Fonts #

Fonts can delay text rendering and cause layout shifts. As a result, it is important to deliver fonts quickly.

Delayed text rendering #

By default, a browser will not immediately render a text element if its associated web fonts have not loaded yet. This is done to prevent a "flash of unstyled text" (FOUT). In many situations, this delays First Contentful Paint (FCP). In some situations, this delays Largest Contentful Paint (LCP).

Layout shifts #

Font swapping, while excellent for displaying content to the user quickly, has the potential to cause layout shifts. These layout shifts occur when a web font and its fallback font take up different amounts of space on the page. Using similarly proportioned fonts will minimize the size of these layout shifts.

In this example, font swapping caused page elements to shift upwards by five pixels.

Identify #

To see the fonts that are being loaded on a particular page, open the Network tab in DevTools and filter by Font. Fonts can be large files, so only using fewer fonts is generally better for performance.

To see how long it takes for the font to be requested, click on the Timing tab. The sooner that a font is requested, the sooner it can be loaded and used.

To see the request chain for a font, click on the Initiator tab. Generally speaking, the shorter the request chain, the sooner the font can be requested.

Fix #

This demo uses the Google Fonts API. Google Fonts provides the option to load fonts via <link> tags or an @import statement. The <link> code snippet includes a preconnect resource hint. This should result in faster stylesheet delivery than using the @import version.

At a very high-level, you can think of resource hints as a way to hint to the browser that it will need to set up a particular connection or download a particular resource. As a result, the browser will prioritize these actions. When using resource hints, keep in mind that prioritizing a particular action takes away browser resources from other actions. Thus, resource hints should be used thoughtfully and not for everything. For more information, see Establish network connections early to improve perceived page speed.

Remove the following @import statement from your stylesheet:

@import url('https://fonts.googleapis.com/css2?family=Montserrat:wght@400&family=Roboto:wght@300&display=swap');

Add the following <link> tags to the <head> of the document:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@100&display=swap" rel="stylesheet">

These link tags instruct the browser to establish an early connection to the origins used by Google Fonts and to load the stylesheet that contains the font declaration for Montserrat and Roboto. These <link> tags should be placed as early in the <head> as possible.

Animations #

The primary way that animations affect Web Vitals is when they cause layout shifts. There are two types of animations that you should avoid using: animations that trigger layout and "animation-like" effects that move page elements. Typically these animations can be replaced with more performant equivalents by using CSS properties like transform, opacity, and filter. For more information, see How to create high-performance CSS animations.

Identify #

The Lighthouse "Avoid non-composited animations" audit may be helpful for identifying non-performant animations.

Fix #

Change the slideIn animation sequence to use transform: translateX() rather than transitioning themargin-left property.

Before:

.header {
  animation: slideIn 1s 1 ease;
}

@keyframes slideIn {
  from {
    margin-left: -100%;
  }
  to {
    margin-left: 0;
  }
}

After:

.header {
  animation: slideIn 1s 1 ease;
}

@keyframes slideIn {
  from {
    transform: translateX(-100%);
  }

  to {
    transform: translateX(0);
  }
}

Critical CSS #

Stylesheets are render-blocking. This means that the browser encounters a stylesheet, it will stop downloading other resources until the browser has downloaded and parsed the stylesheet. This may delay LCP. To improve performance, consider removing unused CSS, inlining critical CSS, and deferring non-critical CSS.

Conclusion #

Although there is still room for further improvements (for example, using image compression to deliver images more quickly), these changes have significantly improved the Web Vitals of this site. If this were a real site, the next step would be to collect performance data from real users to assess whether it is meeting the Web Vitals thresholds for most users. For more information about Web Vitals, see Learn Web Vitals.

The new responsive: Web design in a component-driven world

2021-05-19T00:00:00Z

Responsive Design Today #

Today, when using the term: "responsive design", you are most likely thinking about using media queries to change layout when resizing a design from mobile size, to tablet size, through to desktop size.

But soon, this perception of responsive design may be considered as outdated as using tables for page layout.

Viewport-based media queries give you some powerful tools, but lack a lot of finesse. They lack the ability to respond to user needs, and the ability to inject responsive styles into components themselves.

You can use global viewport information to style your components, but they still don't own their styles, and that doesn't work when our design systems are component-based and not page-based.

The good news is, the ecosystem is changing, and it's changing pretty rapidly. CSS is evolving, and a new era of responsive design is right on the horizon.

We see this happen about every 10 years. 10 years ago, around 2010-2012, we saw a huge change with mobile and responsive design, and the emergence of CSS3.

Source: Web Design Museum.

So it works out that, yet again, the ecosystem is ready for some pretty big changes to happen to CSS. The engineers at Chrome and across the web platform are prototyping, speccing, and starting the implementation for the next era of responsive design.

These updates include user-preference based media features, container queries, and media queries for new screen types, such as foldable screens.

Responsive to the user #

New user preference media features, give you the ability to style web experiences that align with the user's own specific preferences and needs. This means that preference media features allow you to adapt your user experiences to your user's experiences.

These user preference media features include:

prefers-reduced-motion
prefers-contrast
prefers-reduced-transparency
prefers-color-scheme
inverted-colors
And more

Preference features pick up on the preferences a user has set in their operating system, and help to build a more robust and personalized web experience, especially for those with accessibility needs.

`prefers-reduced-motion` #

Users who have set operating system preferences for reduced motion, are requesting fewer animations when using their computer in general. Therefore, it's likely that they wouldn't appreciate a flashy intro screen, card flip animation, intricate loader, or other flashy animations while using the web.

With prefers-reduced-motion you can design your pages with reduced-motion in mind, and create a motion-enhanced experience for those who don't have this preference set.

This card has information on both sides. The baseline reduced-motion experience is a crossfade to show that information, while the motion-enhanced experience is a card flip.

Prefers-reduced-motion shouldn't mean "no motion", since motion is so critical to conveying information online. Instead, provide a solid baseline experience that guides your users without unnecessary movement, and progressively enhance that experience for your users without those accessibility needs or preferences.

`prefers-color-scheme` #

Another preference media feature is prefers-color-scheme. This feature helps you to customize your UI to the theme which your user prefers. In their operating system, whether it's on desktop or mobile, users can set a preference for light, dark, or auto themes, which change depending on the time of day.

If you set up your page using CSS custom properties, swapping color values is made straightforward. You can quickly update your color theme values, such as backgroundColor and textOnPrimary to dynamically adjust to the new theme within the media query.

To make it easier to test some of these preference queries out, you can use DevTools for emulation instead of opening up your system preferences each time.

Designing for dark theme #

When designing for a dark theme, it's not just about inverting background and text colors or dark scrollbars. There are a few considerations you might not realize. For example, you might need to desaturate colors on a dark background to reduce visual vibration.

Instead of using shadows to create depth and draw an element forward, you may want to use light in the element's background-color to draw it forward. This is because shadows won't be as effective on a dark background.

Material design provides some great guidance on designing for dark themes.

Dark themes not only provide a more customized user experience, but they can also improve battery life significantly in AMOLED screens. Those are the screens we're seeing in newer high-end phones, and they're becoming increasingly popular across mobile devices.

A 2018 Android study on dark themes showed a power draw savings of up to 60%, depending on the screen brightness and overall user interface. The 60% statistic came from comparing the Youtube play screen with a paused video at 100% screen brightness using dark theme for the app UI vs a light theme.

You should always provide a dark theme experience for your users whenever possible.

Responsive to the container #

One of the most exciting emerging areas in CSS is container queries, also frequently called element queries. It's hard to understate what the shift from page-based responsive design to container-based responsive design will do to evolve the design ecosystem.

Here's an example of the powerful abilities that container queries provide. You can manipulate any of the card element's styles, including the link list, font sizes, and overall layout based on its parent container:

See demo on Codepen (behind a flag in Canary).

This example shows two identical components with two different container sizes, both taking up space in a layout created using CSS Grid. Each component fits its unique space allotment, and styles itself accordingly.

This amount of flexibility is something that is not possible with media queries alone.

Container queries provide a much more dynamic approach to responsive design. This means that if you put this card component in a sidebar or hero section or within a grid inside of the main body of a page, the component itself owns its responsive information and sizes according to the container, not the viewport

This requires the @container at-rule This works in a similar way to a media query with @media, but instead, @container queries the parent container for information rather than the viewport and user agent.

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

@container (max-width: 850px) {
  .links {
    display: none;
  }

  .time {
    font-size: 1.25rem;
  }

  /* ... */
}

First, set containment on the parent element. And then, write a @container query, to style any of the elements within the container based on its size, using min-width or max-width.

The code above uses max-width, and sets the links to display:none, as well as decreasing the time font size when the container is less than 850px wide.

Container query cards #

In this demo plant website, each of the product cards, including the one in the hero, the sidebar of recently viewed items, and the product grid, are all the exact same component, with the same markup.

See demo on Codepen (behind a flag in Canary).

There are no media queries used to create this entire layout, just container queries. This allows for each product card to shift to the proper layout to fill its space. The grid for example, uses a minmax column layout to let the elements flow into their space, and re-layout the grid when that space is too compressed (which means that it hit the minimum size).

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

@container (min-width: 350px) {
  .card-container {
    padding: 0.5rem 0 0;
    display: flex;
  }

  .card-container button {
    /* ... */
  }
}

When there is at least 350px of space in the grid, the card layout goes horizontal by being set to display: flex, which has a default flex-direction of "row".

With less space, the product cards stack. Each product card styles itself, something that would be impossible with global styles alone.

Mixing Container Queries with Media Queries #

Container queries have so many use cases—one being a calendar component. You can use container queries to re-layout the calendar events and other segments based on the available width of their parent.

See demo on Codepen (behind a flag in Canary).

This demo container queries to change the layout and style of the calendar's date and day of the week, as well as adjusting the margins and font size on the scheduled events to help them better fit the space.

Then, use a media query to shift the entire layout for smaller screen sizes. This example shows how powerful it is to combine media queries (adjusting the global, or macro styles) with container queries (adjusting the container's children, and their micro styles).

So now we can think of Macro and Micro layouts within the same UI component to allow for some really nice nuanced design decisions.

Using container queries today #

These demos are now available to play with behind a flag in Chrome Canary. Go to about://flags in Canary and turn on the #enable-container-queries flag. This will enable support for @container, inline-size and block-size values for the contain property, and the LayoutNG Grid implementation.

The flag also enables the corresponding Chrome DevTools features. Learn how to inspect and debug container queries in DevTools.

Scoped styles #

To build on container queries, the CSS working group is also actively discussing scoped styles to help with proper namespacing and collision-avoidance for components.

Figure originally designed by Miriam Suzanne.

Scoped styles allow for pass-through and component-specific styling to avoid naming collisions, something that many frameworks and plugins like CSS modules already enable us to do within frameworks. This spec would now allow us to write encapsulated styles natively for our components with readable CSS without the need to adjust the markup.

/* @scope (<root>#) [to (<boundary>#)]? { … } */

@scope (.tabs) to (.panel) {
  :scope { /* targeting the scope root */ }
  .light-theme :scope .tab { /* contextual styles */ }
}

Scoping would allow us to create "donut shaped" selectors, where we can specify where to keep a style encapsulated, and where to break out of that scoped style to refer back to a more global style.

An example of this would be a tab panel, where we'd want the tabs to get the scoped style, and the panel within the tabs to get a parent style.

Responsive to the form factor #

The next topic in our conversation about the new era of responsive design is a shift in form factors, and the growing possibilities of what we'll need to be designing for as a web community (such as shape-shifting screen or virtual reality).

Diagram from Microsoft Edge Explainers.

Foldable or flexible screens, and designing for screen spanning is one example of where we can see a form factor shift today. And screen-spanning is yet another spec being worked on to cover these new form factors and needs.

An experimental media query for screen-spanning could help us here. It currently behaves like this: @media (spanning: <type of fold>). The demo sets up a grid layout with two columns: one has a width of --sidebar-width, which is 5rem by default, and the other is 1fr. When the layout is viewed on a dual screen that has a single vertical fold, the value of --sidebar-width is updated with the environment value of the left fold.

:root {
  --sidebar-width: 5rem;
}

@media (spanning: single-fold-vertical) {
  --sidebar-width: env(fold-left);
}

main {
    display: grid;
    grid-template-columns: var(--sidebar-width) 1fr;
}

This enables a layout where the sidebar, the navigation in this case, fills the space of one of the folds, where the app UI fills the other. This prevents a "crease" in the UI.

You can test out foldable screens in the Chrome DevTools emulator to help debug and prototype screen spanning directly in the browser.

Conclusion #

Exploring UI design beyond a flat screen is yet another reason why container queries and scoped styles are so important. They give you the opportunity to silo component styles from page layout and global styles, and user styles, enabling more resilient responsive design. This means you can now design macro layouts using page-based media queries, including screen-spanning nuances. At the same time using micro layouts with container queries on the components, and add user-preference based media queries to customize user experiences based on their unique preferences and need.

This is the new responsive.

It's combining macro layout with micro layout, and on top of all of that, it's taking user customization and form factor into account.

Any of these changes alone would constitute a considerable shift in how we design for the web. But combined, they signify a really big shift in how we even conceptualize responsive design. It's time to think about responsive design beyond viewport size, and start considering all of these new axes for better component-based and customized experiences.

The next era of responsive design is here, and you can already start to explore it yourself.

web.dev/learnCSS #

And for now, if you want to level up your CSS game, and maybe revisit some basics, my team is launching a brand new, totally free CSS course and reference on web.dev. You can access it via web.dev/learnCSS.

I hope you enjoyed this overview on the next era of responsive design, and some of the primitives that will come along with it, and I also hope you're as excited as I am about what this means for the future of web design.

It opens up a huge opportunity to us as a UI community to embrace component-based styles, new form factors, and create user-responsive experiences.

New aspect-ratio CSS property supported in Chromium, Safari Technology Preview, and Firefox Nightly

2021-01-28T00:00:00Z

Aspect ratio #

Browser support

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

Source

Aspect ratio is most commonly expressed as two integers and a colon in the dimensions of: width:height, or x:y. The most common aspect ratios for photography are 4:3 and 3:2, while video, and more recent consumer cameras, tend to have a 16:9 aspect ratio.

Two images with the same aspect ratio. One is 634 x 951px while the other is 200 x 300px. Both have a 2:3 aspect ratio.

With the advent of responsive design, maintaining aspect ratio has been increasingly important for web developers, especially as image dimensions differ and element sizes shift based on available space.

Some examples of where maintaining aspect ratio become important are:

Creating responsive iframes, where they are 100% of a parent's width, and the height should remain a specific viewport ratio
Creating intrinsic placeholder containers for images, videos, and embeds to prevent re-layout when the items load and take up space
Creating uniform, responsive space for interactive data visualizations or SVG animations
Creating uniform, responsive space for multi-element components such as cards or calendar dates
Creating uniform, responsive space for multiple images of varying dimension (can be used alongside object-fit)

Object-fit #

Defining an aspect ratio helps us with sizing media in a responsive context. Another tool in this bucket is the object-fit property, which enables users to describe how an object (such an as image) within a block should fill that block:

Showcasing various object-fit values. See demo on Codepen.

The initial and fill values re-adjust the image to fill the space. In our example, this causes the image to be squished and blurry, as it re-adjusts pixels. Not ideal. object-fit: cover uses the image's smallest dimension to fill the space and crops the image to fit into it based on this dimension. It "zooms in" at its lowest boundary. object-fit: contain ensures that the entire image is always visible, and so the opposite of cover, where it takes the size of the largest boundary (in our example above this is width), and resizes the image to maintain its intrinsic aspect ratio while fitting into the space. The object-fit: none case shows the image cropped in its center (default object position) at its natural size.

object-fit: cover tends to work in most situations to ensure a nice uniform interface when dealing with images of varying dimensions, however, you lose information this way (the image is cropped at its longest edges).

If these details are important (for example, when working with a flat lay of beauty products), cropping important content is not acceptable. So the ideal scenario would be responsive images of varying sizes that fit the UI space without cropping.

The old hack: maintaining aspect ratio with `padding-top` #

Using padding-top to set a 1:1 aspect ratio on post preview images within a carousel.

In order to make these more responsive, we can use aspect ratio. This allows for us to set a specific ratio size and base the rest of the media on an individual axis (height or width).

A currently well-accepted cross-browser solution for maintaining aspect ratio based on an image's width is known as the "Padding-Top Hack". This solution requires a parent container and an absolutely placed child container. One would then calculate the aspect ratio as a percentage to set as the padding-top. For example:

1:1 aspect ratio = 1 / 1 = 1 = padding-top: 100%
4:3 aspect ratio = 3 / 4 = 0.75 = padding-top: 75%
3:2 aspect ratio = 2 / 3 = 0.66666 = padding-top: 66.67%
16:9 aspect ratio = 9 / 16 = 0.5625 = padding-top: 56.25%

Now that we have identified the aspect ratio value, we can apply that to our parent container. Consider the following example:

<div class="container">
  <img class="media" src="..." alt="...">
</div>

We could then write the following CSS:

.container {
  position: relative;
  width: 100%;
  padding-top: 56.25%; /* 16:9 Aspect Ratio */
}

.media {
  position: absolute;
  top: 0;
}

Maintaining aspect ratio with `aspect-ratio` #

Using aspect-ratio to set a 1:1 aspect ratio on post preview images within a carousel.

Unfortunately, calculating these padding-top values is not very intuitive, and requires some additional overhead and positioning. With the new intrinsic aspect-ratio CSS property, the language for maintaining aspect ratios is much more clear.

With the same markup, we can replace: padding-top: 56.25% with aspect-ratio: 16 / 9, setting aspect-ratio to a specified ratio of width / height.

Using padding-top

.container {
  width: 100%;
  padding-top: 56.25%;
}

Using aspect-ratio

.container {
  width: 100%;
  aspect-ratio: 16 / 9;
}

Using aspect-ratio instead of padding-top is much more clear, and does not overhaul the padding property to do something outside of its usual scope.

This new property also adds the ability to set aspect ratio to auto, where "replaced elements with an intrinsic aspect ratio use that aspect ratio; otherwise the box has no preferred aspect ratio." If both auto and a <ratio> are specified together, the preferred aspect ratio is the specified ratio of width divided by height unless it is a replaced element with an intrinsic aspect ratio, in which case that aspect ratio is used instead.

Example: consistency in a grid #

This works really well with CSS layout mechanisms like CSS Grid and Flexbox as well. Consider a list with children that you want to maintain a 1:1 aspect ratio, such as a grid of sponsor icons:

<ul class="sponsor-grid">
  <li class="sponsor">
    <img src="..." alt="..."/>
  </li>
  <li class="sponsor">
    <img src="..." alt="..."/>
  </li>
</ul>

.sponsor-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(120px, 1fr));
}

.sponsor img {
  aspect-ratio: 1 / 1;
  width: 100%;
  object-fit: contain;
}

Images in a grid with their parent element at various aspect ratio dimensions. See demo on Codepen.

Example: preventing layout shift #

Another great feature of aspect-ratio is that it can create placeholder space to prevent Cumulative Layout Shift and deliver better Web Vitals. In this first example, loading an asset from an API such as Unsplash creates a layout shift when the media is finished loading.

Video of cumulative layout shift that happens when no aspect ratio is set on a loaded asset. This video is recorded with an emulated 3G network.

Using aspect-ratio, on the other hand, creates a placeholder to prevent this layout shift:

img {
  width: 100%;
  aspect-ratio: 8 / 6;
}

Video with a set aspect ratio is set on a loaded asset. This video is recorded with an emulated 3G network. See demo on Codepen.

Bonus tip: image attributes for aspect ratio #

Another way to set an image's aspect ratio is through image attributes. If you know the dimensions of the image ahead of time, it is a best practice to set these dimensions as its width and height.

For our example above, knowing the dimensions are 800px by 600px, the image markup would look like: <img src="image.jpg" alt="..." width="800" height="600">. If the image sent has the same aspect ratio, but not necessarily those exact pixel values, we could still use image attribute values to set the ratio, combined with a style of width: 100% so that the image takes up the proper space. All together that would look like:

<!-- Markup -->
<img src="image.jpg" alt="..." width="8" height="6">

/* CSS */
img {
  width: 100%;
}

In the end, the effect is the same as setting the aspect-ratio on the image via CSS, and cumulative layout shift is avoided (see demo on Codepen).

Conclusion #

With the new aspect-ratio CSS property, launching across multiple modern browsers, maintaining proper aspect ratios in your media and layout containers gets a little bit more straightforward.

Photos by Amy Shamblen and Lionel Gustave via Unsplash.

Cross-browser paint worklets and Houdini.how

2020-12-10T00:00:00Z

CSS Houdini is an umbrella term that describes a series of low-level browser APIs that give developers much more control and power over the styles they write.

Houdini enables more semantic CSS with the Typed Object Model. Developers can define advanced CSS custom properties with syntax, default values, and inheritance through the Properties and Values API.

It also introduces paint, layout, and animation worklets, which open up a world of possibilities, by making it easier for authors to hook into the styling and layout process of the browser's rendering engine.

Understanding Houdini worklets #

Houdini worklets are browser instructions that run off the main thread and can be called when needed. Worklets enable you to write modular CSS to accomplish specific tasks, and require a single line of JavaScript to import and register. Much like service workers for CSS style, Houdini worklets are registered to your application, and once registered can be used in your CSS by name.

Write worklet file Register worklet module (CSS.paintWorklet.addModule(workletURL)) Use worklet (background: paint(confetti))

Implementing your own features with the CSS Painting API #

The CSS Painting API is an example of such a worklet (the Paint worklet), and enables developers to define canvas-like custom painting functions that can be used directly in CSS as backgrounds, borders, masks, and more. There is a whole world of possibilities for how you can use CSS Paint in your own user interfaces.

For example, instead of waiting for a browser to implement an angled borders feature, you can write your own Paint worklet, or use an existing published worklet. Then, rather than using border-radius apply this worklet to borders and clipping.

The example above uses the same paint worklet with different arguments (see code below) to accomplish this result. Demo on Glitch.

.angled {
  --corner-radius: 15 0 0 0;
  --paint-color: #6200ee;
  --stroke-weight: 0;

  /* Mask every angled button with fill mode */
  -webkit-mask: paint(angled-corners, filled);
}

.outline {
  --stroke-weight: 1;

  /* Paint outline */
  border-image: paint(angled-corners, outlined) 0 fill !important;
}

The CSS Painting API is currently one of the best-supported Houdini APIs, its spec being a W3C candidate recommendation. It is currently enabled in all Chromium-based browsers, partially supported in Safari, and is under consideration for Firefox.

The CSS Painting API is currently supported on Chromium-based browsers.

But even without full browser support, you can still get creative with the Houdini Paint API and see your styles work across all modern browsers with the CSS Paint Polyfill. And to showcase a few unique implementations, as well as to provide a resource and worklet library, my team built houdini.how.

Houdini.how #

Screenshot from the Houdini.how homepage.

Houdini.how is a library and reference for Houdini worklets and resources. It provides everything you need to know about CSS Houdini: browser support, an overview of its various APIs, usage information, additional resources, and live paint worklet samples. Each sample on Houdini.how is backed by the CSS Paint API, meaning they each work on all modern browsers. Give it a whirl!

Using Houdini #

Houdini worklets must either be run via a server locally, or on HTTPS in production. In order to work with a Houdini worklet, you will need to either install it locally or use a content delivery network (CDN) like unpkg to serve the files. You will then need to register the worklet locally.

There are a few ways to include the Houdini.how showcase worklets in your own web projects. They can either be used via a CDN in a prototyping capacity, or you can manage the worklets on your own using npm modules. Either way, you'll want to also include the CSS Paint Polyfill to ensure they are cross-browser compatible.

1. Prototyping with a CDN #

When registering from unpkg, you can link directly to the worklet.js file without needing to locally install the worklet. Unpkg will resolve to the worklet.js as the main script, or you can specify it yourself. Unpkg will not cause CORS issues, as it is served over HTTPS.

CSS.paintWorklet.addModule("https://unpkg.com/<package-name>");

Note that this does not register the custom properties for syntax and fallback values. Instead, they each have fallback values embedded into the worklet.

To optionally register the custom properties, include the properties.js file as well.

<script src="https://unpkg.com/<package-name>/properties.js"></script>

To include the CSS Paint Polyfill with unpkg:

<script src="https://unpkg.com/css-paint-polyfill"></script>

2. Managing worklets via NPM #

Install your worklet from npm:

npm install <package-name>
npm install css-paint-polyfill

Importing this package does not automatically inject the paint worklet. To install the worklet, you'll need to generate a URL that resolves to the package's worklet.js, and register that. You do so with:

CSS.paintWorklet.addModule(..file-path/worklet.js)

The npm package name and link can be found on each worklet card.

You will also need to include the CSS Paint Polyfill via script or import it directly, as you would with a framework or bundler.

Here is an example of how to use Houdini with the paint polyfill in modern bundlers:

import 'css-paint-polyfill';
import '<package-name>/properties.js'; // optionally register properties
import workletURL from 'url:<package-name>/worklet.js';

CSS.paintWorklet.addModule(workletURL);

Contribute #

Now that you've played around with some Houdini samples, it's your turn to contribute your own! Houdini.how does not host any worklets itself, and instead showcases the work of the community. If you have a worklet or resource you would like to submit, check out the github repo with contribution guidelines. We'd love to see what you come up with!

min(), max(), and clamp(): three logical CSS functions to use today

2020-10-14T00:00:00Z

With responsive design evolving and becoming increasingly nuanced, CSS itself is constantly evolving and providing authors increased control. The min(), max(), and clamp() functions, now supported in all modern browsers, are among the latest tools in making authoring websites and apps more dynamic and responsive.

When it comes to flexible and fluid typography, controlled element resizing, and maintaining proper spacing, min(), max(), and clamp() can help.

Background #

The math functions, calc(), min(), max(), and clamp() allow mathematical expressions with addition (+), subtraction (-), multiplication (*), and division (/) to be used as component values
CSS Values And Units Level 4

Browser support #

`min()` #

Browser support

Chrome 79, Supported 79
Firefox 75, Supported 75
Edge 79, Supported 79
Safari 11.1, Supported 11.1

Source

`max()` #

Browser support

Chrome 79, Supported 79
Firefox 75, Supported 75
Edge 79, Supported 79
Safari 11.1, Supported 11.1

Source

`clamp()` #

Browser support

Chrome 79, Supported 79
Firefox 75, Supported 75
Edge 79, Supported 79
Safari 13.1, Supported 13.1

Source

Usage #

Showing how the min() function selects a value based on a list of options and its parent. See Demo on Codepen.

You can use min(), max(), and clamp() on the right hand side of any CSS expression where it would make sense. For min() and max(), you provide an argument list of values, and the browser determines which one is either the smallest or largest, respectively. For example, in the case of: min(1rem, 50%, 10vw), the browser calculates which of these relative units is the smallest, and uses that value as the actual value.

Showing how the max() function selects a value based on a list of options and its parent. See Demo on Codepen.

The max() function selects the largest value from a list of comma-separated expressions.

Showing how the clamp() function selects a value based on a list of options and its parent. See Demo on Codepen.

To use clamp() enter three values: a minimum value, ideal value (from which to calculate), and maximum value.

Any of these functions can be used anywhere a <length>, <frequency>, <angle>, <time>, <percentage>, <number>, or <integer> is allowed. You can use these on their own (i.e. font-size: max(0.5vw, 50%, 2rem)), in conjunction with calc() (i.e. font-size: max(calc(0.5vw - 1em), 2rem)), or composed (i.e. font-size: max(min(0.5vw, 1em), 2rem)).

To recap:

min(<value-list>): selects the smallest (most negative) value from a list of comma-separated expressions
max(<value-list>): selects the largest (most positive) value from a list of comma-separated expressions
clamp(<min>, <ideal>, <max>): clamps a value between an upper and lower bound, based on a set ideal value

Let's take a look at some examples.

The perfect width #

According to The Elements of Typographic Style by Robert Bringhurst, "anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size."

To ensure that your text blocks are not narrower than 45 characters or wider than 75 characters, use clamp() and the ch (0-width character advance) unit:

p {
  width: clamp(45ch, 50%, 75ch);
}

This allows for the browser to determine the width of the paragraph. It will set the width to 50%, unless 50% is smaller than 45ch, at which point 45ch will be selected, and visa versa for if 50% is wider than 75ch. In this demo, the card itself is getting clamped:

Using the clamp() function to limit a minimum and maximum width. See Demo on Codepen.

You could break this up with just the min() or max() function. If you want the element to always be at 50% width, and not exceed 75ch in width (i.e. on larger screens), write: width: min(75ch, 50%);. This essentially sets a "max" size by using the min() function.

Using the min() function to set a maximum width.

By the same token, you can ensure a minimum size for legible text using the max() function. This would look like: width: max(45ch, 50%);. Here, the browser selects whichever is larger, 45ch or 50%, meaning the element must be at least 45ch or larger.

Using the max() function to set a minimum width.

Padding management #

Using the same concept as above, where the min() function can set a "max" value and max() sets a "min" value, you can use max() to set a minimum padding size. This example comes from CSS Tricks, where reader Caluã de Lacerda Pataca shared this idea: The idea is to enable an element to have additional padding at larger screen sizes, but maintain a minimum padding at smaller screen sizes, particularly on the inline padding. To achieve this, use calc() and subtract the minimum padding from either side: calc((100vw - var(--contentWidth)) / 2), or use max: max(2rem, 50vw - var(--contentWidth) / 2). All together it looks like:

footer {
  padding: var(--blockPadding) max(2rem, 50vw - var(--contentWidth) / 2);
}

Setting a minimum padding for a component using the max() function. See Demo on Codepen.

Fluid typography #

In order to enable fluid typography, Mike Riethmeuller popularized a technique that uses the clamp() function to set a minimum font size, maximum font size, and allow for scaling from the min to the max.

Creating fluid typography with clamp(). See Demo on Codepen.

With clamp(), you can write this more clearly. Rather than requiring a complex string, the browser can do the work for you. Set the minimum acceptable font size (for example, 1.5rem for a title, maximum size (i.e. 3rem) and ideal size of 5vw.

Now, we get typography that scales with the viewport width of the page until it reaches the limiting minimum and maximum values, in a much more succinct line of code:

p {
  font-size: clamp(1.5rem, 5vw, 3rem);
}

Conclusion #

The CSS math functions, min(), max(), and clamp() are very powerful, well supported, and could be just what you're looking for to help you build responsive UIs. For more resources, check out:

Cover image from @yer_a_wizard on Unsplash.

`content-visibility`: the new CSS property that boosts your rendering performance

2020-08-05T00:00:00Z

The content-visibility property, launching in Chromium 85, might be one of the most impactful new CSS properties for improving page load performance. content-visibility enables the user agent to skip an element's rendering work, including layout and painting, until it is needed. Because rendering is skipped, if a large portion of your content is off-screen, leveraging the content-visibility property makes the initial user load much faster. It also allows for faster interactions with the on-screen content. Pretty neat.

In our article demo, applying content-visibility: auto to chunked content areas gives a 7x rendering performance boost on initial load. Read on to learn more.

Browser support #

Browser support

Chrome 85, Supported 85
Firefox preview, Preview
Edge 85, Supported 85
Safari, Not supported

Source

content-visibility relies on primitives within the the CSS Containment Spec. While content-visibility is only supported in Chromium 85 for now (and deemed "worth prototyping" for Firefox), the Containment Spec is supported in most modern browsers.

CSS Containment #

The key and overarching goal of CSS containment is to enable rendering performance improvements of web content by providing predictable isolation of a DOM subtree from the rest of the page.

Basically a developer can tell a browser what parts of the page are encapsulated as a set of content, allowing the browsers to reason about the content without needing to consider state outside of the subtree. Knowing which bits of content (subtrees) contain isolated content means the browser can make optimization decisions for page rendering.

There are four types of CSS containment, each a potential value for the contain CSS property, which can be combined in a space-separated list of values:

size: Size containment on an element ensures that the element's box can be laid out without needing to examine its descendants. This means we can potentially skip layout of the descendants if all we need is the size of the element.
layout: Layout containment means that the descendants do not affect the external layout of other boxes on the page. This allows us to potentially skip layout of the descendants if all we want to do is lay out other boxes.
style: Style containment ensures that properties which can have effects on more than just its descendants don't escape the element (e.g. counters). This allows us to potentially skip style computation for the descendants if all we want is to compute styles on other elements.
paint: Paint containment ensures that the descendants of the containing box don't display outside its bounds. Nothing can visibly overflow the element, and if an element is off-screen or otherwise not visible, its descendants will also not be visible. This allows us to potentially skip painting the descendants if the element is offscreen.

Skipping rendering work with `content-visibility` #

It may be hard to figure out which containment values to use, since browser optimizations may only kick in when an appropriate set is specified. You can play around with the values to see what works best, or you can use another CSS property called content-visibility to apply the needed containment automatically. content-visibility ensures that you get the largest performance gains the browser can provide with minimal effort from you as a developer.

The content-visibility property accepts several values, but auto is the one that provides immediate performance improvements. An element that has content-visibility: auto gains layout, style and paint containment. If the element is off-screen (and not otherwise relevant to the user—relevant elements would be the ones that have focus or selection in their subtree), it also gains size containment (and it stops painting and hit-testing its contents).

What does this mean? In short, if the element is off-screen its descendants are not rendered. The browser determines the size of the element without considering any of its contents, and it stops there. Most of the rendering, such as styling and layout of the element's subtree are skipped.

As the element approaches the viewport, the browser no longer adds the size containment and starts painting and hit-testing the element's content. This enables the rendering work to be done just in time to be seen by the user.

A note on accessibility #

One of the features of content-visibility: auto is that the off-screen content remains available in the document object model and therefore, the accessibility tree (unlike with visibility: hidden). This means, that content can be searched for on the page, and navigated to, without waiting for it to load or sacrificing rendering performance.

The flip-side of this, however, is that landmark elements with style features such as display: none or visibility: hidden will also appear in the accessibility tree when off-screen, since the browser will not render these styles until they enter the viewport. To prevent these from being visible in the accessibility tree, potentially causing clutter, be sure to also add aria-hidden="true".

Example: a travel blog #

In this example, we baseline our travel blog on the right, and apply content-visibility: auto to chunked areas on the left. The results show rendering times going from 232ms to 30ms on initial page load.

A travel blog typically contains a set of stories with a few pictures, and some descriptive text. Here is what happens in a typical browser when it navigates to a travel blog:

A part of the page is downloaded from the network, along with any needed resources.
The browser styles and lays out all of the contents of the page, without considering if the content is visible to the user.
The browser goes back to step 1 until all of the page and resources are downloaded.

In step 2, the browser processes all of the contents looking for things that may have changed. It updates the style and layout of any new elements, along with the elements that may have shifted as a result of new updates. This is rendering work. This takes time.

An example of a travel blog. See Demo on Codepen

Now consider what happens if you put content-visibility: auto on each of the individual stories in the blog. The general loop is the same: the browser downloads and renders chunks of the page. However, the difference is in the amount of work that it does in step 2.

With content-visibility, it will style and layout all of the contents that are currently visible to the user (they are on-screen). However, when processing the story that is fully off-screen, the browser will skip the rendering work and only style and layout the element box itself.

The performance of loading this page would be as if it contained full on-screen stories and empty boxes for each of the off-screen stories. This performs much better, with expected reduction of 50% or more from the rendering cost of loading. In our example, we see a boost from a 232ms rendering time to a 30ms rendering time. That's a 7x performance boost.

What is the work that you need to do in order to reap these benefits? First, we chunk the content into sections:

Example of chunking content into sections with the story class applied, to receive content-visibility: auto. See Demo on Codepen

Then, we apply the following style rule to the sections:

.story {
  content-visibility: auto;
  contain-intrinsic-size: 1000px; /* Explained in the next section. */
}

Specifying the natural size of an element with `contain-intrinsic-size` #

In order to realize the potential benefits of content-visibility, the browser needs to apply size containment to ensure that the rendering results of contents do not affect the size of the element in any way. This means that the element will lay out as if it was empty. If the element does not have a height specified in a regular block layout, then it will be of 0 height.

This might not be ideal, since the size of the scrollbar will shift, being reliant on each story having a non-zero height.

Thankfully, CSS provides another property, contain-intrinsic-size, which effectively specifies the natural size of the element if the element is affected by size containment. In our example, we are setting it to 1000px as an estimate for the height and width of the sections.

This means it will lay out as if it had a single child of "intrinsic-size" dimensions, ensuring that your unsized divs still occupy space. contain-intrinsic-size acts as a placeholder size in lieu of rendered content.

In Chromium 98 and onward, there is a new auto keyword for contain-intrinsic-size. When specified, the browser will remember the last-rendered size, if any, and use that instead of the developer-provided placeholder size. For example, if you specified contain-intrinsic-size: auto 300px, the element will start out with a 300px intrinsic sizing in each dimension, but once the element's contents are rendered, it will retain the rendered intrinsic size. Any subsequent rendering size changes will also be remembered. In practice, this means that if you scroll an element with content-visibility: auto applied, and then scroll it back offscreen, it will automatically retain its ideal width and height, and not revert to the placeholder sizing. This feature is especially useful for infinite scrollers, which can now automatically improve sizing estimation over time as the user explores the page.

Hiding content with `content-visibility: hidden` #

What if you want to keep the content unrendered regardless of whether or not it is on-screen, while leveraging the benefits of cached rendering state? Enter: content-visibility: hidden.

The content-visibility: hidden property gives you all of the same benefits of unrendered content and cached rendering state as content-visibility: auto does off-screen. However, unlike with auto, it does not automatically start to render on-screen.

This gives you more control, allowing you to hide an element's contents and later unhide them quickly.

Compare it to other common ways of hiding element's contents:

display: none: hides the element and destroys its rendering state. This means unhiding the element is as expensive as rendering a new element with the same contents.
visibility: hidden: hides the element and keeps its rendering state. This doesn't truly remove the element from the document, as it (and it's subtree) still takes up geometric space on the page and can still be clicked on. It also updates the rendering state any time it is needed even when hidden.

content-visibility: hidden, on the other hand, hides the element while preserving its rendering state, so, if there are any changes that need to happen, they only happen when the element is shown again (i.e. the content-visibility: hidden property is removed).

Some great use cases for content-visibility: hidden are when implementing advanced virtual scrollers, and measuring layout. They're also great for single-page applications (SPA's). Inactive app views can be left in the DOM with content-visibility: hidden applied to prevent their display but maintain their cached state. This makes the view quick to render when it becomes active again.

Effects on Interaction to Next Paint (INP) #

INP is a metric that evaluates a page's ability to be reliably responsive to user input. Responsiveness can be affected by any excessive amount of work that occurs on the main thread, including rendering work.

Whenever you can reduce rendering work on any given page, you're giving the main thread an opportunity to respond to user inputs more quickly. This includes rendering work, and using the content-visiblity CSS property where appropriate can reduce rendering work—especially during startup, when most rendering and layout work is done.

Reducing rendering work has a direct effect on INP. When users attempt to interact with a page that uses the content-visibility property properly to defer layout and rendering of offscreen elements, you're giving the main thread a chance to respond to critical user-visible work. This can improve your page's INP in some situations.

Conclusion #

content-visibility and the CSS Containment Spec mean some exciting performance boosts are coming right to your CSS file. For more information on these properties, check out:

@property: giving superpowers to CSS variables

2020-07-21T00:00:00Z

CSS Houdini is an umbrella term that covers a set of low-level APIs that expose parts of the CSS rendering engine, and give developers access to the CSS Object Model. This is a huge change for the CSS ecosystem, as it enables developers to tell the browser how to read and parse custom CSS without waiting for browser vendors to provide built-in support for these features. So exciting!

One of the most exciting additions to CSS within the Houdini umbrella is the Properties and Values API.

This API supercharges your CSS custom properties (also commonly referred to as CSS variables) by giving them semantic meaning (defined by a syntax) and even fallback values, enabling CSS testing.

Browser support

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

Writing Houdini custom properties #

Here's an example of setting a custom property (think: CSS variable), but now with a syntax (type), initial value (fallback), and inheritance boolean (does it inherit the value from it's parent or not?). The current way to do this is through CSS.registerProperty() in JavaScript, but in Chromium 85 and later, the @property syntax will be supported in your CSS files:

Separate JavaScript file (Chromium 78)

CSS.registerProperty({
  name: '--colorPrimary',
  syntax: '<color>',
  initialValue: 'magenta',
  inherits: false
});

Included in CSS file (Chromium 85)

@property --colorPrimary {
  syntax: '<color>';
  initial-value: magenta;
  inherits: false;
}

Now you can access --colorPrimary like any other CSS custom property, via var(--colorPrimary). However, the difference here is that --colorPrimary isn't just read as a string. It has data!

Fallback values #

As with any other custom property, you can get (using var) or set (write/rewrite) values, but with Houdini custom properties, if you set a falsey value when overriding it, the CSS rendering engine will send the initial value (its fallback value) instead of ignoring the line.

Consider the example below. The --colorPrimary variable has an initial-value of magenta. But the developer has given it the invalid value "23". Without @property, the CSS parser would ignore the invalid code. Now, the parser falls back to magenta. This allows for true fallbacks and testing within CSS. Neat!

.card {
  background-color: var(--colorPrimary); /* magenta */
}

.highlight-card {
  --colorPrimary: yellow;
  background-color: var(--colorPrimary); /* yellow */
}

.another-card {
  --colorPrimary: 23;
  background-color: var(--colorPrimary); /* magenta */
}

Syntax #

With the syntax feature, you can now write semantic CSS by specifying a type. The current types that are allowed include:

length
number
percentage
length-percentage
color
image
url
integer
angle
time
resolution
transform-list
transform-function
custom-ident (a custom identifier string)

Setting a syntax enables the browser to type-check custom properties. This has many benefits.

To illustrate this point, I'll show you how to animate a gradient. Currently, there is no way to smoothly animate (or interpolate) between gradient values, as each gradient declaration is parsed as a string.

Using a custom property with a "number" syntax, the gradient on the left shows a smooth transition between stop values. The gradient on the right uses a default custom property (no syntax defined) and shows an abrupt transition.

In this example, the gradient stop percentage is being animated from a starting value of 40% to an ending value of 100% via a hover interaction. You should see a smooth transition of that top gradient color downward.

The browser on the left supports the Houdini Properties and Values API, enabling a smooth gradient stop transition. The browser on the right does not. The non-supporting browser is only able to understand this change as a string going from point A to point B. There is no opportunity to interpolate the values, and thus you don't see that smooth transition.

However, if you declare syntax type when writing custom properties, and then use those custom properties to enable the animation, you'll see the transition. You can instantiate the custom property --gradPoint like so:

/* Check for Houdini support & register property */
@supports (background: paint(something)) {
  @property --gradPoint {
    syntax: '<percentage>';
    inherits: false;
    initial-value: 40%;
  }
}

And then when it comes time to animate it, you can update the value from the initial 40% to 100%:

@supports (background: paint(something)) {
  .post:hover,
  .post:focus {
    --gradPoint: 100%;
  }
}

This will now enable that smooth gradient transition.

Smoothly transitioning gradient borders. See Demo on Glitch

Conclusion #

The @property rule makes an exciting technology even more accessible by allowing you to write semantically meaningful CSS within CSS itself. To learn more about CSS Houdini and the Properties and Values API, check out these resources:

Photo by Cristian Escobar on Unsplash.

Ten modern layouts in one line of CSS

2020-07-07T00:00:00Z

Modern CSS layouts enable developers to write really meaningful and robust styling rules with just a few keystrokes. The talk above and this subsequent post examine 10 powerful lines of CSS that do some serious heavy lifting.

To follow along or play with these demos on your own, check out the Glitch embed above, or visit 1linelayouts.glitch.me.

01. Super Centered: `place-items: center` #

For the first 'single-line' layout, let's solve the biggest mystery in all of the CSS land: centering things. I want you to know that it's easier than you think with place-items: center.

First specify grid as the display method, and then write place-items: center on the same element. place-items is a shorthand to set both align-items and justify-items at once. By setting it to center, both align-items and justify-items are set to center.

.parent {
  display: grid;
  place-items: center;
}

This enables the content to be perfectly centered within the parent, regardless of intrinsic size.

02. The Deconstructed Pancake: `flex: <grow> <shrink> <baseWidth>` #

Next we have the deconstructed pancake! This is a common layout for marketing sites, for example, which may have a row of 3 items, usually with an image, title, and then some text, describing some features of a product. On mobile, we'll want those to stack nicely, and expand as we increase the screen size.

By using Flexbox for this effect, you won't need media queries to adjust the placement of these elements when the screen resizes.

The flex shorthand stands for: flex: <flex-grow> <flex-shrink> <flex-basis>.

Because of this, if you want your boxes to fill out to their <flex-basis> size, shrink on smaller sizes, but not stretch to fill any additional space, write: flex: 0 1 <flex-basis>. In this case, your <flex-basis> is 150px so it looks like:

.parent {
  display: flex;
}

.child {
  flex: 0 1 150px;
}

If you do want the boxes to stretch and fill the space as they wrap to the next line, set the <flex-grow> to 1, so it would look like:

.parent {
  display: flex;
}

.child {
  flex: 1 1 150px;
}

Now, as you increase or decrease the screen size, these flex items both shrink and grow.

03. Sidebar Says: `grid-template-columns: minmax(<min>, <max>) …)` #

This demo takes advantage of the minmax function for grid layouts. What we're doing here is setting the minimum sidebar size to be 150px, but on larger screens, letting that stretch out to 25%. The sidebar will always take up 25% of its parent's horizontal space until that 25% becomes smaller than 150px.

Add this as a value of grid-template-columns with the following value: minmax(150px, 25%) 1fr. The item in the first column (the sidebar in this case) gets a minmax of 150px at 25%, and the second item (the main section here) takes up the rest of the space as a single 1fr track.

.parent {
  display: grid;
  grid-template-columns: minmax(150px, 25%) 1fr;
}

04. Pancake Stack: `grid-template-rows: auto 1fr auto` #

Unlike the Deconstructed Pancake, this example does not wrap its children when the screen size changes. Commonly referred to as a sticky footer, this layout is often used for both websites and apps, across mobile applications (the footer is commonly a toolbar), and websites (single page applications often use this global layout).

Adding display: grid to the component will give you a single column grid, however the main area will only be as tall as the content with the footer below it.

To make the footer stick to the bottom, add:

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

This sets the header and footer content to automatically take the size of its children, and applies the remaining space (1fr) to the main area, while the auto sized row will take the size of the minimum content of its children, so as that content increases in size, the row itself will grow to adjust.

05. Classic Holy Grail Layout: `grid-template: auto 1fr auto / auto 1fr auto` #

For this classic holy grail layout, there is a header, footer, left sidebar, right sidebar, and main content. It's similar to the previous layout, but now with sidebars!

To write this entire grid using a single line of code, use the grid-template property. This enables you to set both the rows and columns at the same time.

The property and value pair is: grid-template: auto 1fr auto / auto 1fr auto. The slash in between the first and second space-separated lists is the break between rows and columns.

.parent {
  display: grid;
  grid-template: auto 1fr auto / auto 1fr auto;
}

As in the last example, where the header and footer had auto-sized content, here the left and right sidebar are automatically sized based on their children's intrinsic size. However, this time it is horizontal size (width) instead of vertical (height).

06. 12-Span Grid: `grid-template-columns: repeat(12, 1fr)` #

Next we have another classic: the 12-span grid. You can quickly write grids in CSS with the repeat() function. Using: repeat(12, 1fr); for the grid template columns gives you 12 columns each of 1fr.

.parent {
  display: grid;
  grid-template-columns: repeat(12, 1fr);
}

.child-span-12 {
  grid-column: 1 / 13;
}

Now you have a 12 column track grid, we can place our children on the grid. One way to do this would be to place them using grid lines. For example, grid-column: 1 / 13 would span all the way from the first line to the last (13th) and span 12 columns. grid-column: 1 / 5; would span the first four.

Another way to write this is by using the span keyword. With span, you set the starting line and then how many columns to span into from that starting point. In this case, grid-column: 1 / span 12 would be equivalent to grid-column: 1 / 13, and grid-column: 2 / span 6 would be equivalent to grid-column: 2 / 8.

.child-span-12 {
  grid-column: 1 / span 12;
}

07. RAM (Repeat, Auto, MinMax): `grid-template-columns(auto-fit, minmax(<base>, 1fr))` #

For this seventh example, combine some of the concepts you've already learned about to create a responsive layout with automatically-placed and flexible children. Pretty neat. The key terms to remember here are repeat, auto-(fit|fill), and minmax()', which you remember by the acronym RAM.

All together, it looks like:

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

You are using repeat again, but this time, using the auto-fit keyword instead of an explicit numeric value. This enables auto-placement of these child elements. These children also have a base minimum value of 150px with a maximum value 1fr, meaning on smaller screens, they will take up the full 1fr width, and as they reach 150px wide each, they will start to flow onto the same line.

With auto-fit, the boxes will stretch as their horizontal size exceeds 150px to fill the entire remaining space. However, if you change this to auto-fill, they will not stretch when their base size in the minmax function is exceeded:

.parent {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(150px, 1fr));
}

08. Line Up: `justify-content: space-between` #

For the next layout, the main point to demonstrate here is justify-content: space-between, which places the first and last child elements at the edges of their bounding box, with the remaining space evenly distributed between the elements. For these cards, they are placed in a Flexbox display mode, with the direction being set to column using flex-direction: column.

This places the title, description, and image block in a vertical column inside of the parent card. Then, applying justify-content: space-between anchors the first (title) and last (image block) elements to the edges of the flexbox, and the descriptive text in between those gets placed with equal spacing to each endpoint.

.parent {
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}

09. Clamping My Style: `clamp(<min>, <actual>, <max>)` #

Here's where we get into some techniques with less browser support, but have some really exciting implications for layouts and responsive UI design. In this demo, you are setting the width using clamp like so: width: clamp(<min>, <actual>, <max>).

This sets an absolute min and max size, and an actual size. With values, that can look like:

.parent {
  width: clamp(23ch, 60%, 46ch);
}

The minimum size here is 23ch or 23 character units, and the maximum size is 46ch, 46 characters. Character width units are based on the font size of the element (specifically the width of the 0 glyph). The 'actual' size is 50%, which represents 50% of this element's parent width.

What the clamp() function is doing here is enabling this element to retain a 50% width until 50% is either greater than 46ch (on wider viewports), or smaller than 23ch (on smaller viewports). You can see that as I stretch and shrink the parent size, the width of this card increases to its clamped maximum point and decreases to its clamped minimum. It then stays centered in the parent since we've applied additional properties to center it. This enables more legible layouts, as the text won't be too wide (above 46ch) or too squished and narrow (less than 23ch).

This is also a great way to implement responsive typography. For example, you could write: font-size: clamp(1.5rem, 20vw, 3rem). In this case, the font-size of a headline would always stay clamped between 1.5rem and 3rem but would grow and shrink based on the 20vw actual value to fit the width of of the viewport.

This is a great technique to ensure legibility with a minimum and maximum size value, but remember it is not supported in all modern browsers so make sure you have fallbacks and do your testing.

10. Respect for Aspect: `aspect-ratio: <width> / <height>` #

And finally, this last layout tool is the most experimental of the bunch. It was recently introduced to Chrome Canary in Chromium 84, and there is active effort from Firefox in getting this implemented, but it is not currently in any stable browser editions.

I do want to mention this, though, because it is such a frequently met problem. And that is just simply maintaining the aspect ratio of an image.

With the aspect-ratio property, as I resize the card, the green visual block maintains this 16 x 9 aspect ratio. We are Respecting the Aspect Ratio with aspect-ratio: 16 / 9.

.video {
  aspect-ratio: 16 / 9;
}

To maintain a 16 x 9 aspect ratio without this property, you'd need to use a padding-top hack and give it a padding of 56.25% to set a top-to-width ratio. We will soon have a property for this to avoid the hack and the need to calculate the percentage. You can make a square with 1 / 1 ratio, a 2 to 1 ratio with 2 / 1, and really just anything you need for this image to scale with a set size ratio.

.square {
  aspect-ratio: 1 / 1;
}

While this feature is still up and coming, it it a good one to know about as it resolves a lot of developer strife that I have faced many times myself, especially when it comes to video and iframes.

Conclusion #

Thank you for following this journey through 10 powerful lines of CSS. To learn more, watch the full video, and try out the demos yourself.

Web Animations API improvements in Chromium 84

2020-05-27T00:00:00Z

When used correctly, animations improve user perception and memory of your brand, guide user actions, and help users navigate your application—providing context in a digital space.

The Web Animations API is a tool that enables developers to write imperative animations with JavaScript. It was written to underpin both CSS animation and transition implementations and enable future effects to be developed, as well as existing effects to be composed and timed.

While Firefox and Safari have already implemented the full set of spec features, Chromium 84 brings a slew of previously unsupported features to Chrome and Edge enabling cross-browser interoperability.

The long history of the Web Animations API in Chromium.

Getting started #

Creating an animation via the Web Animations API should feel very familiar if you've used @keyframe rules. First you'll need to create a Keyframe Object. What might look like this in CSS:

@keyframes openAnimation {
  0% {
    transform: scale(0);
  }
  100% {
    transform: scale(1);
  }
}

would look like this in JavaScript:

const openAnimation = [
  { transform: 'scale(0)' },
  { transform: 'scale(1)' },
];

Where you set parameters for animation in CSS:

.modal {
  animation: openAnimation 1s 1 ease-in;
}

you would set in JS:

document.querySelector('.modal').animate(
    openAnimation, {
      duration: 1000, // 1s
      iterations: 1, // single iteration
      easing: 'ease-in' // easing function
    }
);

The amount of code is about the same, but with JavaScript, you get a couple of superpowers that you don't have with CSS alone. This includes the ability to sequence effects, and an increased control of their play states.

Beyond `element.animate()` #

However, with the update, the Web Animations API is no longer restricted to animations created via element.animate(). We can manipulate CSS animations and transitions as well.

getAnimations() is a method that returns all animations on an element regardless of whether it was created via element.animate() or via CSS rules (CSS animation or transition). Here is an example of what this looks like:

You first "get" the keyframes for the transition to determine where we are transitioning from. Then, you create two new opacity animations, enabling the cross fade effect. Once the cross-fade completes, you delete the copy.

Orchestrating animations with promises #

In Chromium 84, you now have two methods that can be used with promises: animation.ready and animation.finished.

animation.ready enables you to wait for pending changes to take effect (i.e. switching between playback control methods such as play and pause).
animation.finished provides a means of executing custom JavaScript code when an animation is complete.

Let's continue with our example, and create an orchestrated animation chain with animation.finished. Here, you have a vertical transformation (scaleY), followed by a horizontal transformation (scaleX), followed by an opacity change on a child element:

Applying transformations and opacity to an opening modal element. See Demo on Codepen

const transformAnimation = modal.animate(openModal, openModalSettings);
transformAnimation.finished.then(() => { text.animate(fadeIn, fadeInSettings)});

We've chained these animations using animation.finished.then() prior to executing the next animation set in the chain. This way, the animations appear in order, and you are even applying effects to different target elements with different options set (such as speed and ease).

Within CSS, this would be cumbersome to recreate, especially when applying unique, yet sequenced animations to multiple elements. You'd have to use a @keyframe, sort out the correct timing percentages to place the animations, and use animation-delay prior to triggering the animations in the sequence.

Example: Play, pause, and reverse #

What can open, should close! Luckily, since Chromium 39, the Web Animations API has provided us the ability to play, pause, and reverse our animations.

You can take the above animation, and give it a smooth, reversed animation when clicking the button again using .reverse(). This way, you can create a smoother and more contextual interaction for our modal.

An example of a modal opening and closing upon button click. See Demo on Glitch

What you can do is create two play-pending animations (openModal, and an inline opacity transformation), and then pause one of the animations, delaying it until the other is finished. You can then use promises to wait for each to be finished before playing. Finally, you can check to see if a flag is set, and then reverse each animation.

Example: Dynamic interactions with partial keyframes #

Retargeting example, where a mouse click adjusts the animation to a new location. See Demo on Glitch

selector.animate([{transform: `translate(${x}px, ${y}px)`}],
    {duration: 1000, fill: 'forwards'});

In this example, there is only one keyframe, and no specified start position. This is an example of using partial keyframes. The mouse handler does a few things here: it sets a new end location and triggers a new animation. The new start position is inferred from the current underlying position.

New transitions can be triggered while existing ones are still running. This means that the current transition is interrupted, and a new one is created.

Performance improvements with replaceable animations #

When creating animations based on events, such as on 'mousemove', a new animation is created each time, which can quickly consume memory and degrade performance. To address this problem, replaceable animations were introduced in Chromium 83, enabling automated cleanup, where finished animations are flagged as replaceable and automatically removed if replaced by another finished animation. Consider the following example:

A comet trail animates when the mouse moves. See Demo on Glitch

elem.addEventListener('mousemove', evt => {
 rectangle.animate(
   { transform: translate(${evt.clientX}px, ${evt.clientY}px) },
   { duration: 500, fill: 'forwards' }
 );
});

Each time the mouse moves, the browser re-calculates the position for each ball in the comet trail and creates an animation to this new point. The browser now knows to remove old animations (enabling replacement) when:

The animation is finished.
There is one or more animations higher in composite ordering that are also finished.
The new animations are animating the same properties.

You can see exactly how many animations are being replaced by tallying up a counter with each removed animation, using anim.onremove to trigger the counter.

There are a few additional methods to take your animation control even further:

animation.replaceState() provides a means of tracking whether an animation is active, persisted, or removed.
animation.commitStyles() updates the style of an element based on the underlying style along with all animations on the element in the composite order.
animation.persist() marks an animation as non-replaceable.

Smoother animations with composite modes #

With the Web Animations API, you can now set the composite mode of your animations, meaning they can be additive or accumulative, in addition to the default mode of "replace". Composite modes allow developers to write distinct animations and have control over how effects are combined. Three composite modes are now supported: 'replace' (the default mode), 'add', and 'accumulate'.

When you composite animations, a developer can write short, distinct effects and see them combined together. In the example below, we are applying a rotation and scale keyframe to each box, with the only adjustment being the composite mode, added as an option:

A demo showing the default, add, and accumulate composite modes. See Demo on Glitch

In the default 'replace' composite mode, the final animation replaces the transform property and ends up at rotate(360deg) scale(1.4). For 'add', composite adds the rotation and multiplies the scale, resulting in a final state of rotate(720deg) scale(1.96). 'accumulate' combines the transformations, resulting in rotate(720deg) scale(1.8). For more on the intricacies of these composite modes, check out The CompositeOperation and CompositeOperationOrAuto enumerations from the Web Animations spec.

Let's take a look at a UI element example:

A bouncy dropdown menu which has two composited animations applied to it. See Demo on Glitch

Here, two top animations are composited. The first is a macro-animation, which moves the dropdown by the full height of the menu itself as a slide-in effect from the top of the page, and the second, a micro-animation, applies a little bounce as it hits the bottom. Using the 'add' composite mode enables a smoother transition.

const dropDown = menu.animate(
    [
      { top: `${-menuHeight}px`, easing: 'ease-in' },
      { top: 0 }
    ], { duration: 300, fill: 'forwards' });

  dropDown.finished.then(() => {
    const bounce = menu.animate(
      [
        { top: '0px', easing: 'ease-in' },
        { top: '10px', easing: 'ease-out' },
        { ... }
      ], { duration: 300, composite: 'add' });
  });

What's next for the Web Animations API #

These are all exciting additions to animations capabilities in today's browsers, and even more additions are coming down the pipeline. Check out these future specifications for some further reading on what's coming next:

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

Una Kravets on web.dev

Container queries land in stable browsers

Using container queries #

A container query Valentine #

Building Designcember

Overview #

Starting with whimsy #

Window animation with spritesheets #

CSS masking #

Squooshing the art #

Screen reader and keyboard users #

Astro, static first, component-driven site generator #

Days as components #

Scoped styles and Open Props #

Flexible containers #

Cross-browser support #

Dark mode #

Other Easter eggs #

Personal touches #

Functional touches #

State of CSS 2021

Feature usage and awareness

Browser compatibility

What's missing in CSS?

Learn more

CSS for Web Vitals

Layout #

Inserting content into the DOM #

Identify #

Fix #

Images #

Images and Largest Contentful Paint (LCP) #

Fix #

Images and layout shifts #

Identify #

Fix #

Fonts #

Delayed text rendering #

Layout shifts #

Identify #

Fix #

Animations #

Identify #

Fix #

Critical CSS #

Conclusion #

The new responsive: Web design in a component-driven world

Responsive Design Today #

Responsive to the user #

prefers-reduced-motion #

prefers-color-scheme #

Designing for dark theme #

Responsive to the container #

Container query cards #

Mixing Container Queries with Media Queries #

Using container queries today #

Scoped styles #

Responsive to the form factor #

Conclusion #

web.dev/learnCSS #

New aspect-ratio CSS property supported in Chromium, Safari Technology Preview, and Firefox Nightly

Aspect ratio #

Object-fit #

The old hack: maintaining aspect ratio with padding-top #

Maintaining aspect ratio with aspect-ratio #

Example: consistency in a grid #

Example: preventing layout shift #

Bonus tip: image attributes for aspect ratio #

Conclusion #

Cross-browser paint worklets and Houdini.how

Understanding Houdini worklets #

Implementing your own features with the CSS Painting API #

Houdini.how #

Using Houdini #

1. Prototyping with a CDN #

2. Managing worklets via NPM #

Contribute #

min(), max(), and clamp(): three logical CSS functions to use today

Background #

Browser support #

`prefers-reduced-motion` #

`prefers-color-scheme` #

The old hack: maintaining aspect ratio with `padding-top` #

Maintaining aspect ratio with `aspect-ratio` #

`min()` #

`max()` #

`clamp()` #

Skipping rendering work with `content-visibility` #

Specifying the natural size of an element with `contain-intrinsic-size` #

Hiding content with `content-visibility: hidden` #

01. Super Centered: `place-items: center` #

02. The Deconstructed Pancake: `flex: <grow> <shrink> <baseWidth>` #

03. Sidebar Says: `grid-template-columns: minmax(<min>, <max>) …)` #

04. Pancake Stack: `grid-template-rows: auto 1fr auto` #

05. Classic Holy Grail Layout: `grid-template: auto 1fr auto / auto 1fr auto` #

06. 12-Span Grid: `grid-template-columns: repeat(12, 1fr)` #

07. RAM (Repeat, Auto, MinMax): `grid-template-columns(auto-fit, minmax(<base>, 1fr))` #

08. Line Up: `justify-content: space-between` #

09. Clamping My Style: `clamp(<min>, <actual>, <max>)` #

10. Respect for Aspect: `aspect-ratio: <width> / <height>` #

Beyond `element.animate()` #

`:focus-within` #

`position: sticky` #

`backdrop-filter` #

`:is()` #

`gap` #