Rachel Andrew on web.dev

New to the web platform in September

2023-10-02T00:00:00Z

Stable browser releases #

In September 2023 Firefox 118, Safari 17, and Chrome 117 became stable. This post takes a look at what that means for the web platform.

The subgrid value for grid-template-columns and grid-template-rows is included in Chrome 117, making this longed for feature interoperable. You can learn more about subgrid in the article CSS subgrid.

Browser support

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

Source

Chrome also includes three new CSS features to easily add entry and exit animations, and smoothly animate to and from the top layer dismissible elements such as dialogs and popovers. You can learn about the transition-behavior property, @starting-style rule, and overlay property in the article Four new CSS features for entry and exit animations.

Browser support

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

Also in Chrome 117 is JavaScript array grouping with the Object.groupBy and Map.groupBy static methods.

Browser support

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

Safari 17 includes the popover attribute, to add support for the Popover API.

Browser support

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

Safari 17 and Firefox 118 include the HTML <search> element. This element represents the parts of the page or application that contain funtionality for search or filtering content.

Browser support

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

Source

There are lots of new CSS features included in Safari 17, including @counter-style. This rule lets you define counter styles that are outside the predefined list of style. This feature is now available in all three engines.

Browser support

Chrome 91, Supported 91
Firefox 33, Supported 33
Edge 91, Supported 91
Safari 17, Supported 17

Source

Firefox 118 includes several additional CSS math functions: abs(), sign(), round(), mod(), rem(), pow(), sqrt(), hypot(), log(), and exp().

Browser support

Chrome, Not supported
Firefox 112, Supported 112
Edge, Not supported
Safari 15.4, Supported 15.4

Source

Safari 17 also includes support for HEIC/HEIF images, and JPEG XL.

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 119, Safari 17.1, and Chrome 118. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

The <search> element, shipping in Firefox and Safari this month is included in Chrome 118, meaning this feature is quickly landing across all three engines.

The Object.groupBy and Map.groupBy static methods are part of Firefox 119.

Chrome 118 includes CSS scoped styles with the @scope rule and new media features with prefers-reduced-transparency and scripting.

Safari 17.1 is currently a release that fixes a range of issues across the platform.

Photo by Charles Deluvio.

Submit your proposals for Interop 2024

2023-09-14T00:00:00Z

Over the past two years the Chrome team has successfully worked with our partners to improve the interoperability of the web. For Interop 2022 all major browser vendors and other stakeholders worked together to improve top browser compatibility issues identified by web developers. We repeated the process with Interop 2023, which still has a few months to run yet is already seeing a huge improvement in scores. For Interop 2023, we also requested public proposals for features to include, which led to many great suggestions representing the needs of the wider web ecosystem.

January 2023.

September 2023.

It's been a huge success, with many features reaching interoperability, and we're happy to announce that Interop 2024 is happening.

The first step is to gather suggested features, once again including ideas from the wider community, so the Interop 2024 proposal process is now open for submissions. Suggestions can include features that behave differently across browsers, or features that are not yet implemented in all browsers. Keep in mind that proposals with high quality specifications and web platform tests are more likely to be included, as this project is about reaching interoperability rather than specifying new features. The proposal submission process ends October 5, 2023.

Once the proposal period ends, the collected submissions will be discussed by browser vendors and other partners to determine the final list. It's likely that there will be more proposals than can be achieved during 2024, so some high quality proposals may not be selected. We are looking forward to reviewing all the submissions, and we'll post the final list here once Interop 2024 gets underway.

Submit your proposals here.

New to the web platform in August

2023-08-31T00:00:00Z

Stable browser releases #

In August 2023 Firefox 116, Firefox 117, Safari 16.6, and Chrome 116 became stable. This post takes a look at what that means for the web platform.

Firefox 116 supports the Audio Output Devices API on all platforms except for Android. This API allows web applications to redirect audio output to a permitted Bluetooth headset, speakerphone, or other device, instead of having to use the browser or underlying OS default.

Browser support

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

Source

Chrome 116 includes CSS Motion Path allowing any graphical object to be animated it along a path specified by the developer. This allows a number of powerful new transform possibilities, such as positioning using polar coordinates (with the ray() function) rather than the standard rectangular coordinates used by the translate() function, or animating an element along a defined path. This makes it easier to define complex and beautiful 2d spatial transitions. A path can be specified as circle(), ellipse(), rect(), inset(), xywh(), polygon(), ray() and url().

Browser support

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

Also in Chrome 116 is the Document Picture-in-Picture API. This enables an always-on-top window that can be populated with arbitrary HTMLElements. This is an expansion upon the existing HTMLVideoElement API that only allows for an HTMLVideoElement to be put into a Picture-in-Picture (PiP) window.

Browser support

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

Firefox 117 supports CSS Nesting and the & nesting selector. This enables the nesting of one style rule inside another. This makes CSS Nesting interoperable with a caveat, Safari and Chrome implemented an older version of the spec, which did not allow nesting of type selectors. Firefox has implemented the new version of the spec which does not require the & nesting selector. You can see examples of both versions in Using CSS Nesting.

Browser support

Chrome 112, Supported 112
Firefox, Not supported
Edge 112, Supported 112
Safari 16.5, Supported 16.5

Source

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 118 and Chrome 117. The Safari 17 beta is still ongoing. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

There's not a lot of information available as yet for the next Firefox release. However, Chrome 117 promises some exciting features. For example, some new CSS features that enable entry and exit animations.

The subgrid value for grid-template-columns and grid-template-rows is included in Chrome 117, making this longed for feature interoperable.

Also in Chrome 117 is JavaScript array grouping with the Object.groupBy and Map.groupBy static methods.

Safari 17 beta includes the popover attribute, to add support for the Popover API.

Photo by Courtney Cook.

New to the web platform in July

2023-07-31T00:00:00Z

Stable browser releases #

In July 2023 Firefox 115 and Chrome 115 became stable. This post takes a look at what that means for the web platform.

Multiple values for the CSS `display` property #

Chrome 115 includes multiple values for the CSS display property. This means that display: flex becomes display: block flex and display: block becomes display: block flow. The single values are maintained as legacy keywords, these values are now available in the three major engines.

Browser support

Chrome 115, Supported 115
Firefox 70, Supported 70
Edge 115, Supported 115
Safari 15, Supported 15

Scroll-driven animations #

Also in Chrome 115 are the ScrollTimeline and ViewTimeline extensions to the Web Animations specification. These enable scroll-driven animations via CSS and JavaScript.

Browser support

Chrome 115, Supported 115
Firefox, Not supported
Edge 115, Supported 115
Safari, Not supported

Source

Privacy Sandbox APIs #

The Privacy Sandbox relevance and measurement APIs shipped in Chrome 115. This includes the Topics, Protected Audience, Attribution Reporting, Private Aggregation, Shared Storage, and Fenced Frames APIs.

To understand more about these APIs check out the Privacy Sandbox demos.

The `animation-composition` property #

Firefox 115 supports the CSS animation-composition property. Making animation-composition supported in all three major engines. Learn more in the article Specify how multiple animation effects should composite with animation-composition.

Browser support

Chrome 112, Supported 112
Firefox 115, Supported 115
Edge 112, Supported 112
Safari 16, Supported 16

Source

Array methods #

Also reaching interoperability with Firefox 115 are a set of methods for Array and TypedArray. Array.toReversed(), Array.toSorted(), Array.toSpliced(), Array.with(), TypedArrays.toReversed(), TypedArrays.toSorted(), and TypedArrays.with() return a new array with elements that have been shallow copied.

Browser support

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

Source

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 116 and Chrome 116. The Safari 17 and Safari 16.6 betas are still ongoing. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

Photo by Jason Leung.

New to the web platform in June

2023-06-30T00:00:00Z

Stable browser releases #

In June 2023 Firefox 114 became stable, so it's a single browser issue this month. Check out the beta browser releases section for details of several features that are about to become interoperable once those betas become stable.

WebTransport API #

Firefox 114 includes the WebTransport API, a modern update to WebSockets providing support for multiple streams, unidirectional streams, and out-of-order delivery.

Browser support

Chrome 97, Supported 97
Firefox 114, Supported 114
Edge 97, Supported 97
Safari, Not supported

Source

The SVG `crossorigin` attribute #

Firefox 114 also includes the crossorigin attribute, on the <image> and <feImage> elements in SVG, provides support for configuration of the Cross-Origin Resource Sharing (CORS) requests for the element's fetched data. This works in the same way as the HTML crossorigin attribute.

Browser support

Chrome, Not supported
Firefox 114, Supported 114
Edge, Not supported
Safari, Not supported

Source

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 115, and Safari 17 with Chrome 115 and Safari 16.6 still ongoing. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

Firefox 115 supports the CSS animation-composition property. Once this version of Firefox becomes stable on July 4th, animation-composition will be supported in all three major engines. Learn more in the article Specify how multiple animation effects should composite with animation-composition.

There is a whole stack of new features and fixes in the Safari 17 beta. Safari 17 adds Web Apps to macOS Sonoma. This means you can add a website to the Dock from the File menu or Share Sheet, and it will open in its own window.

Safari 17 also brings some features to interoperable status—contain-intrinsic-size, @counter-style, @font-face size-adjust, and the overflow-block and overflow-inline media features will be available in all major engines when Safari 17 ships.

Photo by Rodrigo Abreu.

New CSS color spaces and functions in all major engines

2023-06-02T00:00:00Z

CSS now supports color spaces that allow us to access colors outside of the sRGB gamut. This means that you can support HD (high definition) displays, using colors from HD gamuts. This support comes with new functions to make better use of color on the web.

Accessing color spaces from CSS #

We already have a number of functions that allow us to access colors within the sRGB gamut—rgb(), hsl(), and hwb(). Now supported in browsers is the color() function, a normalized way to access colors within any RGB color space. This includes sRGB, Display P3, and Rec2020. You can see some examples in the following CSS:

.valid-css-color-function-colors {
  --srgb: color(srgb 1 1 1);
  --srgb-linear: color(srgb-linear 100% 100% 100% / 50%);
  --display-p3: color(display-p3 1 1 1);
  --rec2020: color(rec2020 0 0 0);
  --a98-rgb: color(a98-rgb 1 1 1 / 25%);
  --prophoto: color(prophoto-rgb 0% 0% 0%);
  --xyz: color(xyz 1 1 1);
}

Browser support

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

Source

Also supported are several functions allowing access to color spaces other than sRGB using lch(), lab(), oklch(), and oklab().

Browser support

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

Source

You can learn about all of these different color spaces in the High definition CSS color guide.

The `color-mix()` function #

As well as these new color spaces, all engines now support the color-mix() function. This function enables mixing of one color into another, in any of the color spaces. In the following CSS, 25% of blue is mixed into white, in the srgb color space.

.example {
  background-color: color-mix(in srgb, blue 25%, white);
}

Browser support

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

Source

Learn more about color-mix()

These new functions and color spaces promise to bring vibrant HD color to the web. For inspiration, make a start by creating some beautiful gradients using the HD gradient generator at gradient.style.

Hero image by Daniele Levis Pelusi

New to the web platform in May

2023-05-31T00:00:00Z

Stable browser releases #

In May 2023, Firefox 113, Chrome 113, Chrome 114, and Safari 16.5 became stable. Let's take a look at what this means for the web platform.

WebGPU #

Chrome 113 includes WebGPU, the successor to the WebGL and WebGL 2 graphics APIs for the web. It provides modern features such as GPU compute, lower overhead access to GPU hardware, the ability to render to multiple canvases from a single graphics device, and better, more predictable performance.

Browser support

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

Source

First-Party Sets #

First-Party Sets (FPS) is part of the Privacy Sandbox. It is a way for organizations to declare relationships among sites, so that browsers can decide when to allow limited third-party cookie access for sites within a set. FPS began a staged rollout in Chrome 113.

CSS media features and more #

For CSS, Chrome 113 includes the overflow-inline and overflow-block media features.

Browser support

Chrome 113, Supported 113
Firefox 66, Supported 66
Edge 113, Supported 113
Safari, Not supported

Source

And the update media feature.

Browser support

Chrome 113, Supported 113
Firefox 102, Supported 102
Edge 113, Supported 113
Safari, Not supported

Source

Also included is the linear() easing function, which you can learn more about in the article Create complex animation curves in CSS with the linear() easing function.

Browser support

Chrome 113, Supported 113
Firefox 112, Supported 112
Edge 113, Supported 113
Safari, Not supported

CSS Color Level 4 features #

Firefox 113 includes the color(), lab(), lch(), oklab(), oklch(), and color-mix() functional notations, along with the forced-color-adjust property. This means that the new color spaces and functions are now supported across all three major engines. You can learn more about these color spaces and functions in the High definition CSS color guide.

Browser support

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

Source

More control over `:nth-child()` selections #

Firefox 113 also adds the ability to pass a selector list into :nth-child() and nth-last-child(). Learn more about this, and see examples in the post More control over :nth-child() selections with the of S syntax.

Browser support

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

Compressions Streams API #

Now supported in all three major engines due to inclusion in Firefox 113, the Compressions Streams API enables the compression and decompression of streams. This means that JavaScript applications no longer need to bundle a compression library.

Browser support

Chrome 80, Supported 80
Firefox 113, Supported 113
Edge 80, Supported 80
Safari 16.4, Supported 16.4

Source

CSS nesting #

Safari 16.5 mostly resolved issues, but also adds support for CSS Nesting, with the new nesting selector >, used to nest related style rules, in a way that will be familiar to developers who have used pre-processors:

.nesting {
  color: hotpink;

  > .is {
    color: rebeccapurple;

    > .awesome {
      color: deeppink;
    }
  }
}

Browser support

Chrome 112, Supported 112
Firefox, Not supported
Edge 112, Supported 112
Safari 16.5, Supported 16.5

Source

Balancing headlines with `text-wrap: balance` #

From Chrome 114 you can use text-wrap: balance. This allows you to balance headlines, avoiding the issue of having a single word on the final line, providing a more pleasing and readable result. You can find out more in CSS text-wrap: balance.

Browser support

Chrome 114, Supported 114
Firefox, Not supported
Edge 114, Supported 114
Safari, Not supported

Source

CHIPS: Cookies Having Independent Partitioned State #

As part of the work to phase out third-party cookies, CHIPS enables opting-in to third-party cookies being partitioned by top-level site using the new cookie attribute Partitioned. CHIPS is available in Chrome 114.

Also in Chrome 114 is the Popover API making it easier to build transient user interface (UI) elements that are displayed on top of all other web app UI.

These include user-interactive elements like action menus, form element suggestions, content pickers, and teaching UI.

The new popover attribute enables any element to be displayed in the top layer automatically. This means no more worrying about positioning, stacking elements, focus or keyboard interactions for the developer.

Learn more in Introducing the popover API.

Browser support

Chrome 114, Supported 114
Firefox 114, Behind a flag
Edge 114, Supported 114
Safari 17, Supported 17

Source

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 114, Chrome 115, and Safari 16.6. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

Chrome 115 includes multiple values for the CSS display property. This means that display: flex becomes display: block flex and display: block becomes display: block flow. The single values are maintained as legacy keywords, and once in Chrome Stable this makes the multiple values available accross all engines.

Also in Chrome 115 are the ScrollTimeline and ViewTimeline extensions to the Web Animations specification. These enable scroll-driven animations via CSS and JavaScript.

Firefox 114 includes the WebTransport API, a modern update to WebSockets providing support for multiple streams, unidirectional streams, and out-of-order delivery.

Photo by Photoz ace.

Introducing Baseline

2023-05-10T00:00:00Z

Baseline helps you to see, at a glance, whether a feature or API is safe to use in your site or web applications. In this post, learn about the ideas that led to this concept, and how we hope it will help you.

Keeping up with changes to the web platform #

The web of today changes rapidly. Our browsers are evergreen, with new features landing in stable browsers each month. This is exciting, however it also poses problems. How do web developers keep up with all of this change? How do you know when it's safe to use a feature? When is it the right time to start to learn, and to invest in new features?

In the past, we often explained browser support to stakeholders by tying it to a certain browser release (for example, Internet Explorer 11) because the line in the sand a non-evergreen browser created was clear to everyone. Today, the landscape can often seem less clear, with so many features landing it's a lot of work to check support for everything we use.

We know how much of a problem this is to developers, because you have consistently told us that it's a problem. Over two years ago we decided it was a problem we wanted to try to address.

Getting our own house in order #

We recognized that we were adding to confusion about the status of features, mixing experimental things in with stable content on our sites. So, we've improved the clarity of our own communication channels. We now use web.dev to publish content about the stable web, those things that we can now describe as part of Baseline, and those that are very close to that status. We also highlight the work of other browsers, as we all work together to improve the interoperability of the platform.

On web.dev you'll find content such as the newly interoperable series, celebrating features that are now supported in all three major engines. We also have our monthly series, covering what's new to the web platform sharing the work of all browsers, and updates about Interop 2023. This site is also home to our best practices guidance in subjects such as performance, accessibility, and fundamental web development skills.

On developer.chrome.com you can learn about the new things that Chrome is bringing to the web platform. Some of these things are experimental, or only in Chrome right now. Many of the things we post about on developer.chrome.com are coming to other browsers, and we hope to celebrate their interoperable moments very soon, but we want you to have clarity about their status and browser support.

We have also been adding clear browser support information to everything that we publish, and when our team talks about features at conferences.

Documentation is really important for adoption of new features, and this year we've made sure that the new features we are landing in Chrome have documentation over on MDN. For example, take a look at the documentation for View Transitions and WebGPU. We also help support Open Web Docs who contribute documentation for the entire web platform to MDN.

Working with others #

Improving what we do was important, however to address the bigger issue we needed to work with others. We've been successfully working with our partners at other browser vendors and related companies through Interop 2022 and 2023. Forming the WebDX Community Group brought everyone together to think about this issue of clarity across the platform as a whole.

The group is working together on a feature set, a way to group web platform features to show their support status, and this feature-set is key to the concept of Baseline.

Creating platform-wide clarity with Baseline #

Baseline is the line in the sand that is hard to identify in a world of evergreen browsers. Everything that is fully supported in the most recent two versions of major browsers will be part of Baseline. Therefore if your library states that all features used are part of Baseline, developers know what you mean. When creating a proposal for a new application, you can explain to stakeholders that browser support will be tied to Baseline, thus creating clarity for everyone as to levels of support.

From today you will start to see Baseline appearing on pages on MDN, and on web.dev.

As Baseline will be a continuously moving line, with new features becoming part of that set each month, every year we will publish a cut of features that are part of Baseline at one moment in time. For extra clarity, you can tie support to Baseline 24, for example.

What's next? #

We'll be continuing the rollout of Baseline across web.dev. When reading an article or tutorial, you'll be able to see when the features described are part of Baseline. You won't get part of the way through something and realize it uses something that doesn't have good browser support.

We'll be providing widgets that you can use on your own articles or libraries, indicating support for the Baseline feature set.

We'll also be working to ensure that new features we are landing in Chrome become part of Baseline as quickly as possible. Watch out for future posts where we'll talk more about that work.

And we'll be gathering feedback from developers to find out how this idea is working in practice, and what more you would like to see. Keep an eye on the Baseline page, or offer feedback right now via the WebDX Community Group.

New to the web platform in April

2023-04-28T00:00:00Z

Stable browser releases #

In April 2023, Firefox 112, and Chrome 112 became stable. Let's take a look at what this means for the web platform.

The `inert` attribute #

Firefox 112 includes the inert global attribute. This attribute tells the browser to ignore the element, indicating content that should not be interactive. It:

Prevents click events being fired.
Prevents the element from gaining focus.
Excludes the element and its contents from the accessibility tree.

This attribute is now interoperable in all three engines.

Browser support

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

Source

The `linear()` easing function #

The linear() easing function enables linear interpolation between a number of points. This enables more complex animations such as bounce and elastic effects. This function is in Firefox 112.

Browser support

Chrome 113, Supported 113
Firefox 112, Supported 112
Edge 113, Supported 113
Safari, Not supported

CSS nesting #

Chrome 112 adds support for CSS Nesting, a feature that is highly anticipated by many developers. This introduces a new nesting selector >, used to nest related style rules, in a way that will be familiar to developers who have used pre-processors:

.nesting {
  color: hotpink;

  > .is {
    color: rebeccapurple;

    > .awesome {
      color: deeppink;
    }
  }
}

Browser support

Chrome 112, Supported 112
Firefox, Not supported
Edge 112, Supported 112
Safari 16.5, Supported 16.5

Source

CSS `animation-composition` #

Chrome 112 also includes support for animation-composition. Learn how this property works in Specify how multiple animation effects should composite with animation-composition.

Browser support

Chrome 112, Supported 112
Firefox 115, Supported 115
Edge 112, Supported 112
Safari 16, Supported 16

Source

New headless mode #

If you use Chrome's Headless mode, for example with Puppeteer, then 112 brings an all new Headless mode. Learn about it in Chrome's Headless mode gets an upgrade.

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 113 and Chrome 113, with the Safari 16.5 beta still ongoing. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

Firefox 113 includes the color(), lab(), lch(), oklab(), and oklch() functions. Also included is the color-mix() function from CSS Color 5, and the forced-color-adjust property.

Firefox also includes the nth-child of <selector> syntax, giving finer control of which elements you want to select. Read more in More control over :nth-child() selections with the of S syntax.

For CSS, Chrome 113 includes the overflow-inline, overflow-block, and update media features. Also included in the linear() easing function, and the unprefixed image-set() type.

Chrome 113 also includes WebGPU, the successor to the WebGL and WebGL 2 graphics APIs for the Web. It provides modern features such as GPU compute, lower overhead access to GPU hardware, the ability to render to multiple canvases from a single graphics device, and better, more predictable performance.

Photo by Karen Ciocca.

New to the web platform in March

2023-03-31T00:00:00Z

Stable browser releases #

In March 2023, Firefox 111, Chrome 111, and Safari 16.4 became stable. Let's take a look at what this means for the web platform.

Global HTML attributes #

Firefox 111 adds support for a couple of useful global HTML attributes. The autocapitalize attribute controls whether text may be automatically capitalized when the user is typing on a virtual keyboard.

Browser support

Chrome 43, Supported 43
Firefox 111, Supported 111
Edge 79, Supported 79
Safari, Not supported

Source

The translate attribute indicates whether an element should be translated when a page is localized.

Browser support

Chrome 19, Supported 19
Firefox 111, Supported 111
Edge 79, Supported 79
Safari 6, Supported 6

Source

Origin Private File System (OPFS) #

Firefox adds support for the Origin Private File System (OPFS) when using the File System Access API. Learn more about the OPFS.

The View Transitions API #

Chrome 111 adds the View Transitions API, making the creation of polished transitions in Single-Page Apps (SPAs) simpler by snapshotting views and allowing the DOM to change without any overlap between states.

Find out more in the launch post SPA view transitions land in Chrome 111.

Browser support

Chrome 111, Supported 111
Firefox, Not supported
Edge 111, Supported 111
Safari, Not supported

Source

New CSS color spaces and functions #

Also included in Chrome 111 are a whole new set of ways to use color on the web. Chrome now supports color spaces that access colors outside of the RGB gamut, along with the color() and color-mix() functions. Learn more in our High definition CSS color guide and blog post on color-mix().

Browser support

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

Source

The Chrome release also includes new DevTools to help you work with this new color functionality.

More control over `:nth-child()` selections #

Chrome 111 adds the ability to pass a selector list into :nth-child() and nth-last-child(). Learn more about this, and see examples in the post More control over :nth-child() selections with the of S syntax.

Browser support

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

Support for previous and next slide in the Media Session API #

Finally in this list of Chrome 111 additions are the Presenting slides actions for the media session API—"previousslide" and "nextslide".

Browser support

Chrome 111, Supported 111
Firefox, Not supported
Edge 111, Supported 111
Safari, Not supported

Pseudo-class support in Safari #

Safari 16.4 is an amazing release for the web platform. This article won't cover all of the additions, so check out the full list of features in the Safari 16.4 release notes.

There's a bunch of additional CSS pseudo-classes with support in this release: :user-invalid, :user-valid, :dir(), :modal, and :fullscreen.

New range syntax for media queries #

This Safari release makes the far more elegant and useful range syntax for media queries interoperable across all three engines. See examples of this syntax in this post, published when the syntax shipped in Chrome.

Browser support

Chrome 104, Supported 104
Firefox 102, Supported 102
Edge 104, Supported 104
Safari 16.4, Supported 16.4

Source

CSS Properties and Values #

Safari 16.4 adds support for @property, enabling CSS custom property registration directly in a stylesheet. Learn more about this in @property: giving superpowers to CSS variables.

Browser support

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

Source

CSS API support #

The great additions for CSS keep coming, with support for the CSS Typed OM. This API exposes CSS values as typed JavaScript objects rather than strings. It makes working with CSS from JavaScript easier, and is more performant than existing methods.

Browser support

Chrome 66, Supported 66
Firefox, Not supported
Edge 79, Supported 79
Safari 16.4, Supported 16.4

Source

There is also support for constructable stylesheets with CSSStyleSheet(). This enables the sharing of stylesheets between a document and its shadow DOM subtrees. With this version of Safari, constructable stylesheets are now supported in all three engines.

Browser support

Chrome 73, Supported 73
Firefox 101, Supported 101
Edge 79, Supported 79
Safari 16.4, Supported 16.4

Source

Web Push and the Badging API #

Safari now suports Web Push, along with the Badging API, which is great news for app developers. In particular, this version means that push notifications are supported in all major engines.

Browser support

Chrome 42, Supported 42
Firefox 44, Supported 44
Edge 17, Supported 17
Safari 16, Supported 16

Source

Import maps #

Another addition that brings a feature to interoperable status is the addition of JavaScript Import maps, making importing ES modules much easier.

Browser support

Chrome 89, Supported 89
Firefox 108, Supported 108
Edge 89, Supported 89
Safari 16.4, Supported 16.4

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 112, Safari 16.5, and Chrome 112. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

Firefox 112 adds support for the inert attribute, which will make this useful attribute available across all engines. You can learn more about inert in Introducing inert. Firefox will also enable support for the linear() easing function.

Chrome 112 and Safari 16.5 both add support for CSS Nesting, a feature that is highly anticipated by many developers.

Chrome 112 also includes support for animation-composition. Learn how this property works in Specify how multiple animation effects should composite with animation-composition.

If you use Chrome's Headless mode, for example with Puppeteer, then 112 brings an all new Headless mode. Learn about it in Chrome's Headless mode gets an upgrade.

Photo by Tali Khrab.

New to the web platform in February

2023-02-28T00:00:00Z

Stable browser releases #

In February 2023, Firefox 110 and Chrome 110 became stable. Let's take a look at what this means for the web platform.

Container queries in all three engines #

Firefox 110 included support for size container queries, making this key feature available in all three engines.

Browser support

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

Source

CSS initial letters #

Chrome 110 adds support for the CSS initial-letter property. This property sets the number of lines an initial letter should sink into the following lines of text. Learn more in the post Control your drop caps with CSS initial-letter.

Browser support

Chrome 110, Supported 110
Firefox, Not supported
Edge 110, Supported 110
Safari 9, Supported 9

Source

ReadableStream async iteration #

Firefox added support for the async interable protocol in ReadableStream.

Browser support

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

AudioContext.setSinkId() #

In Chrome AudioContext.setSinkId sets the ID of the audio device to use for output. This allows the AudioContext to route audio to a connected output device of the user's choosing.

Learn more about this feature in the post Change the destination output device in Web Audio.

Browser support

Chrome 110, Supported 110
Firefox, Not supported
Edge 110, Supported 110
Safari, Not supported

Source

IFrame credentialless #

Also in Chrome, IFrame credentialless gives developers a way to load documents in third party iframes using new and ephemeral contexts. Iframe credentialless are a generalization of COEP credentialless to support third-party iframes that may not deploy COEP. This removes the constraint that third-party iframes must support COEP in order to be embedded in a COEP page and will unblock developers looking to adopt cross-origin-isolation.

Learn more about iframe credentialless.

Browser support

Chrome 110, Supported 110
Firefox, Not supported
Edge 110, Supported 110
Safari, Not supported

Early stable #

Chrome 110 also marked a change in the Chrome release schedule. The early stable release will roll out a week earlier than the general release, to a small percentage of users. You can learn more about this change in the article change in release schedule from Chrome 110.

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 111, Safari 16.4, and Chrome 111. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

Firefox adds support for the Origin Private File System (OPFS) when using the File System Access API.

Chrome includes all features described in CSS Color Level 4. This includes four device-independent color types (lab, Oklab, lch and Oklch), the color() function, and user-defined color spaces for gradients and animations. Also included is the color-mix() function from CSS Color 5.

Read the High definition CSS color guide to learn about these new color types and spaces.

Chrome also includes the View Transitions API, that enables polished transitions in Single-Page Applications (SPAs). Find out more in the documentation for View Transitions.

Also in Chrome 111 is the declarative shadow DOM, a new way to implement and use shadow DOM directly in HTML.

Safari 16.4 promises to be a huge release for the platform. For CSS the release includes support for the :user-invalid and :user-valid pseudo-classes, the margin-trim property, the range syntax for media queries, and support for the CSS Properties and Values API and @property.

Safari also includes support for Web Push, and the Badging API, along with a number of other Web APIs. It's a really exciting release that will see a number of features reach interoperability.

Photo by Robert Katzki.

Introducing Learn Privacy

2023-02-22T00:00:00Z

Today we are excited to announce the latest in our series of courses on web.dev. Learn Privacy is a brand new course written by Stuart Langridge.

When you acquire a new user, you are granted their trust. It's your organization's responsibility to honor this trust by keeping user data private. And, as a developer, you have a key role to play. This course will help you to understand the ways in which you can help to protect the privacy of your users, with code snippets, best practices, and questions to ask yourself and your team on your privacy journey.

Learn Privacy joins our existing courses:

Watch this space for more opportunities to learn key web development skills, coming up very soon!

All of Learn HTML! is available

2023-02-21T00:00:00Z

All modules in the Learn HTML course are now available. This course was written by Estelle Weyl and takes you through an in-depth journey to really understand HTML.

You can read them in whatever order you'd like. The final modules, launched today, are:

I've been writing HTML for a very long time, and I learned things while editing this course. There really is a lot more to HTML than you might think, and it's definitely worth revisiting some of the things you think you already know. Take a look, and don't forget to check out some of the other courses in our growing collection.

Last baseline alignment

2023-02-20T00:00:00Z

Alignment using the first and last keywords is now available in all major engines. This means that we can use last baseline alignment as another option when aligning groups of flex or grid items.

Browser support

Chrome 108, Supported 108
Firefox 52, Supported 52
Edge 108, Supported 108
Safari 16.2, Supported 16.2

First baseline alignment #

If you set the value of align-items to baseline, the result will be first baseline alignment. Therefore the first baseline of the item you are aligning (described as the alignment subject) will align with the first baseline of the other items in the group. You can see this in the following example, where the first two flex items are aligned using align-items: baseline, so they align along the baseline created by the larger text. The final item is aligned to flex-start and therefore aligns to the start of the flex container.

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

Last baseline alignment #

When aligning a grid or flex item with the value last baseline, the last baseline of that item will align to the last baseline of the baseline sharing group that it is part of. The following example demonstrates last baseline alignment, with the first flex item aligning with the last line of text in the larger item. The final item in this group is aligned to flex-end, which is the end of the flex container.

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

Fallback alignment #

If the alignment subject does not have a baseline sharing group to align to, then a fallback alignment will be used. For baseline, and first baseline the fallback alignment is start, and for last baseline the fallback alignment is end.

Photo by Toa Heftiba.

Interop 2023: continuing to improve the web for developers

2023-02-01T00:00:00Z

In 2023, all major browser vendors and other stakeholders are again working together to solve the top browser compatibility issues. The effort started on this scale with Interop 2022, and you can learn what we achieved together in the end-of-year post. Everyone involved believes this will help improve the experience for web developers everywhere. This year, for the first time, we publicly announced the proposal process and got many great suggestions from frameworks, large companies, browser vendors, and developers everywhere.

The Interop 2023 focus areas #

This time around, we have no less than 26 focus areas, outlined in detail in our project document. They are, in alphabetical order:

Border Image in CSS
Color Spaces and Functions in CSS
Container Queries in CSS
Containment in CSS
CSS Pseudo-classes
Custom Properties in CSS
Flexbox
Font feature detection and palettes
Forms
Grid
:has()
Inert
Masking in CSS
Math Functions in CSS
Media Queries
Modules in Web Workers
Motion Path in CSS Animations
Offscreen Canvas
Pointer and mouse Events
URL
Web Compat 2023: A catchall focus area for small bugs that cause known site compatibility issues
Web Codecs (video)
Web Components

You can find full details of all focus areas at Web Platform Tests based on MDN Web Docs, however here are a few that we think you might be really excited about.

Container Queries #

Container queries has been a top request from developers for many years, and in 2022 Chrome and Safari shipped it. Firefox expects to ship container queries in Firefox 110, and the tests for this focus area help to ensure that container queries work reliably cross-browser and according to the spec.

:has(…) #

Developers have for a long time asked for a parent selector in CSS. The :has() pseudo-class makes possible many of the use cases for parent selectors, as well as selecting a previous sibling element with respect to a reference element. For example, this makes it possible to style a figure that has a caption differently to one that doesn’t. Learn more about the use cases for has() in :has(), the family selector.

Custom Properties #

CSS custom properties, also known as CSS variables, make it possible to define a value once in a stylesheet and reuse that in many places, reducing repetition. For example, you can define a common color or font size once in a stylesheet and use this across components. Basic support for custom properties has been in browsers for a long time. Interop 2023 focuses on the @property at-rule. @property represents a custom property registration in a stylesheet, allowing for property type checking, setting default values, and whether the property should inherit values. Learn more in @property: giving superpowers to CSS variables.

CSS masking #

CSS masking provides methods to apply image effects, such as you might see in a graphics application, using CSS. Support for the various masking properties is patchy, making masking harder to use than it should be. This focus area will help developers to confidently use creative effects cross-browser. Learn more about applying effects to images in this article about image masking.

OffscreenCanvas #

The <canvas> element and Canvas API provide a scriptable way to draw graphics to the screen. However, this can cause performance problems as the work is completed on the same thread as user interaction. OffscreenCanvas offers developers a canvas which is decoupled from the DOM and the Canvas API. Developers can also run rendering tasks in a Web Worker, separate from the main thread. Learn more about the performance benefits of OffscreenCanvas.

Pointer and mouse events #

Pointer events are fired when interacting with a page using a mouse, pen, stylus, or touch screen. Mouse events are fired when using a mouse, but for historical reasons also for touch. This focus area covers the behavior of pointer and mouse interaction with pages, including how they interact with hit testing and scrolling areas. The focus area for 2023 excludes touch and stylus, due to a lack of Web Platform Tests in this area.

WebCodecs #

The WebCodecs API provides methods for developers to access the individual frames of video, and chunks of audio. It offers access to codecs that are already available in the browser, and various interfaces to interact with them. The article Video processing with WebCodecs shows how to use the API to decode and render individual frames to a canvas.

Web Components #

Web Components is an umbrella term for a number of technologies used to create reusable components, such as Custom Elements and Shadow DOM. Interop 2023 will focus on improving the interoperability of these foundational technologies.

Dashboard #

Follow progress throughout the year on the Interop 2023 dashboard, where you can see current scores and the status of addressing these focus areas across all major browser engines.

The Interop 2023 Dashboard (screenshot taken January 31st, 2023).

The Focus Area scores are calculated based on test pass rates. If you have feedback or want to contribute improvements to WPT, please file an issue to request updating the set of tests used for scoring.

All the Active Focus Areas and their overall Interop Score.

More about Interop 2023 #

Learn Images!

2023-02-01T00:00:00Z

Today we are excited to share with you our latest course on web.dev. Learn Images is a new course written by Mat Marquis, and it's a deep dive into all you need to know about images on the web.

This course is created for beginner and advanced web developers alike, covering everything from the basics of ensuring image sources are efficiently requested and rendered, to the details of how common image formats are communicated from server to client. Throughout this course you’ll learn how to achieve the smallest possible transfer sizes for your images without compromising on their quality—at least, not in a way anyone will be able to see.

As with all of our courses, you can go through the series from start to finish for a holistic understanding of how images work on the modern web, or use it as a reference for the specific concepts and markup patterns you’ll be using in your day-to-day work.

Learn Images joins our existing courses, as we develop a library of resources to help you learn key web development skills:

New to the web platform in January

2023-01-31T00:00:00Z

Stable browser releases #

In January 2023, Firefox 109, Chrome 109, and Safari 16.3 became stable. Let's take a look at what this means for the web platform.

MathML #

Chrome 109 supports MathML Core, a language for describing mathematical notation embeddable in HTML and SVG. This release means that MathML is now interoperable across all the major engines.

The `scrollend` event #

Firefox 109 implements scrollend. This event provides a reliable way to detect that a scroll is complete. Find out more about this event, which is also being implemented in Chrome, in the article Scrollend, a new JavaScript event.

Browser support

Chrome 114, Supported 114
Firefox 109, Supported 109
Edge 114, Supported 114
Safari, Not supported

Source

The `lh` CSS length unit and `hyphenate-limit-chars` #

For CSS in Chrome we have the lh length unit. This unit is equivalent to the computed value of the line-height property on the element on which it is used.

Browser support

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

Also, the hyphenate-limit-chars property specifying the minimum number of characters in a hyphenated word.

Browser support

Chrome 109, Supported 109
Firefox, Not supported
Edge 109, Supported 109
Safari, Not supported

Content-Security-Policy (CSP) `prefetch-src` #

Safari 16.3 is mostly a release of fixes, and resolves a number of CSS sizing issues. The only new feature listed in the notes, is the addition of the Content-Security-Policy (CSP) prefetch-src directive.

Browser support

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

Source

Features for Chrome on Android #

New in Chrome on Android is Secure Payment Confirmation (SPC). This is a proposed web standard that allows customers to authenticate with a credit card issuer, bank, or other payment service provider using a platform authenticator—typically activated with a device's screen unlock feature such as a fingerprint sensor.

Also new for Chrome on Android is the Origin Private File System (OPFS), part of the File System Access API on Android. This includes all of the File System Access API surface, minus the show{OpenFile, SaveFile, Directory}Picker() methods and the Drag and Drop API integration.

Beta browser releases #

Chrome 110 includes the CSS initial-letter property. This property provides a way to set the number of lines that an initial letter should sink into the text. Learn more in the article Control your drop caps with CSS initial-letter.

Also, for CSS in Chrome 110 is the :picture-in-picture pseudo-class. This gives you a way to target and customize the media player when videos enter and exit picture-in-picture mode.

Chrome includes the setSinkID() method of the AudioContext API. This method provides a way to change the destination audio device when using Web Audio.

Firefox 110 includes size Container Queries, which will bring us interoperability across the three main browser engines for this long-awaited feature.

Photo by Denys Nevozhai.

New to the web platform in December

2022-12-28T00:00:00Z

Stable browser releases #

In December, Firefox 108, and Safari 16.2 became stable. Let's take a look at what this means for the web platform.

Support for `height` and `width` attributes of `<source>` #

Firefox 108 supports height and width attributes for the <source> element, when it is a child of a <picture> element. These attributes accept the height or width of the image, in pixels, as an integer without a unit.

Browser support

Chrome 90, Supported 90
Firefox 108, Supported 108
Edge 12, Supported 12
Safari 15, Supported 15

Trigonometric CSS functions #

Firefox also now supports trigonometric functions in CSS—sin(), cos(), tan(), asin(), acos(), atan(), and atan2().

Browser support

Chrome 111, Supported 111
Firefox 108, Supported 108
Edge 111, Supported 111
Safari 15.4, Supported 15.4

Source

Support for last baseline in all three engines #

In addition to a number of CSS fixes, Safari 16.2 includes last baseline alignment for CSS grid and flexbox layout, which means this feature now supported in the three main browser engines.

CSS `font-variant-alternates` #

Safari also adds support for additional values for the font-variant-alternates CSS property: annotation(value-name), character-variant(value-name), ornaments(value-name), styleset(value-name), stylistic(value-name), swash(value-name), along with the associated @font-feature-values at-rule.

Browser support

Chrome 111, Supported 111
Firefox 34, Supported 34
Edge 111, Supported 111
Safari 9.1, Supported 9.1

Source

Beta browser releases #

The only new feature listed for Safari 16.3 is the addition of the Content-Security-Policy (CSP) prefetch-src directive. There are also a number of fixes in this beta.

Chrome 109 supports MathML Core, a language for describing mathematical notation embeddable in HTML and SVG.

For CSS in Chrome we have the lh length unit. This unit is equivalent to the computed value of the line-height property on the element on which it is used. Also, the hyphenate-limit-chars property specifying the minimum number of characters in a hyphenated word.

At the time of writing, and perhaps due to the holiday season, Firefox release notes haven't been updated.

Other news #

This post marks the 12th edition of this blog post series, bringing you a selection of interesting things landing in browsers each month in 2022. I'll be back in 2023 to continue sharing some of the interesting things landing on the web platform each month.

Many of the features landing in browsers over this past year, and lots of those things mentioned as "CSS fixes," were part of Interop 2022. For more information, read the Chrome team's end-of-year report on this cross-browser initiative to improve some of the top interoperability pain points on the web platform.

And finally, of interest to people who read this post, is this list of updates based on the MDN browser compatibility data, released by our friends over at MDN.

Photo by Patrick Hendry.

Interop 2022: end of year update

2022-12-19T00:00:00Z

We've reached the end of another year, and it's time to look at the improvements made by browsers as we work together to improve the interoperability of the web platform. You can check out how things started in our post in March this year, as the initiative was launched.

The scores for experimental browsers in March 2022.

The overall scores at the end of the year show a great improvement across all engines.

The scores for experimental browsers in December 2022.

In this post, learn about the progress made during 2022. In addition to these headline features, there were many smaller improvements made by all engines. Small issues that can cause inconsistencies between engines and trip you up during development, have been fixed. Seeing big features available cross-browser is definitely exciting, but it's sometimes the small things that cause the most problems, and it's great to see how much has been improved.

Cascade layers #

Cascade layers let you manage the cascade by grouping selectors into layers. It's the kind of feature that only becomes useful when it is supported everywhere. All major engines now support cascade layers, and the scores across all browsers reflect how interoperable the feature is, with just a few tests left to pass for Firefox.

Browser support

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

Source

The dialog element #

The dialog element allows the creation of modal and non-modal dialogs. This is a common pattern on the web, and using this element gives you usability and accessibility that you would otherwise have to develop and test when creating your own components. In the article Building a dialog component, Adam Argyle explains how to build on top of this element to build different types of dialogs.

Browser support

Chrome 37, Supported 37
Firefox 98, Supported 98
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

Subgrid #

At the beginning of 2022, the only browser supporting the subgrid value for grid-template-rows and grid-template-columns was Firefox. During 2022 Safari has landed support, and the feature is under development in Chrome. It's going to miss the end of year deadline for interoperability, but it's on the way.

Browser support

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

Source

Viewport units #

Viewport units are the only feature that has hit 100% of passing tests across all engines. This includes the concepts of the small and large viewport, that accounts for the changing viewport size on mobile as device UI elements appear and disappear. You can find out more about these units in the post the large, small, and dynamic viewport units.

Browser support

Chrome 108, Supported 108
Firefox 101, Supported 101
Edge 108, Supported 108
Safari 15.4, Supported 15.4

Color 4 #

This collection of color work enables CSS to not only specify colors in higher definition gamuts (for example, display p3, rec2020), but also provides new color functions that each have unique utilities for working with color. New color spaces are lch(), oklch(), lab(), oklab(), display-p3, rec2020, a98-rgb, prophoto-rgb, xyz, xyz-d50, xzy-d65: try these in Canary today with this flag enabled. These changes also apply to gradients, allowing authors to specify which colorspace their gradients use. The same flag also enables color-mix() support, allowing you to mix two colors together in a space of your choice. The color-mix() function is also behind a flag in Safari and Firefox. More colors, better colors, better gradients, and better tools.

Interop 2023 #

I hope you'll be happy to know that we aren't intending to stop at the end of 2022, and Interop 2023 is already well through the initial planning stage. In the New Year we'll be able to announce the features that have been selected, and look forward to another year of making it easier to develop for the web.

Hero image by Ian Schneider.

New to the web platform in November

2022-11-30T00:00:00Z

Stable browser releases #

In November, Firefox 107, and Chrome 108 became stable. Let's take a look at what this means for the web platform.

A change to Layout Viewport behavior in Chrome on Android #

There's a change to how the Layout Viewport behaves from Chrome 108 on Android when the on-screen keyboard is shown. Read Prepare for viewport resize behavior changes coming to Chrome on Android to learn more.

New viewport units #

Also in Chrome 108 are the new CSS Viewport Units. These include small (svw, svh, svi, svb, svmin, svmax), large (lvw, lvh, lvi, lvb, lvmin, lvmax), dynamic (dvw, dvh, dvi, dvb, dvmin, dvmax), and logical (vi, vb) units. These units are already implemented in Firefox and Safari, meaning that we now have interop across the three main browser engines for these units.

Read The large, small, and dynamic viewport units.

Browser support

Chrome 108, Supported 108
Firefox 101, Supported 101
Edge 108, Supported 108
Safari 15.4, Supported 15.4

The contain-intrinsic-size shorthand CSS property is supported in Firefox 107, along with the longhand contain-intrinsic-width, contain-intrinsic-height and logical properties contain-intrinsic-block-size and contain-intrinsic-inline-size.

These are applied to specify the size of a UI element that is subject to size containment. This allows a user agent to determine the size of an element without needing to render its child elements. They are useful when an element is subject to size containment.

Browser support

Chrome 83, Supported 83
Firefox 107, Supported 107
Edge 83, Supported 83
Safari 17, Supported 17

Source

Support for the CSS fragmentation `avoid` keyword #

Chrome 108 includes support for the avoid value of the CSS fragmentation properties break-before, break-after, and break-inside when printing. This value tell the browser to avoid breaking before, after or inside the element it is applied to. For example, the following CSS avoids a figure being broken at a page break.

figure {
    break-inside: avoid;
}

This addition is due to the inclusion of print support using LayoutNG, this brings a modern, lessy buggy experience. Learn more about LayoutNG.

Federated Credential Management API #

The Federated Credential Management API (FedCM) provides an abstraction for federated identity flows on the web. It exposes a browser mediated dialog that allows users to choose accounts from identify providers to login to websites. FedCM is shipping in Chrome 108, find out more about it in the FedCM announcement blog post.

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. Due to where release dates fall, the only new beta this month is Firefox 108, with Safari 16.2 beta still ongoing.

Implementation of container queries is underway in Firefox. Behind the layout.css.container-queries.enabled flag in Firefox 108 beta, you will find the container query length units—cqw, cqh, cqi, cqb, cqmin, cqmax. These are units of length relative to the size of a query container.

Photo by Matt Seymour.

Accessibility Week

2022-11-18T00:00:00Z

This week we highlighted accessibility resources to help you make your sites and applications usable by everyone.

We're continuing to roll out Learn Accessibility, a brand new course written by Carie Fisher that will take you through the essentials for building accessible websites and web apps.

We've had 3 community spotlights:

Melanie Sumner told us about her journey into engineering, accessible design, Ember.js, and the importance of funding these efforts.
Olutimilehin Olushuyi told us about his move from the law to web development, building accessible community, and creating accessible layouts.
Albert Kim told us about mental health awareness, building for invisible disabilities, the COGA Accessibility Community Group, and more practical wisdom.

Watch us answer your questions #

On Thursday, Alexandra White spoke with Carie Fisher and Melanie Sumner about accessibility, and we answered some of your questions.

Have more questions? Ask us on Twitter, @ChromiumDev.

More resources #

A solid document structure is a great start for accessible development. Find out how to really use HTML in our Learn HTML course. Follow it up with Learn Accessibility's Content structure module for more on semantic HTML, landmarks, and tables for accessible content.

In Testing web design color contrast get an overview of three tools and techniques to ensure your content is readable by everyone.

In Building the main navigation for a website learn how to create accessible navigation using semantic HTML.

On the web #

The W3C hosts a collection of courses, training, and certification on digital accessibility from different providers.
Read Accessibility articles on Smashing Magazine, including <article> vs. <section>: How To Choose The Right One by Olushuyi Olutimilehin.
If you're making a case for accessibility work at your company, check out Melanie Sumner's pleasefunda11y.com.
If you want to support the Cognitive and Learning Disabilities Accessibility Task Force, join the COGA Accessibility Community Group. This group supplies user needs and feedback to the COGA Task Force.

New to the web platform in October

2022-10-31T00:00:00Z

Stable browser releases #

In October, Firefox 106, Chrome 107, and Safari 16.1 became stable. Let's take a look at what this means for the web platform.

Animation of grid tracks #

Thanks to the work of our contributors at Microsoft, Chrome is now able to interpolate grid-template-columns and grid-template-rows values. This means that grid layouts can smoothly transition between states, instead of snapping at the halfway point of an animation or transition.

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

Hover over the avatars to see the animation. This example is from the article CSS animated grid layouts, where you can find out more.

Browser support

Chrome 107, Supported 107
Firefox 66, Supported 66
Edge 107, Supported 107
Safari 16, Supported 16

Additions to `getDisplayMedia()` #

Also in Chrome are some additions to getDisplayMedia() that aim to prevent accidental oversharing when screen sharing.

The displaySurface option can indicate that the web app prefers to offer a specific display surface type (tabs, windows, or screens).
The surfaceSwitching option indicates whether Chrome should allow the user to dynamically switch between shared tabs.
The selfBrowserSurface option can be used to prevent the user from sharing the current tab. This avoids the "hall of mirrors" effect.
The systemAudio option ensures Chrome only offers relevant audio-capture to the user.

Safari 16.1 also includes support for getDisplayMedia, adding support for capturing a specific Safari window.

Testing for support of font technology and features from CSS #

Firefox has added the font-tech() and font-format() functions to feature queries with @supports. The following example tests for support of COLRv1 fonts.

@supports font-tech(color-COLRv1) {

}

You can find more examples on MDN.

Scroll to text fragment #

Safari 16.1 includes support for scroll to text fragment which adds support for navigating to a URL with a particular text fragment specified.

AVIF support #

Safari 16 included support for still AVIF images, Safari 16.1 includes support for animated AVIF images on macOS Ventura, iOS 16, and iPadOS 16.

Web Push for Safari #

Safari 16.1 brings Web Push support to Safari on macOS Ventura. This uses the Push API and Notifications API, you can read more about this in the article Meet Web Push. Web Push landing in Safari means that it is now available across all three major engines.

Beta browser releases #

figure {
    break-inside: avoid;
}

Chrome 108 starts to roll out a change to the way overflow behaves on replaced elements, which may cause visual changes in some circumstances. Read the article A change to overflow on replaced elements in CSS for more details and to see how to address any issues you see.

There's a change to how the Layout Viewport behaves in Chrome on Android when the on-screen keyboard is shown. Read Prepare for viewport resize behavior changes coming to Chrome on Android to learn more and find out how to prepare for this shipping to stable next month.

Also in Chrome are the new CSS Viewport Units. These include small (svw, svh, svi, svb, svmin, svmax), large (lvw, lvh, lvi, lvb, lvmin, lvmax), dynamic (dvw, dvh, dvi, dvb, dvmin, dvmax), and logical (vi, vb) units. These units are already implemented in Firefox and Safari.

Firefox 107 enables COLRv1 font support, joining Chrome in supporting this font technology. Also in fonts, Chrome 108 adds support for the font-tech() and font-format() functions to feature queries with @supports.

Firefox also adds contain-intrinsic-size support, joining Chrome to make two browsers with support for this feature.

Safari 16.2 Beta includes a bunch of CSS fixes including sizing and scroll snap.

Photo by ahmed zid.

New to the web platform in September

2022-09-30T00:00:00Z

Stable browser releases #

In September, Firefox 105, Chrome 106, and Safari 16 became stable. This means that the September post is full of exciting things for the web platform.

Container queries #

Safari 16 adds support for container queries, a feature which is now available in two engines. Safari also adds support for the new container query units.

Browser support

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

Source

Grid layout #

Safari has landed support for the subgrid value of grid-template-columns and grid-template-rows. Using this value on a grid that is also a grid item means that instead of defining new tracks, the grid uses those that it spans of the parent.

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

In Safari or Firefox the headers and footers in these cards will align, as their tracks are a subgrid of the parent.

Browser support

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

Source

Also, in Safari, for grid layout is the ability to animate grid tracks.

Browser support

Chrome 107, Supported 107
Firefox 66, Supported 66
Edge 107, Supported 107
Safari 16, Supported 16

Safari has also added support for offset-path, overscroll-behavior, text-align-last, and the resolution media query.

Encoding API #

Firefox 105 supports the TextDecoderStream and TextEncoderStream interfaces of the Encoding API.

Browser support

Chrome 71, Supported 71
Firefox 105, Supported 105
Edge 79, Supported 79
Safari 14.1, Supported 14.1

Source

New Intl APIs #

The Intl APIs help to display content in a localized format and Chrome 106 adds a slew of new number format functionality.

Like other Intl APIs, this shifts the burden to the system—so you don’t need to ship or maintain complex localization code to every user. The API knows where the currency symbol goes, how to format dates and times, or compile a list.

The showPicker() method #

Safari 16 contains the showPicker() method, enabling a canonical way to show a browser picker for dates, time, color, and files is included. You can find out more about this in show a browser picker for date, time, color, and files.

Beta browser releases #

Chrome 107 includes the ability to animate grid tracks, that also shipped in Safari this month. Once this lands in Chrome it will be supported in all three major engines.

Also in Chrome are some additions to getDisplayMedia() that aim to prevent accidental oversharing when screen sharing.

The displaySurface option can indicate that the web app prefers to offer a specific display surface type (tabs, windows, or screens).
The surfaceSwitching option indicates whether Chrome should allow the user to dynamically switch between shared tabs.
The selfBrowserSurface option can be used to prevent the user from sharing the current tab. This avoids the "hall of mirrors" effect.
The systemAudio option ensures Chrome only offers relevant audio-capture to the user.

Safari 16.1 includes an additional fix to accessibility of display: contents, a fix to dynamic viewport height (dvh) units, and support for scroll to text fragments.

Photo by Alexandr Podvalny.

Introducing Learn HTML

2022-09-27T00:00:00Z

Today we are excited to announce the latest in our series of courses on web.dev. Learn HTML is a brand new course written by Estelle Weyl that will take you through all you need to know about HTML today.

We're landing the first five modules today, the rest will follow in staged launches over the next couple of months. You can work through these modules beginning to end, or dip into those that interest you. Even if you have been working on the web for years, you'll discover things you didn't know. HTML is a Living Standard, constantly evolving to meet the needs of the web, so it's worth revisiting it from time to time.

Learn HTML joins our existing courses:

Watch this space for more opportunities to learn key web development skills, coming up very soon!

Submit your proposals for Interop 2023

2022-09-21T00:00:00Z

The Chrome team has worked with other browser vendors and partners in the ecosystem to help improve browser compatibility since 2019, starting with the MDN Developer Needs Assessment survey and most recently on Interop 2022. For Interop 2022, all major browser vendors and other stakeholders worked together to improve top browser compatibility issues identified by web developers. We are thrilled at the progress that we’ve made together and are excited to announce Interop 2023 is happening!

March 2022.

September 2022.

The Interop 2023 proposal process is now open for submissions. Suggestions can include features that behave differently across browsers, or features that are not yet implemented in all browsers. Keep in mind that proposals with high quality specifications and web platform tests are more likely to be included, as this project is about reaching interoperability rather than specifying new features. The proposal submission process ends October 15, 2022.

Once the proposal period ends, the collected submissions will be discussed by browser vendors and other partners to determine the final list. It’s likely that there will be more proposals than can be achieved during 2023, so some high quality proposals may not be selected. We are looking forward to reviewing all the submissions, and we’ll post the final list here once Interop 2023 gets underway.

New to the web platform in August

2022-08-31T00:00:00Z

Stable browser releases #

In August, Firefox 104, Chrome 104, and Chrome 105 became stable.

Individual transforms #

Chrome 104 includes individual properties for CSS Transforms. The properties are scale, rotate, and translate, which you can use to individually define those parts of a transformation.

By doing so, Chrome joins Firefox and Safari which already support these properties.

Browser support

Chrome 104, Supported 104
Firefox 72, Supported 72
Edge 104, Supported 104
Safari 14.1, Supported 14.1

Source

New media query syntax #

Chrome 104 also includes the media query range syntax. This has already been shipped by Firefox, and helps streamline media queries. For example the following media query:

@media (min-width: 400px) {
  // Styles for viewports with a width of 400 pixels or greater.
}

Can be written using a comparison operator:

@media (width >= 400px) {
  // Styles for viewports with a width of 400 pixels or greater.
}

Browser support

Chrome 104, Supported 104
Firefox 102, Supported 102
Edge 104, Supported 104
Safari 16.4, Supported 16.4

Source

Container queries #

Chrome 105 is an exciting release bringing the long-awaited feature of container queries to the web platform. While media queries give you a way to query against the size of the viewport, container queries provide a method of querying against the size of a container.

Browser support

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

Source

To use container queries, turn on containment using the container-type property.

.card-container {
  container-type: 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, since the text flows inline from left to right.

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

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

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

You can find out more about container queries in the post @container and :has(): two powerful new responsive APIs landing in Chromium 105.

The :has() parent pseudo-class #

The post mentioned above also mentions :has(). This new pseudo-class The CSS :has() pseudo-class gives you a way to target the parent element and siblings based on conditions. Learn more in :has() the family selector.

Browser support

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

Source

Sanitizer API #

Also in Chrome 105 is the Sanitizer API. This API builds sanitization into the platform to help remove cross-site scripting vulnerabilities.

Browser support

Chrome 105, Supported 105
Firefox 83, Behind a flag
Edge 105, Supported 105
Safari, Not supported

Source

Also in Chrome 105 is the :modal CSS pseudo-class. This matches an element that is in a state in which it excludes all interaction with elements outside it. For example, a <dialog> opened with the showModal() API.

Browser support

Chrome 105, Supported 105
Firefox 103, Supported 103
Edge 105, Supported 105
Safari 15.6, Supported 15.6

Source

The findLast() and findLastIndex() methods #

Firefox 104 adds support behind a flag for the methods Array.prototype.findLast(), Array.prototype.findLastIndex(), TypedArray.prototype.findLast(), and TypedArray.prototype.findLastIndex(). These are used to find the value and index (respectively) of the last element in an Array or TypedArray that matches a supplied test function.

Browser support

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

Source

Beta browser releases #

Due to release dates falling just outside the month, the only new beta in August was Firefox 105, which is currently light on details.

The Safari 16 beta mentioned in June is also still ongoing.

New to the web platform in July

2022-07-29T00:00:00Z

Stable browser releases #

In July, Firefox 103 and Safari 15.6 became stable, and with this we get interoperability on a couple of nice CSS features.

The `backdrop-filter` property #

Firefox 103 includes the backdrop-filter property which is used to apply effects such as blurring to the area behind an element. With this value in Firefox, it is now available in all three engines, though Safari requires the -webkit prefix.

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

Browser support

Chrome 76, Supported 76
Firefox 103, Supported 103
Edge 17, Supported 17
Safari 9, Supported 9

Source

The `scroll-snap-stop` property #

Firefox also implemented the scroll-snap-stop property. This property gives you control over whether a scrolling element passes over possible snap positions (with the default value of normal) or must snap to the first (with the value always). The scroll-snap-stop property is now in all three browser engines.

Browser support

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

Source

Safari 15.6 was a release mostly dedicated to resolving issues, however it did land one new CSS feature with the :modal pseudo-class. This feature was also shipped in Firefox 103. The :modal pseudo-class selects an element when everything outside of that element cannot be interacted with until the element is dismissed. For example, a dialog element opened with showModal().

Browser support

Chrome 105, Supported 105
Firefox 103, Supported 103
Edge 105, Supported 105
Safari 15.6, Supported 15.6

Source

Beta browser releases #

Due to release dates falling just outside the month, the only new beta in June was Firefox 104.

Included in Firefox 104 is the CSS Font Loading API in Web Workers, and the CSS animation-composition property, that defines the composition operation used when multiple animations affect the same property simultaneously.

The Safari 16 beta mentioned last month is also still ongoing.

These beta features will land in stable browsers soon.

Hero image by Nick Fewings.

New to the web platform in June

2022-06-30T00:00:00Z

Stable browser releases #

In June, Chrome 103 and Firefox 102 became stable.

Transform streams and readable byte streams #

Firefox 102 includes support for Transform Streams. This enables piping from ReadableStream to a WritableStream, executing a transformation on the chunks. It's great to see this feature become available in all three engines, making this a very good time to learn about Streams.

Browser support

Chrome 67, Supported 67
Firefox 102, Supported 102
Edge 79, Supported 79
Safari 14.1, Supported 14.1

Source

Readable byte streams are also now supported in Firefox 102, enabling a BYOB (bring your own buffer) reader with the ReadableStreamBYOBReader interface. This can be used to stream data supplied by the developer.

Browser support

Chrome 89, Supported 89
Firefox 102, Supported 102
Edge 89, Supported 89
Safari, Not supported

Source

Access locally installed fonts #

Chrome 103 includes the Local Font Access API, which allows access to the user's locally installed fonts. After requesting access to the fonts installed on the device, call window.queryLocalFonts() to get an array of the installed fonts.

const pickedFonts = await window.queryLocalFonts();
for (const fontData of pickedFonts) {
  console.log(fontData.postscriptName);
  console.log(fontData.fullName);
  console.log(fontData.family);
  console.log(fontData.style);
}

The `update` media feature #

Firefox 102 includes the update media feature. This is used to query whether the output device can modify the appearance of content once it has been rendered.

Browser support

Chrome 113, Supported 113
Firefox 102, Supported 102
Edge 113, Supported 113
Safari, Not supported

Source

A new HTTP status code—103 early hints #

Chrome 103 adds a new status code HTTP 103 Early Hints. If the server or CDN knows that a certain set of subresources is required to load a page, it can advise the browser to preconnect to origins or even preload resources as the page that requires them comes in. This requires updates to your server or CDN to take advantage of the feature, find out more about Early Hints.

Beta browser releases #

New betas in April were Chrome 104, Firefox 103, and Safari 16.

New syntax for range media queries #

Chrome 104 includes the new syntax for range media queries, from the Media Queries Level 4 specification. For example, a media query previously written like this:

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

Can now be written like this:

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

Browser support

Chrome 104, Supported 104
Firefox 102, Supported 102
Edge 104, Supported 104
Safari 16.4, Supported 16.4

Source

Region Capture API #

Chrome 104 on desktop also includes the Region Capture API. This enables cropping and removing content from captured video before sharing it.

Safari 16 brings several key features to the browser #

Safari 16 looks to be another exciting release from the Safari team. This release adds many of the features that are included in Interop 2022, it's great to see so much landing at this mid-year point. I'm highlighting a few of my favorite features here, but do check out the release notes for more.

Along with many developers, I'm really excited to see size queries support for Container Queries, a feature that is also behind a flag in Chrome currently.

Also in Safari 16 is support for the subgrid value for grid-template-columns and grid-template-rows. This feature is already in Firefox, and in development in Chrome, and enables grid track sizing to be inherited by nested grids.

Browser support

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

Source

Also for grid layout is the ability to animate grid tracks.

Browser support

Chrome 107, Supported 107
Firefox 66, Supported 66
Edge 107, Supported 107
Safari 16, Supported 16

The showPicker() method, enabling a canonical way to show a browser picker for dates, time, color, and files is included. You can find out more about this in show a browser picker for date, time, color, and files.

Browser support

Chrome 99, Supported 99
Firefox 101, Supported 101
Edge 99, Supported 99
Safari 16, Supported 16

Source

Accessibility issues for display: contents have also been addressed, making this useful feature safe to use without danger of removing elements from the accessibility tree.

These beta features will land in stable browsers soon.

Hero image by Nick Fewings.

New to the web platform in May

2022-05-31T00:00:00Z

Stable browser releases #

In May, Chrome 102, Safari 15.5, Firefox 100, and Firefox 101 became stable.

Chrome 102 and Safari 15.5 include the inert attribute. This removes elements from the tab order and accessibility tree if they are non-interactive. For example, an element that is currently offscreen or hidden.

Browser support

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

Source

Chrome 102 includes the new value until-found for the HTML hidden attribute. This enables find-in-page and scroll to text fragment on text that is inside a collapsed area of the page, as you might find in an accordion pattern. Find out more in the post Making collapsed content accessible with hidden=until-found.

Browser support

Chrome 102, Supported 102
Firefox, Not supported
Edge 102, Supported 102
Safari, Not supported

Source

Chrome 102 ships the Navigation API, an API that standardizes client-side routing in single-page applications. This API was previously named the App History API.

Browser support

Chrome 102, Supported 102
Firefox, Not supported
Edge 102, Supported 102
Safari, Not supported

Firefox 101 supports constructable stylesheets. Support includes the CSSStyleSheet() constructor, and the replace(), and replaceSync() methods. Constructable stylesheets make it easier to create stylesheets for use with the Shadow DOM. In the following example, a stylesheet is created using the CSSStyleSheet() constructor, a CSS rule is added with the replaceSync() method, and the resulting rule is printed to the console.

const stylesheet = new CSSStyleSheet();
stylesheet.replaceSync('body { color: red; }');
console.log(stylesheet.rules[0].cssText);

Browser support

Chrome 73, Supported 73
Firefox 101, Supported 101
Edge 79, Supported 79
Safari 16.4, Supported 16.4

Source

Also in Firefox 101 is the prefers-contrast media feature, making this feature available cross-browser.

Browser support

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

Source

Beta browser releases #

New betas in April were Chrome 103 and Firefox 102.

Firefox 102 includes the update media feature. This is used to query whether the output device can modify the appearance of content once it has been rendered. It accepts the following values:

none: Once rendered the content cannot be updated. For example, a printed document.
slow: The device can update the content, but too slowly to display smooth animation. For example, E-ink screens.
fast: The content can change dynamically, and quickly enough to render animations. For example, a computer or phone screen.

Browser support

Chrome 113, Supported 113
Firefox 102, Supported 102
Edge 113, Supported 113
Safari, Not supported

Source

Chrome 103 includes the Local Font Access API, which allows access to the user's locally installed fonts.

These beta features will land in stable browsers soon.

Edit: A previous version of this post included mention of the Element.isVisible() method, which is not shipping in this release.

The Front-End Developer's Guide to the Terminal

2022-05-20T00:00:00Z

If you are used to working in a GUI, then the terminal can seem a complicated and unforgiving place. By learning a few commands however, you can achieve most tasks quickly and easily.

Josh Comeau has written an excellent guide for front-end developers who are new to the terminal. Providing the information that many tutorials seem to assume you already know, in easy to follow steps.

"It's the missing manual of terminal fundamentals needed to work with modern JS frameworks like React, so you can move onto the fun stuff: building user interfaces!"

Check it out at The Front-End Developer's Guide to the Terminal.

Photo by Etienne Girardet.

Bridging the gap

2022-05-11T00:00:00Z

When we talk to developers, be that individually or via surveys such as the State of CSS, we repeatedly hear the same things. Developers find it hard to make websites and applications that work well across browsers, and find it hard to know when exciting new features are safe to use.

Flexbox gap #

As an example of a problematic property, the gap property lets you make gaps between grid or flex items, or columns in a multicol container. While we have had column-gap in multicol for a long time, the property first appeared in grid layout as grid-gap, along with grid-column-gap and grid-row-gap.

Just after grid layout landed in browsers, the property was renamed as gap, along with row-gap and column-gap. It was then specified to work in flex layout too. The renaming means that we don’t have multiple properties doing the same thing.

.box {
  display: flex;
  gap: 1em;
}

Firefox shipped the property for flex layouts in October 2018. It didn’t show up in Chrome until July 2020, followed by Safari in April 2021. This meant there was a gap of two years and six months before we could safely use gap. In reality, for most developers the wait was much longer, due to needing to support browser versions older than the latest one. Supporting gap in flex layout was made more problematic by the fact we can’t use feature queries to detect gap support in flex layout. As the gap property is supported in grid, @supports (gap:1em) will return true.

An additional problem is that when a new feature lands in one browser, people start to talk about it and share demos. This often begins long before the feature is in any stable browser at all. This can be confusing for developers, or at the least, frustrating. Repeatedly, shiny new features are being talked about everywhere, and then you discover you can’t actually use them due to lack of support.

Why are there gaps in support? #

This is not a post pointing the finger at one browser for being slow. If you look across different platform features, you’ll discover that different browsers take the lead on different features.

Most features will be prototyped in one browser. For example, the grid layout specification was first created by Microsoft and implemented in an initial form in Internet Explorer 10. An engineer at Mozilla did a lot of work to figure out how subgrid should behave, and so this feature landed in Firefox first. We’re seeing Safari take the lead on some exciting new color functions.

While one browser may take the lead on prototyping, representatives of all browsers (and other organizations) in the CSS Working Group discuss CSS features. It’s very important that a feature can be implemented in all browsers, and that it isn’t designed in such a way as to make it impossible to implement in one browser. That would lead to a permanent gap in support, and lack of adoption of the feature.

When it comes to implementing a feature however, it needs to be prioritized alongside all the other possible features for that browser. And, sometimes things are held up behind other work that needs to be done to make the browser better. A great example of this is the RenderingNG work in Chromium. This has paved the way for the implementation of subgrid; however, the long gap between Firefox and Chromium shipping subgrid is due to the need for grid layout to be reimplemented in the new rendering engine first.

The problems #

We have two problems here. The first is the interoperability problem, the fact that it can take a long time from the point at which a feature lands in one browser to when it is available everywhere.

The second is a problem of messaging. How can we make it clear where the gaps in support are? How do we share new features without causing everyone to have to carefully research each thing to work out how well supported it is?

Interoperability #

Browsers are already working together to solve the interoperability issue. Last year Compat 2021 helped to close the gap in support on a number of features, including the gap property in flex layout. This year the Interop 2022 effort is focussing on 15 features, and there has already been movement on some of these.

You can follow progress on the Interop 2022 dashboard.

Messaging #

The second problem is something that I’m keen to help with when we talk about features here on web.dev and on developer.chrome.com. I want the status of features to be really clear when you read our content, and for us to provide practical ways to navigate support issues.

We’ve launched a number of fundamental courses, with more to come. These courses help you to learn how to build for the modern web, using core web platform technologies. Check out:

We’re working to focus our content on this site on those things that you can safely use. We’re not completely there yet; however, you should start to see a bit of a shift towards the practical over the coming months.

We also contribute to open web documentation through our support of the Open Web Docs project. This ensures we have first-class documentation on MDN, along with up-to-date browser compatibility data. We then use this data here on web.dev to show support for features. Here’s the current support of gap in flex layout.

Browser support

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

If you want to know more about Chrome’s vision for the web, the things we are experimenting with in Origin and Developer trials, then you’ll increasingly find that content on our sister site—developer.chrome.com. The content there may well be experimental, or only supported in Chrome right now, but we’d love you to explore it and offer feedback.

It really is an exciting time for the web right now. We hope we can help to bring key features to you more quickly, and be clear about the gaps that do exist, making web development more fun and less frustrating.

Photo by Cristofer Maximilian.

Variable fonts in real life

2022-05-06T00:00:00Z

If you have not yet taken the plunge into using variable fonts, the article Variable fonts in real life from Roman Shamin and Travis Turner at Evil Martians gives some excellent use cases, and reasons why your next project should make the change.

Variable fonts now have excellent browser support. They can help with performance, as the browser only needs to download a single font file for all variations. However, as this article shows, they can also help match font weights to logos and other elements, assist with contrast issues between light and dark mode, and make small text more readable.

Browser support

Chrome 62, Supported 62
Firefox 62, Supported 62
Edge 17, Supported 17
Safari 11, Supported 11

Source

Hero image by Florian Klauer

New to the web platform in April

2022-04-29T00:00:00Z

Stable browser releases #

In April, Chrome 101 and Firefox 99 became stable. After the bumper crop of features landing last month, it was a bit quieter during April, but a few interesting things landed for us to use.

Chrome 101 includes hwb color notation. This specifies color according to its hue, whiteness, and blackness. As with other color notation, an optional alpha component specifies opacity.

h1 {
  color: hwb(194 0% 0% / .5) /* #00c3ff with 50% opacity */
}

To learn more about hwb(), read this article by Stefan Judis: hwb() – a color notation for humans?.

Browser support

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

Source

Also in Chrome 101 is the Fetch Priority feature. This gives you a way to hint to the browser which order resources should be downloaded in, by using the fetchpriority attribute. In the example below, a low priority image is indicated with fetchpriority="low".

<img src="/images/in_viewport_but_not_important.svg" fetchpriority="low" alt="I'm an unimportant image!">

Fetch Priority isn't yet available in other browsers, however you can start using them right now to benefit anyone with a browser based on Chromium 101.

Browser support

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

Source

Firefox 99 includes the pdfViewerEnabled property of the Navigator interface. This property indicates if the browser supports inline display of PDF files.

if (!navigator.pdfViewerEnabled) {
  // The browser does not support inline viewing of PDF files.
}

Browser support

Chrome 94, Supported 94
Firefox 99, Supported 99
Edge 94, Supported 94
Safari 16.4, Supported 16.4

Source

Beta browser releases #

New betas in April were Chrome 102, Firefox 100, and Safari 15.5.

Chrome 102, Safari 15.5, and Firefox preview versions include the inert attribute. This removes elements from the tab order and accessibility tree if they are non-interactive. For example, an element that is currently offscreen or hidden.

Browser support

Chrome 102, Supported 102
Firefox, Not supported
Edge 102, Supported 102
Safari, Not supported

Source

Chrome 102 also includes the Local Font Access API, which allows access to the user's locally installed fonts.

These beta features will land in stable browsers soon.

Hero image by Jason Leung

New to the web platform in March

2022-03-31T00:00:00Z

Stable browser releases #

In March, Chrome 99, Chrome 100, Firefox 98, and Safari 15.4 became stable. This brought a whole batch of new features to the platform, and many of these additions meant that the feature became available in all three browser engines. In this post I've concentrated on those additions that give us interoperability cross-browser, but do check out the release notes to see all of the features added to each engine.

Chrome 99 and Safari 15.4 included Cascade Layers. The @layer at-rule defines a cascade layer, helping you to control specificity. They join Firefox, and so Cascade Layers is now available in all three browser engines. Find out more about Cascade Layers in Cascade layers are coming to your browser.

Browser support

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

Source

Chrome 100 includes the new value of plus-lighter for the CSS mix-blend-mode property. This value is useful when cross-fading two elements when all or a subset of pixels have the same values. You can read more about the problem this solves in Cross-fading any two DOM elements is currently impossible.

Browser support

Chrome 100, Supported 100
Firefox 99, Supported 99
Edge 100, Supported 100
Safari 9.1, Supported 9.1

Safari 15.4 includes the contain property, allowing for CSS containment.

Browser support

Chrome 52, Supported 52
Firefox 69, Supported 69
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

Also in Safari 15.4 is accent-color, which gives control over the accent color used on some form controls.

Browser support

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

Source

Firefox 98 and Safari 15.4 landed the <dialog> element, which represents a dialog box.

Browser support

Chrome 37, Supported 37
Firefox 98, Supported 98
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

Safari 15.4 also completed support for the :focus-visible pseudo-class. The implementation work on this was by Igalia.

Browser support

Chrome 86, Supported 86
Firefox 85, Supported 85
Edge 86, Supported 86
Safari 15.4, Supported 15.4

Source

Beta browser releases #

New betas in March were Chrome 101, and Firefox 99.

Chrome 101 beta includes hwb color notation. This specifies color according to its hue, whiteness, and blackness. As with other color notation, an optional alpha component specifies opacity.

h1 {
  color: hwb(194 0% 0% / .5) /* #00c3ff with 50% opacity */
}

Browser support

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

Source

Firefox 99 includes the pdfViewerEnabled property of the Navigator interface. This property indicates if the browser supports inline display of PDF files.

if (!navigator.pdfViewerEnabled) {
  // The browser does not support inline viewing of PDF files.
}

Browser support

Chrome 94, Supported 94
Firefox 99, Supported 99
Edge 94, Supported 94
Safari 16.4, Supported 16.4

Source

These beta features will land in stable browsers soon.

Hero image by Brandon Zack

Interop 2022: browsers working together to improve the web for developers

2022-03-03T00:00:00Z

For the first time ever, all major browser vendors, and other stakeholders, have come together to solve the top browsers compatibility issues identified by web developers. Interop 2022 will improve the experience of developing for the web in 15 key areas. In this article, find out how we got here, what the project focuses on, how success will be measured, and how you can track progress.

It all started in 2019 #

Back in 2019 Mozilla, Google, and others started a major effort to understand developers' pain points, in the form of the MDN Developer Needs Assessment surveys, and the deep-dive Browser Compatibility Report. These reports gave us detailed and actionable information to address top challenges for developers with the web platform, and led to the Compat 2021 effort.

Among other things, Compat 2021 led to creating a solid foundation for powerful features such as CSS grid (12% usage and steadily growing) and CSS flexbox (77% usage), including the gap property in flexbox, which solves a top pain point for developers when adopting new layout methods.

We were delighted to reach a score of over 90% across all implementations at the end of 2021!

What is Interop 2022? #

Interop 2022 is a benchmark, agreed on by representatives of three major browser implementations, and developed through a process of public nomination and review with input from supporters Apple, Bocoup, Google, Igalia, Microsoft, and Mozilla.

The benchmark focuses on 15 areas, identified by developers as being particularly troublesome when they are missing or have compatibility issues across browsers. All browser vendors have agreed to focus on these areas, and everyone involved is excited to get started on making the experience of developing for the web measurably better.

The 15 areas of focus #

The following features will be the focus of Interop 2022. They include 10 new areas, plus 5 carried over from Compat 2021. The new areas of focus are:

Cascade layers #

Cascade layers give web developers more control over the cascade. They provide a way to group selectors into layers, each with its own specificity. This means you don't need to order selectors carefully or create highly specific selectors to overwrite base CSS rules.

Color spaces and CSS color functions #

To use color functions in a design system, you currently need to rely on Sass, PostCSS, or calc() on HSL values. Color functions built into CSS mean that colors can be dynamically updated, and new color spaces remove the restriction to the sRGB gamut, and perceptual limitations of HSL.

There are two functions defined in CSS Color Level 5 that enable more dynamic theming on the web platform:

color-mix(): Takes two colors and returns the result of mixing them in a specified color space by a specified amount.
color-contrast(): Selects from a list of colors the color with the highest contrast to a specified single color.

These functions support expanded color spaces (LAB, LCH, and P3), and in addition to HSL and sRGB, they default to the uniform LCH color space.

New viewport units #

Difficulties dealing with viewport sizing are prominent in both the MDN Browser Compatibility Report 2020 and the new State of CSS 2021 survey. CSS Values and Units Level 4 adds new units for the largest, smallest, and dynamic viewport sizes, lv*, sv*, and dv*. These units will make it easier to create layouts that fill the visible viewport on mobile devices while taking the address bar into account.

Additionally, the cross vendor team behind Interop 2022 will collaborate on researching and improving the state of interoperability of existing viewport measurement features, including the existing vh unit.

Scrolling #

The 2021 Scroll Survey Report confirms that scrolling features and scrolling compatibility are difficult to implement and have many areas for improvement. We'll focus on scroll snap, scroll-behavior, and overscroll-behavior to help scrolling be more consistent and smooth across platforms.

We are also exploring new scroll snap feature proposals.

Subgrid #

The subgrid value of grid-template-columns and grid-template-rows means that a grid item that has display: grid applied can inherit the track definition from the part of the parent grid it is placed over.

For example, the following three card components have a header and footer aligned with the adjacent card headers and footers, even though each card has an independent grid. This pattern works because each card is an item that spans three rows of the parent grid, then uses subgrid to inherit those rows into the card.

See this on CodePen.

Also included #

CSS Containment (the contain property)
The <dialog> element
Form controls
Typography and Encodings: including font-variant-alternates, font-variant-position, the ic unit, and CJK text encodings
Web Compat, which focuses on differences between browsers that have caused site compatibility issues affecting end users

The following areas made great progress through the Compat 2021 project, but there is still room for improvement. Therefore, they have been included in Interop 2022, in order that the remaining issues can be addressed.

Aspect Ratio
Flexbox
Grid
Sticky Positioning
Transforms

Investigation efforts #

In addition to the 15 focus areas, Interop 2022 includes three investigation efforts. These are areas that are problematic and need improvement, but where the current state of the specifications or tests aren’t yet good enough to be able to score progress using test results:

Editing, contenteditable and execCommand
Pointer and Mouse Events
Viewport Measurement

Browser vendors and other stakeholders will collaborate on improving the tests and specifications for these areas, so that they could be included in future iterations of this effort.

Measuring success and tracking progress #

The existing web-platform-tests dashboard will be used to track the progress in the 15 focus areas. For each area, a set of tests have been identified. Browsers are then scored against these tests, giving a score for each area and an overall score for all 15 areas.

To follow along and track the progress, check out the Interop 2022 dashboard. Over the course of the year, you can follow along and see how the platform you build for is improving.

See all browser scores per focus area on wpt.fyi/interop-2022.

What will all this mean for developers? #

The goal of these multi-year interoperability efforts, in the form of Compat 2021, Interop 2022 and much more, is to fully acknowledge and address the pain points developers have experienced through for many years. And it's not a one-browser effort but rather a strong collaboration between all major browser vendors and friends for improving the web platform across the board.

In essence, the goal is to make the web platform more usable and reliable for developers, so that they can spend more time building great web experiences instead of working around browser inconsistencies.

Let us know what you think #

If you have feedback on the improvements made during Compat 2021, or on any of the features included in Interop 2022, we would love to hear from you. Which of these features will make the most difference to your work? What are you really excited about? File issues for the GitHub repo or let us know on Twitter.

More about Interop 2022 from:

New to the web platform in February

2022-03-02T00:00:00Z

Stable browser releases #

In February, Chrome 98 and Firefox 97 became stable.

Chrome 98 shipped the self.structuredClone method. It creates a deep clone of a value using the structured clone algorithm. Read more about structuredClone().

Browser support

Chrome 98, Supported 98
Firefox 94, Supported 94
Edge 98, Supported 98
Safari 15.4, Supported 15.4

Source

Firefox 97 includes Cascade Layers. The @layer at-rule defines a cascade layer, helping you to control specificity.

@layer framework {
  /* creates a new layer named framework */
}

Firefox is the first browser to land this in a release version. However, check out the section of this post on beta releases, as it won't be too long before this feature is available everywhere. Find out more about Cascade Layers in Cacade layers are coming to your browser.

Browser support

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

Source

Firefox also lands the scrollbar-gutter property. This property helps to remove layout shifts caused by a scrollbar appearing as content grows.

A scrollbar gutter is the space between the inner border edge and the outer padding edge. This is where a scrollbar will appear if needed. If no scrollbar is present, the gutter displays as an extension of the padding. The following CSS would add spacing accounting for the scrollbar size to both sides of the box, to keep the appearance symmetrical.

.container {
  scrollbar-gutter: stable both-edges;
}

Browser support

Chrome 94, Supported 94
Firefox 97, Supported 97
Edge 94, Supported 94
Safari, Not supported

Source

Chrome 98 supports COLRv1 color gradient vector fonts as an additional new font format. A color font contains glyphs with multiple colors in them, which can be for example an emoji or a country flag or a multi-colored letter.

Read more about this new font format in COLRv1 Color Gradient Vector Fonts in Chrome 98.

Beta browser releases #

New betas in February were Chrome 99, and Firefox 98. Safari Beta 15.4 is still ongoing, I covered some of the things included last month.

Chrome 99 includes Cascade Layers, with Cascade Layers also in Safari Beta 15.4 we can expect to see this feature in all evergreen browsers very soon.

Also in Chrome 99 are several new attributes for CanvasRenderingContext2D, and a new showPicker() method on HTMLInputElement which is a way to show a browser picker for date, time, color, and files.

In Firefox 98 you'll find the <dialog> element. Another feature that will be in all evergreen browsers once the Firefox and Safari betas become stable.

All of these beta features will land in stable browsers soon.

Hero image by Erfan Moradi

New to the web platform in January

2022-02-01T00:00:00Z

Stable browser releases #

In January, Chrome 97 and Firefox 96 became stable.

Firefox 96 shipped the color function hwb(). This function expresses a color by hue, whiteness, and blackness.

Browser support

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

Source

Also in Firefox 96 is the CSS color-scheme property. This property gives you a way to indicate the color schemes an element can be rendered in. For example, to indicate that .widget can be rendered in the operating system's light or dark modes, use the following CSS.

.widget {
  color-scheme: light dark;
}

With color-scheme landing in Firefox, this means the property is available in Chrome, Firefox, and Safari.

Browser support

Chrome 81, Supported 81
Firefox 96, Supported 96
Edge 81, Supported 81
Safari 13, Supported 13

Source

Beta browser releases #

The betas for January were Chrome 98, Firefox 97, and Safari 15.4 Beta 1.

Read more about this new font format in COLRv1 Color Gradient Vector Fonts in Chrome 98.

Also included is the structuredClone() method for making deep copies of objects, and the CSS media queries dynamic-range and video-dynamic-range. Find more features to test in the Chrome 98 Beta post.

Chrome 98 DevTools brings you a whole collection of new features including the new Full Accessibility Tree.

Firefox 97 Beta supports the cap and ic units for length, and also implements the scrollbar-gutter property.

There is a whole collection of good things included in Safari 15.4 Beta. Features include implementation of the ::backdrop pseudo-element, :focus-visible pseudo-class, the accent-color property, and CSS Containment with the contain property. This beta also includes the HTML <dialog> element, the lazy attribute on images to enable lazy-loading, plus support for Web App Manifest icons.

All of these beta features will land in stable browsers soon.

Hero image by ian dooley.

Community highlight: Lynn Fisher

2021-12-30T00:00:00Z

This post is part of Designcember. A celebration of web design, brought to you by web.dev.

Lynn Fisher is an American artist known for her work on the web. After attending art school in Arizona, she began working as a designer and CSS developer in software consulting. She has spent her career pursuing cross-discipline endeavors, experimenting with the web as a creative medium, and creating fun, niche web projects. She currently works with the creative folks at Netlify. I talked to her about her many fun projects.

Rachel What was your route into web design and development?

Lynn: In high school, a friend of mine introduced me to GeoCities. I remember having such a "my eyes are finally open" moment realizing I could make websites. My first site was a fansite for a local band in Phoenix that I was obsessed with. Over the next few years I learned HTML and CSS via the LiveJournal to MySpace pipeline and made lots of sites for local bands and artists. I learned just enough to get my first job as an "HTML Production Assistant" at a web agency after college.

After that, I learned on the job and via the design and dev community sharing knowledge and resources. I studied fine art in school which did help me develop confidence in my creative voice and introduced me to critique, but it wasn't formal design training. I was able to improve over time with practice and learning from coworkers and folks in the industry.

Rachel: How did you get started creating single div CSS artworks?

Lynn: At CSSConf 2013, I saw Lea Verou give her Humble Border-radius talk and it was another eye-opening moment. There was this whole world of artistic potential in CSS properties I was already using and I was so excited to explore and experiment. I went home and made WhyAZ and drew all the illustrations with CSS. At the time, each illustration was made of two HTML elements (which followed a lot of icon system markup that was floating around). So it looked something like:

<div class="icon">
  <span class="clock"></span>
</div>

I then wanted to see how complex I could make illustrations with only one HTML element. Turned out to be a really fun, super-constrained challenge that I could do with a couple hours here or there. So I bought a domain and started adding them to a site and now it‘s been almost eight years! It's still really fun to try and stretch the medium and to work on my illustration skills at the same time.

Rachel: You have so many cool projects! Do you always have something in your mind that you would like to build?

Lynn: Thank you! I keep a backlog of rough ideas that might make fun projects: things I'm interested in, patterns I start noticing, shows and movies I'm obsessing over. Sometimes it takes a long time for an idea to turn into a clear project. I had "fake movies in real movies" in my backlog for a few years before the Nestflix fake streaming service developed into an executable project. I don't keep a schedule, but I usually have an idea that feels ready once I'm looking for something new to work on.

Rachel: Your yearly refreshes have become something of an event. Do you feel a pressure to do these now, or is it still a lot of fun?

You can see an archive of all the designs

Lynn: It's still really fun and a project I look forward to. It's the one project I know I can make as weird as I want. It's always a good opportunity to experiment, try something new, and learn whatever new techniques gained traction that year. And because it gets replaced each year, it's really helped me to strengthen my ability to deal with change. It forces me to move on, even if I feel a particular affinity for any one version.

I do feel pressure though! It's easy to feel like each version needs to be more creative, more innovative than the previous ones. It can be stressful! It does push me to be ambitious though and I appreciate that. While I have the time and energy, I'm happy to try and keep raising the bar.

Rachel: You've recently started working at Netlify, how has the shift from client work to working on a product been?

Lynn: So I'm working on the marketing design team at Netlify, so in a lot of ways the work is really similar to the agency work we would do for product teams. The biggest difference is being able to see so much more of the big picture. Sometimes when you're hired as an outside agency to work on a project, your view can be limited to those specific goals and timelines. Not that that's a bad thing, though. Focus is super valuable! Being inside the product company opens up so much information and you get to see how different parts of the business work together, how competing goals are prioritized, and how individual projects effectively contribute (or don't) to long term revenue and growth goals.

I guess maybe my experience has been more like going from an outside agency to an in-house team. I do love the variety client work offers, but it's been fun digging into deeply understanding Netlify as a platform and the Jamstack ecosystem.

Rachel: What feature or functionality would you love to see added to CSS?

Lynn: A lot of things I've always wanted are being actively worked on which is really cool. Container queries and the :has() pseudo-class are at the top of the list.

Interpolation timelines feel like they could be super useful. Scott Kellum recently talked me through how they might help with some issues I've been running into with my responsive experiments and it's super cool.

I often reach for JS to give me the height of an element when it's not explicitly set, so it might be cool if CSS could do that on its own. I'm sure that's complicated though!

Rachel: Who else is doing really interesting, fun, or creative work on the web right now?

Lynn: So many people are doing fun work! Some I'm loving lately:

Neal Agarwal's neal.fun is a treasure trove of delightful web projects.
I love the fun and creative SVG work from Cassie Evans.
Jhey Tompkins does really fun CSS demos.
I love the project Style Stage (a next generation CSS Zen Garden) from Stephanie Eckles.
Mind-blowing CSS artwork from Ben Evans and Diana Smith.
Charlie Gerard is making extremely cool hands-free and motion-controlled demos.
George Francis is creating beautiful generative artwork.

You can find out what Lynn creates next via her portfolio website at lynnandtonic.com, or by following her on Twitter.

Community highlight: Miriam Suzanne

2021-12-24T00:00:00Z

This post is part of Designcember. A celebration of web design, brought to you by web.dev.

Miriam Suzanne is an author, artist, and web developer in Denver, Colorado. She’s a co-founder of OddBird (a web agency), staff writer for CSS Tricks, member of the Sass core team, and W3C Invited Expert on the CSS Working Group. Lately she's been focused on developing new CSS features like Cascade Layers, Container Queries, and Scope. Offline, Miriam is a published novelist, playwright, and musician. We talked about her work with Sass and CSS.

Photo credit From the Hip Photo

Rachel: I first learned about your work due to your grid framework Susy, what led you to create that?

Miriam: Back in 2008, layout on the web was a very different experience. Developers had moved away from table layout to more semantic (but still hacky) floated grids. There was a boom in one-size-fits-all 12-column "grid frameworks"–providing a pre-defined (usually static) grid with a set of pre-defined CSS classes. If you needed anything more customizable, you were on your own. It was clear that websites needed to become more responsive, but media-queries weren't available yet, and there were a load of browser compatibility issues around fluid floats.

I was using Natalie Downe's CSS Systems approach, which was clever about responding to both font and viewport sizes, but I was frustrated by all the repetitive math and browser hacks required. At the same time, Sass was starting to get some attention, and it fit perfectly for what I needed. The first draft of Susy was very simple: just a couple mixins to do the math and add the hacks I needed. The goal was to be minimal, and only output the essential code. Totally customizable grids, without any predefined classes.

Rachel: How did you make the shift from working on a CSS preprocessor to working on CSS specifications? Do you think working on the preprocessor was a good background for specification writing?

Miriam: In my experience there is a lot of overlap, and I'm still very active on both sides of that divide. But I think that's largely thanks to the Sass team in particular, led by Natalie Weizenbaum, which takes a very long-term view—trying to develop tools that integrate smoothly with developing web standards. Pushing beyond one-size-fits-all "opinionated" solutions and building for long-term flexibility is essential when you are thinking about the future of core web standards.

How can we build tools that respect the diversity of developer needs and approaches, while still encouraging and facilitating accessibility and other important considerations?

Rachel: We’ve got a bunch of stuff coming into CSS that essentially replaces functionality that was traditionally part of Sass. Are there strong reasons to still use something like Sass?

Miriam: Yes, for some people—but there's no universal answer here. Take variables for example. Sass variables are lexically scoped, and compiled on the server, with organized data structures like lists and objects, color manipulation, etc. That's great for design system logic that doesn't need to run in the browser.

CSS variables have some overlap, they can also store values, but they provide an entirely different set of cascade-based strengths and weaknesses. Sass can't handle custom properties, and CSS can't really handle structured data. Both are useful, and both are powerful—but your specific needs may vary.

I think it's great when people can eliminate tools that they no longer need, and some projects might not require both server- and client-side variables. Wonderful! But it's too simple to assume that means they are identical, and one simply replaces the other. There will always be use-cases for some design logic to happen server-side, and some to happen client-side—even if we get to the point where the languages provide essentially the same features. Pre-processors are with us for the long term.

Rachel: Is there anything that has surprised you as you’ve got more involved in the work of creating standards, or anything that you think folk generally might not be aware of about the process?

Miriam: Before getting involved, the standards process felt like a mysterious and magical black box, and I wasn't sure what to expect. I was scared that I might not have enough knowledge of browser-internals to contribute, but the reality is they don't need more browser engineers. They need more developers and designers who are building websites and applications in the wild.

I was surprised to find that very few of the people involved are primarily focused on standards, but also very few of them are primarily developing or designing websites. The W3C is made up of 'volunteers' from member organizations (often paid by those orgs, but not as their primary job) and membership isn't cheap. That skews the participants away from day-to-day designers and developers, especially those of us doing client work at small agencies, or freelance. My role as an Invited Expert would be totally volunteer, an expensive hobby, if I hadn't found outside funding for that work.

In reality, the process is quite open and public and needs developer involvement–but there are always so many conversations happening at once, it can be hard to find your place. Especially if it's not your day job.

Rachel: Container queries have been the holy grail for a lot of web developers for many years. I’m very excited about the fact that we’re getting them. I feel as if a lot of folk are thinking about the utility of container queries—do you feel they have potential to unlock more creativity too?

Miriam: Absolutely, though I don't see those as entirely separate. We all have limited time, and we're trying to write maintainable and performant code. When something is hard to do practically, we are less likely to get creative with what's possible.

Still, the web industry is now dominated by large corporate interests, and so those business concerns always get more airtime than web artists. And I think we lose a lot if we ignore web creativity as a primary use-case for features. I've been very excited to see some of the CSS art folks playing with the container query prototype. Jhey Tompkins built a particularly clever and interactive demo of CSS venetian blinds as commentary on the old anti-CSS meme. I think there's a lot more to explore in that space, and I can't wait to see what else people come up with.

The conversation has also focused on size-based queries, as the original use-case, but I'm excited to see what people do with style queries–the ability to write conditional styles based on the value of a CSS property or variable. It's an extremely powerful feature, and so far mostly unexplored. I think it opens up even more creative opportunities!

Rachel: Is there anything that we can’t do (or have an upcoming way to do) in CSS that you think would be useful?

Miriam: I'm very excited about some other specs I've been working on. Cascade layers will give authors more control over specificity issues, and Scope should help with more precise selector targeting. But both of those are high-level architectural concerns. The artist in me is more excited for things like CSS toggles, a declarative way to create interactive styles, or container 'timelines', allowing us to smoothly transition values between media or container breakpoints. That has very practical implications for responsive typography, but would also open up a lot of creative opportunities for responsive art and animation.

Rachel: Who else is doing really interesting, fun, or creative work on the web right now?

Miriam: Oh, I'm not even sure how to answer that, there are so many people doing creative work in such different areas. There's a lot of exciting standards work in progress from both the CSSWG and Open-UI, including some of your work on fragmentation. But I often find the most inspiration from web artists, and how people are putting these tools into production, in ways that aren't directly tied to commerce. People like Jhey, or Lynn Fisher, or Yuan Chuan, or many others who are pushing the boundaries of what web technologies can do visually and interactively. Even people doing more business-driven work can learn a lot from their artistic techniques.

I also appreciate the more conceptual web art of people like Ben Grosser, who keeps pushing us to reconsider what we want from the web, and social media in particular. Check out his new minus.social, for example.

Rachel: Keep up with Miriam’s work on CSS at css.oddbird.net and find out what else she is up to via her website at miriam.codes and Twitter @TerribleMia.

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.

Community highlight: Chen Hui Jing

2021-12-10T00:00:00Z

This post is part of Designcember. A celebration of web design, brought to you by web.dev.

Chen Hui Jing is a self-taught designer and developer living in Singapore, with an inordinate love for CSS, as evidenced by her blog (which is mostly about CSS) and her tweets (which are largely about typography and the web). She used to play basketball full-time and launched her web career during downtime between training sessions, and hopes to be able to climb outdoors one day. I talked to her about CSS, and in particular non-English writing systems.

Rachel: What was your route into web design and development?

Hui Jing: When I was living in the dorms while playing basketball full-time, I had a bit more experience with computers than my peers, and my coach (bless him) thought that I could do something about our association website that hadn't been updated in years. I had zero idea what web development was, but I thought I had enough spare time to figure it out. It was more enjoyable than I expected and many years later, I'm still here.

Rachel: And how did you get into CSS in particular?

Hui Jing: I'm a very visual person by nature, and there's something about being able to give "instructions" to the browser and immediately see that reflected on the screen that really appealed to me. It felt much more intuitive to me than programming logic for applications. I got serious about the web at a time when developments in the world of CSS were starting to pick up speed, so there were a lot of experimental properties that were not widely used. It felt very exciting to discover new features that few people knew about.

Working with vertical writing modes #

Rachel: You've written a lot about vertical writing modes in CSS, and the fun bugs you find when working with vertical writing. Do you have any favorite bugs we should all go and star?

Hui Jing: There were a few when I checked back in May this year, but, most of them have been resolved except one: Chromium has an issue with the Devtools overlay in vertical writing mode. I think this is a testament to how this evergreen browser update cycle is really pushing web development forward.

Rachel: It’s great to hear that these issues are being fixed. Do you think playing with writing-mode has more use cases than simply typesetting vertical text?

Hui Jing: Oh yes, definitely. Even though typesetting East Asian scripts is the primary use-case of writing mode, I think other writing systems can make use of writing-mode to implement vertical layouts, like the style we often see in print magazines. To me, combinations of CSS properties are what makes CSS so powerful, so writing-mode together with flexbox and grid give us a fairly large number of permutations for layout directions, from a page level boxes down to individual characters in the text. I think this unlocks possibilities and more creativity as folks realize the scope of what is possible for web design moving forward. I hope to see layouts and designs on the web that I couldn't have imagined just a few years ago.

Rachel: I'm often asked whether I think everyone should use logical properties and values now, or if it will become the default. How would you answer that?

Hui Jing: Personally, I hope it would become the default, because from a practical perspective, it would make multi-script website development much easier. As to whether it WILL become the default, that's much harder to answer.

A challenge for logical properties is that it is "replacing" an established syntax that has been in use for many years, plus the fact that support for scripts that are not the default, horizontal top-to-bottom only got much better in recent years. Content on the web is still predominantly in English, so the case for using logical properties is less strong in this context. I think a larger push for non-English speakers to create content in their respective languages for the web would forward this cause. Also, if supporting multiple languages becomes a greater priority, the value of using logical properties would become even more apparent.

New features in CSS #

Rachel: What feature or functionality would you love to see added to CSS?

Hui Jing: I've been following Miriam Suzanne's work on container queries for a while, and the parts of the specification that haven't been developed yet for Style and State container features are quite exciting, because they really expand the concept of responsive design. We can potentially get our designs and layouts to respond to more than just the size of our viewport. So I hope the containment module is something the different browser vendors can agree on and we can get wider support for this in the near future.

Inspiring people to follow #

Rachel: Who else is doing really interesting, fun, or creative work on the web right now?

Hui Jing: I'm always drawn to people who do CSS art. And there are folks whom I have been a fan of for years, like Yuan Chuan and his generative CSS creations, Ben Evans who does mind blowing CSS artwork and Ana Tudor with her deep dives into really clever techniques. Recently I've come across Codepens by Julia Miocene and Jackie Zen that have beautiful CSS animations as well.

Rachel: You can read more from Chen Hui Jing on her site at chenhuijing.com.

Community highlight: Bramus Van Damme

2021-12-04T00:00:00Z

This post is part of Designcember. A celebration of web design, brought to you by web.dev.

Bramus speaking at Frontend United.

Rachel: What was your route into web development?

Bramus: As a kid, I always liked to tinker with things. I would spend days playing with my LEGO® bricks, building my own fantasy world and objects from scratch.

When we got a computer at home—an unusual device to own in the 1990s—I soon traded in the physical toys with computer games. I wasn't an avid gamer though; I don't think I ever finished a game entirely. Instead of finishing the games, I found myself modding them.

In 1997, while looking up information about those games and tools, I also discovered view-source. Curious to know how things were built, I started collecting HTML-snippets of the sites that I visited. Combining those snippets with Frontpage Express (an application that came with Internet Explorer 4 and 5), I soon created my very first web pages with info about myself. Those pages never got published, they only existed on one of the floppy disks I carried around.

From that time on I continued to become more interested in computers and the web. This interest led me to flunk a year in high school on purpose, so that I could switch major from economics to IT—I knew I wanted to pursue a career in IT. By 2002 I was in college, where I properly learned HTML and took my first steps into CSS and JavaScript. During those three years I realized that the web was my true passion, and in 2005, fresh out of college, I took on my first job as a professional web developer.

On being a front and backend developer #

Rachel: I spotted on your site that you are both a front and backend developer, I followed a similar path being originally a Perl, then a PHP and MySQL developer. Do you feel more excited by one side or the other? Do you think the possibility of being a hybrid developer is vanishing given the complexity of learning just one part of the stack?

Bramus: Throughout my career I've constantly been floating between backend and frontend. One year I would find myself elbow-deep into JavaScript and React (and even React Native), only to be creating Terraform scripts and Docker containers the year after. I like mixing the two, yet my passion always lay with the frontend, and CSS specifically.

In the early days of tinkering with the web, one simply was the "webmaster" and did it all. As the scope of the work was pretty limited back then, it was quite easy to keep up. Having seen both frontend and backend explode over the past 20 years, it became harder and harder to maintain expertise across the field. That's why I decided to mainly focus on frontend again in 2020.

Rachel: Why did you start writing about CSS in particular?

Bramus The content on my blog has always been a reflection of the projects that I'm working on. Therefore a mix of front and backend posts.

Attending conferences such as Fronteers Conference and CSS Day helped me to write in-depth frontend posts. For example, seeing Tab Atkins-Bittner talk about CSS Custom Properties in 2013—years before they even were an official thing—or you (Rachel Andrew) explaining Grid to us in 2015 were events that directly led me to write about them. At the time, I was a lecturer in web and mobile development at a technical university, so I had a very good reason to pay attention, as later on I'd be teaching my own students about those subjects.

In 2019, I started to closely monitor the CSSWG and participate in discussions. Browsers working on features behind feature flags meant that I was able to experiment with the things I read about, even before they shipped. This was then reflected through the contents of my blog.

Advice for new writers #

Rachel: What would be your advice to someone who wants to start writing about tech?

Bramus: Don't hesitate and simply do it. Even when it's about a single line of CSS, or if it's 1 post per year, or if you "only" have 5 subscribers: do it. Scratch your own itch, and write the article you wanted to find yourself. Through writing on my blog I not only challenged myself to learn about technologies in finer detail, but also opened doors along the way—both personally and professionally.

Don't overly rely on external services such as Medium or Twitter, but try and have your own place on the web. In the long run it'll pay off. You don't need any fancy CMS, build pipelines, or comments system, to get started. All you need is a text editor and some time to spare. HTML, combined with a simple stylesheet, can get you a long way.

New features in CSS #

Rachel: You have written about lots of the new features that are being developed in the CSSWG and in browsers, what do you think is the most exciting for the future of the web? Which do you think will have the most immediate impact in your own professional work?

Bramus: Along with many developers I'm pretty excited about CSS Container Queries. Other upcoming features—such as Cascade Layers and Scroll-linked Animations—also excite me, but Container Queries will definitely have the biggest impact. They will allow us to transition from responsive pages to responsive components.

Rachel: What feature or functionality would you love to see added to CSS?

Bramus: Scroll-linked Animations is one of the features that I would like to see move forward. Right now it's only an Editor's Draft. Being able to define hardware-accelerated scrolling without relying on JavaScript is something that totally fits into my mental model of progressive enhancement and the rule of least power.

CSS Nesting is also my radar. It took more than two years since its first Editor's Draft, but I was very glad to see its First Public Working Draft get released last summer.

Apart from these bigger features, I can definitely appreciate smaller tweaks and additions. Things like accent-color definitely put a smile on my face, as they make my life as a developer easier.

Recommendations for inspiring web people to follow #

Rachel: Who else is doing really interesting, fun, or creative work on the web right now?

Bramus: That's a very difficult question to answer, so many people are producing content that amazes and inspires me. For example, Adam Argyle and his GUI challenges, the projects from Stephanie Eckles, blog posts by Michelle Barker, videos from Kevin J. Powell, the work Miriam Suzanne is doing in the CSS Working Group, podcasts from Una Kravets, articles by Jake Archibald, Jake and Surma's HTTP 203, George Francis' Houdini work, and Temani Afif's posts. These people and their projects, and the many others that I'm forgetting right now, have my respect and admiration.

I think the most influential person throughout my career was Jeremy Keith. His teaching us about semantic HTML, progressive enhancement, and resilience were eye-opening moments to me. It's a message I gave to my own students, and still like to spread today. In times where JavaScript is eating the world and junior developers somehow seem to have skipped out on the fundamentals of the web, his posts and talks are more relevant than they ever were before.

Rachel: You can follow Bramus on Twitter, and on his blog at bram.us.

Everything announced at Chrome Dev Summit 2021

2021-11-03T00:00:00Z

This post rounds up all the key announcements from the 2021 Chrome Dev Summit, with the links you need to find out more.

Make the web more interoperable #

Web compatibility is one of the biggest challenges for web developers, and so Google has been working with other browser vendors to fix the top five compatibility pain points: flexbox, grid, position: sticky, aspect-ratio, and transforms.

The work has already led to improvements in these key areas. You can read about those in the Compat 2021 mid-year update.

Allow new classes of applications to run on the web #

Project Fugu is an effort that aims to allow new classes of applications to the web. You can keep up to date with progress on the Fugu APIs at fugu-tracker.web.app.

Adobe recently announced that they are bringing Photoshop to the web, a feat made possible by collaboration between Adobe, Google, and web standards organizations. Find out more in the post Photoshop's journey to the web.

Ensure privacy #

Many common web functions rely on third-party cookies and other cross-site tracking mechanisms that weren’t designed with privacy in mind, making it difficult for developers to meet the growing need for privacy.

We are working with the web community and industry stakeholders to develop new privacy-preserving technologies to support the ecosystem, with the aim to phase out third-party cookies and reduce covert tracking and browser fingerprinting.

Find out about this work on the Privacy Sandbox site. We also have information and guides to the proposals for developers, a monthly update or changes and progress, and information on the timeline and testing details for changes to the user-agent string.

Improve Core Web Vitals #

We've been working with the developers of popular JavaScript frameworks to improve Core Web Vitals, and as part of that work have identified two new metrics that we'd love your feedback on. Read about overall responsiveness and smoothness, then let us know what you think.

Also announced is an updated version of PageSpeed Insights, a new Recorder Panel for Chrome DevTools, currently available in Canary, and a new user flow API for Lighthouse.

Enable new web platform features #

RenderingNG is an ambitious refactoring of Chromium's rendering engine, a project that is fixing long standing bugs in Chrome, and also unlocking new features. This includes one feature that has been the top request from web developers for many years—container queries.

Container queries look familiar to anyone who has ever used a media query to create a responsive design. However, inside of querying the viewport size, they allow you to query the size of the container your component is in. Google has been working on a trial implementation of the emerging specification, behind the #enable-container-queries flag in Chrome.

Read a blog post covering RenderingNG in detail, or watch this video to get all the key details of how this work unlocks implementation of features that were once thought impossible to land.

Help you to create beautiful and responsive sites #

The new responsive design is so much more than just screen—or container—size. You can learn how to create modern responsive sites in our course Learn Design. The first five modules launch today, the rest will be posted over the coming weeks.

New CSS properties have landed in Chrome and other browsers this year to make creating beautiful experiences easier. Find out more about accent-color and size-adjust.

To help you quickly take advantage of new CSS, we have launched a set of layout patterns. These will give you a robust starting point for many common interface patterns.

Provide courses to help you learn web technology #

In addition to Learn Design, we are launching new modules for Learn CSS, our comprehensive CSS course launched earlier this year.

We have also developed a complete course helping you to design functional and accessible forms—Learn Forms. Along with these courses, you can find the first few modules of Learn PWA.

Examples of high-performance CSS animations

2020-10-23T00:00:00Z

In this post find out how some popular animations found on CodePen have been created. These animations all use the performant techniques discussed in other articles in this section.

See Why are some animations slow? to learn the theory behind these recommendations, and the Animations Guide for practical tips.

Wizard loading animation #

View Wizard loading animation on CodePen

This loading animation is built entirely with CSS. The image plus all of the animation has been created in CSS and HTML, no images or JavaScript. To understand how it was created and how well it performs you can use Chrome DevTools.

Inspect the animation with Chrome DevTools #

With the animation running, open the Performance tab in Chrome DevTools and record a few seconds of the animation. You should see in the Summary that the browser is not doing any Layout or Paint operations when running this animation.

The summary after profiling the wizard animation.

To find out how this animation was achieved without causing layout and paint, inspect any of the moving elements in Chrome DevTools. You can use the Animations Panel to locate the various animated elements, clicking on any element will highlight it in the DOM.

Viewing and selecting items in the Chrome DevTools Animation Panel.

For example select the triangle, and watch how the box of the element transforms during its journey into the air, as it spins, and then returns to the start position.

Video showing how we can track the path of the triangle in Chrome DevTools.

With the element still selected look at the Styles Panel. There you can see the CSS which draws the shape of the triangle, and the animation being used.

How it works #

The triangle is created by using the ::after pseudo-element to add generated content, using borders to create the shape.

.triangle {
    position: absolute;
    bottom: -62px;
    left: -10px;
    width: 110px;
    height: 110px;
    border-radius: 50%;
}

.triangle::after {
    content: "";
    position: absolute;
    top: 0;
    right: -10px;
    width: 0;
    height: 0;
    border-style: solid;
    border-width: 0 28px 48px 28px;
    border-color: transparent transparent #89beb3 transparent;
}

The animation is added with the following line of CSS,

animation: path_triangle 10s ease-in-out infinite;

Staying in Chrome DevTools you can find the keyframes by scrolling down the Style Panel. There you will find that the animation is created by using transform to change the position of the element and rotate it. The transform property is one of the properties described in the Animations Guide, which does not cause the browser to do layout or paint operations (which are the main causes of slow animations).

@keyframes path_triangle {
  0% {
    transform: translateY(0);
  }
  10% {
    transform: translateY(-172px) translatex(10px) rotate(-10deg);
  }
  55% {
    transform: translateY(-172px) translatex(10px) rotate(-365deg);
  }
  58% {
    transform: translateY(-172px) translatex(10px) rotate(-365deg);
  }
  63% {
    transform: rotate(-360deg);
  }
}

Each of the different moving parts of this animation uses similar techniques. The result is a complex animation which runs smoothly.

Pulsating Circle #

View Pulsating Circle on CodePen

This type of animation is sometimes used to draw attention to something on a page. To understand the animation you can use Firefox DevTools.

Inspect the animation with Firefox DevTools #

With the animation running, open the Performance tab in Firefox DevTools and record a few seconds of the animation. Stop the recording, in the waterfall you should see that there are no entries for Recalculate Style. You now know that this animation does not cause style recalculation, and therefore layout and paint operations.

The Firefox DevTools Waterfall.

Staying in Firefox DevTools inspect the circle to see how this animation works. The <div> with a class of pulsating-circle marks the position of the circle, however it does not draw a circle itself.

.pulsating-circle {
    position: absolute;
    left: 50%;
    top: 50%;
    transform: translateX(-50%) translateY(-50%);
    width: 30px;
    height: 30px;
}

The visible circle and animations are achieved using the ::before and ::after pseudo-elements.

The ::before element creates the opaque ring that extends outside of the white circle, using an animation called pulse-ring, which animates transform: scale, and opacity.

.pulsating-circle::before {
    content: '';
    position: relative;
    display: block;
    width: 300%;
    height: 300%;
    box-sizing: border-box;
    margin-left: -100%;
    margin-top: -100%;
    border-radius: 45px;
    background-color: #01a4e9;
    animation: pulse-ring 1.25s cubic-bezier(0.215, 0.61, 0.355, 1) infinite;
}

@keyframes pulse-ring {
  0% {
    transform: scale(0.33);
  }
  80%, 100% {
    opacity: 0;
  }
}

Another way to see which properties are being animated is to select the Animations panel in Firefox DevTools. You will then see a visualization of the animations being used, and the properties that are being animated.

With the ::before pseudo-element selected we can see which properties are animating.

The white circle itself is created and animated using the ::after pseudo-element. The animation pulse-dot uses transform: scale to grow and shrink the dot during the animation.

.pulsating-circle::after {
  content: '';
  position: absolute;
  left: 0;
  top: 0;
  display: block;
  width: 100%;
  height: 100%;
  background-color: white;
  border-radius: 15px;
  box-shadow: 0 0 8px rgba(0, 0, 0, 0.3);
  animation: pulse-dot 1.25s cubic-bezier(0.455, 0.03, 0.515, 0.955) -0.4s infinite;
}

@keyframes pulse-dot {
  0% {
    transform: scale(0.8);
  }
  50% {
    transform: scale(1);
  }
  100% {
    transform: scale(0.8);
  }
}

An animation like this could be used in various places in your application, it's important that these small touches don't impact the overall performance of your app.

Pure CSS 3D Sphere #

View Pure CSS 3D Sphere on CodePen

This animation seems incredibly complicated, however it uses techniques that we have already seen in the previous examples. The complexity comes from animating a large number of elements.

Open Chrome DevTools and select one of the elements with a class of plane. The sphere is made up of a set of rotating planes and spokes.

The plane appears to be rotating.

These planes and spokes are inside a wrapper <div>, and it is this element which is rotating using transform: rotate3d.

.sphere-wrapper {
  transform-style: preserve-3d;
  width: 300px;
  height: 300px;
  position: relative;
  animation: rotate3d 10s linear infinite;
}

@keyframes rotate3d {
  0% {
    transform: rotate3d(1, 1, 1, 0deg);
  }
  25% {
    transform: rotate3d(1, 1, 1, 90deg);
  }
  50% {
    transform: rotate3d(1, 1, 1, 180deg);
  }
  75% {
    transform: rotate3d(1, 1, 1, 270deg);
  }
  100% {
    transform: rotate3d(1, 1, 1, 360deg);
  }
}

The dots can be found nested inside the plane and spoke elements, they use an animation which uses transform to scale and translate them. This creates the pulsing effect.

The dot rotates with the sphere and pulses.

.spoke-15 .dot,
.spoke-21 .dot {
  animation: pulsate 0.5s infinite 0.83333333s alternate both;
  background-color: #55ffee;
}

@-webkit-keyframes pulsate {
  0% {
    transform: rotateX(90deg) scale(0.3) translateZ(20px);
  }
  100% {
    transform: rotateX(90deg) scale(1) translateZ(0px);
  }
}

The work involved in creating this animation has been to get the timing right, to create the turning and pulsing effect. The animations themselves are quite straightforward, and use methods which perform very well.

You can see how this animation performs by opening Chrome DevTools and recording Performance while it is running. After the initial load, the animation is not triggering Layout or Paint, and runs smoothly.

Conclusion #

From these examples you can see how animating a few properties using performant methods can create some very cool animations. By defaulting to the performant methods described in the Animations guide you can spend your time creating the effect you want, with fewer concerns about making the page slow.

How to create high-performance CSS animations

2020-10-06T00:00:00Z

This guide teaches you how to create high-performance CSS animations.

See Why are some animations slow? to learn the theory behind these recommendations.

Browser compatibility #

All of the CSS properties that this guide recommends have good cross-browser support.

Move an element #

To move an element, use the translate or rotation keyword values of the transform property.

For example to slide an item into view, use translate.

.animate {
  animation: slide-in 0.7s both;
}

@keyframes slide-in {
  0% {
    transform: translateY(-1000px);
  }
  100% {
    transform: translateY(0);
  }
}

Items can also be rotated, in the example below 360 degrees.

.animate {
  animation: rotate 0.7s ease-in-out both;
}

@keyframes rotate {
  0% {
    transform: rotate(0);
  }
  100% {
    transform: rotate(360deg);
  }
}

Resize an element #

To resize an element, use the scale keyword value of the transform property.

.animate {
  animation: scale 1.5s both;
}

@keyframes scale {
  50% {
    transform: scale(0.5);
  }
  100% {
    transform: scale(1);
  }
}

Change an element's visibility #

To show or hide an element, use opacity.

.animate {
  animation: opacity 2.5s both;
}

@keyframes opacity {
  0% {
    opacity: 1;
  }
  50% {
    opacity: 0;
  }
  100% {
    opacity: 1;
  }
}

Avoid properties that trigger layout or paint #

Before using any CSS property for animation (other than transform and opacity), determine the property's impact on the rendering pipeline. Avoid any property that triggers layout or paint unless absolutely necessary.

Force layer creation #

As explained in Why are some animations slow?, by placing elements on a new layer they can be repainted without also requiring the rest of the layout to be repainted.

Browsers will often make good decisions about which items should be placed on a new layer, but you can manually force layer creation with the will-change property. As the name suggests, this property tells the browser that this element is going to be changed in some way.

In CSS this property can be applied to any selector:

body > .sidebar {
  will-change: transform;
}

However, the specification suggests this approach should only be taken for elements that are always about to change. If the above example was a sidebar the user could slide in and out, that might be the case. Some items on your page may not frequently change, and so it would be better to apply will-change using JavaScript at a point where it becomes likely the change will occur. You'll need to make sure to give the browser enough time to perform the optimizations needed and then remove the property once the changing has stopped.

If you need a way to force layer creation in one of the rare browsers that doesn't support will-change (most likely Internet Explorer at this point), you can set transform: translateZ(0).

Debug slow or janky animations #

Chrome DevTools and Firefox DevTools have lots of tools to help you figure out why your animations are slow or janky.

Check if an animation triggers layout #

An animation that moves an element using something other than transform, is likely to be slow. In the following example, I have achieved the same visual result animating top and left, and using transform.

Don't

.box {
  position: absolute;
  top: 10px;
  left: 10px;
  animation: move 3s ease infinite;
}

@keyframes move {
  50% {
     top: calc(90vh - 160px);
     left: calc(90vw - 200px);
  }
}

.box {
  position: absolute;
  top: 10px;
  left: 10px;
  animation: move 3s ease infinite;
}

@keyframes move {
  50% {
     transform: translate(calc(90vw - 200px), calc(90vh - 160px));
  }
}

You can test this in the following two Glitch examples, and explore performance using DevTools.

Before.
After.

Chrome DevTools #

Open the Performance panel.
Record runtime performance while your animation is happening.
Inspect the Summary tab.

If you see a nonzero value for Rendering in the Summary tab, it may mean that your animation is causing the browser to do layout work.

The animation-with-top-left example causes rendering work.

The animation-with-transform example does not cause rendering work.

Firefox DevTools #

In Firefox DevTools the Waterfall can help you to understand where the browser is spending time.

Open the Performance panel.
In the panel Start Recording Performance while your animation is happening.
Stop the recording and inspect the Waterfall tab.

If you see entries for Recalculate Style then the browser is having to begin at the start of the rendering waterfall.

Check if an animation is dropping frames #

Open the Rendering tab of Chrome DevTools.
Enable the FPS meter checkbox.
Watch the values as your animation runs.

At the top of the FPS meter UI you see the label Frames. Below that you see a value along the lines of 50% 1 (938 m) dropped of 1878. A high-performance animation will have a high percentage, e.g. 99%. A high percentage means that few frames are being dropped and the animation will look smooth.

The animation-with-top-left example causes 50% of frames to be dropped

The animation-with-transform example causes only 1% of frames to be dropped.

Check if an animation triggers paint #

When it comes to painting, some things are more expensive than others. For example, anything that involves a blur (like a shadow, for example) is going to take longer to paint than drawing a red box. In terms of CSS, however, this isn't always obvious: background: red; and box-shadow: 0, 4px, 4px, rgba(0,0,0,0.5); don't necessarily look like they have vastly different performance characteristics, but they do.

Browser DevTools can help you to identify which areas need to be repainted, and performance issues related to painting.

Chrome DevTools #

Open the Rendering tab of Chrome DevTools.
Select Paint Flashing.
Move the pointer around the screen.

In this example from Google Maps you can see the elements that will be repainted.

If you see the whole screen flashing, or areas that you don't think should change highlighted then you can do some investigation.

If you need to dig into whether a particular property is causing performance issues due to painting, the paint profiler in Chrome DevTools can help.

Firefox DevTools #

Open Settings and add a Toolbox button for Toggle paint flashing.
On the page you want to inspect, toggle the button on and move your mouse or scroll to see highlighted areas.

Conclusion #

Where possible restrict animations to opacity and transform in order to keep animations on the compositing stage of the rendering path. Use DevTools to check which stage of the path is being affected by your animations.

Use the paint profiler to see if any paint operations are particularly expensive. If you find anything, see if a different CSS property will give the same look and feel with better performance.

Use the will-change property sparingly, and only if you encounter a performance issue.

Why are some animations slow?

2020-10-06T00:00:00Z

Modern browsers can animate two CSS properties cheaply: transform and opacity. If you animate anything else, the chances are you're not going to hit a silky smooth 60 frames per second (FPS). This post explains why this is the case.

Animation performance and frame rate #

It is widely accepted that a frame rate of 60 FPS is the target when animating anything on the web. This frame rate will ensure that your animations look smooth. On the web a frame is the time that it takes to do all of the work required to update and repaint the screen. If each frame does not complete within 16.7ms (1000ms / 60 ≈ 16.7), then users will perceive the delay.

The rendering pipeline #

To display something on a webpage the browser has to go through the following sequential steps:

Style: Calculate the styles that apply to the elements.
Layout: Generate the geometry and position for each element.
Paint: Fill out the pixels for each element into layers.
Composite: Draw the layers to the screen.

These four steps are known as the browser's rendering pipeline.

When you animate something on a page that has already loaded these steps have to happen again. This process begins from the step that has to be changed in order to allow the animation to take place.

As mentioned before, these steps are sequential. For example, if you animate something that changes layout, the paint and composite steps also have to run again. Animating something that changes layout is therefore more expensive than animating something that only changes compositing.

Animating layout properties #

Layout changes involve calculating the geometry (position and size) of all the elements affected by the change. If you change one element, the geometry of other elements may need to be recalculated. For example, if you change the width of the <html> element any of its children may be affected. Due to the way elements overflow and affect one another, changes further down the tree can sometimes result in layout calculations all the way back up to the top.

The larger the tree of visible elements, the longer it takes to perform layout calculations.

Animating paint properties #

Paint is the process of determining in what order elements should be painted to the screen. It is often the longest-running of all tasks in the pipeline.

The majority of painting in modern browsers is done in software rasterizers. Depending on how the elements in your app are grouped into layers, other elements besides the one that changed may also need to be painted.

Animating composite properties #

Compositing is the process of separating the page into layers, converting the information about how the page should look into pixels (rasterization), and putting the layers together to create a page (compositing).

This is why the opacity property is included in the list of things which are cheap to animate. As long as this property is in its own layer, changes to it can be handled by the GPU during the compositing step. Chromium-based browsers and WebKit create a new layer for any element which has a CSS transition or animation on opacity.

What is a layer? #

By placing the things that will be animated or transitioned onto a new layer, the browser only needs to repaint those items and not everything else. You may be familiar with Photoshop's concept of a layer which contains a bunch of elements that can be moved together. Browser rendering layers are similar to that idea.

While the browser does a good job of making decisions about what elements should be on a new layer, if it misses one there are ways to force layer creation. You can find out about that in How to create high-performance animations. However, creating new layers should be done with care because each layer uses memory. On devices with limited memory creating new layers may cause more of a performance problem than the one you are trying to solve. In addition, each layer's textures need to be uploaded to the GPU. Therefore you may well hit constraints of bandwidth between the CPU and GPU.

CSS vs JavaScript performance #

You might wonder: is it better from a performance perspective to use CSS or JavaScript for animations?

CSS-based animations, and Web Animations (in the browsers that support the API), are typically handled on a thread known as the compositor thread. This is different from the browser's main thread, where styling, layout, painting, and JavaScript are executed. This means that if the browser is running some expensive tasks on the main thread, these animations can keep going without being interrupted.

As explained in this article, other changes to transforms and opacity can, in many cases, also be handled by the compositor thread.

If any animation triggers paint, layout, or both, the main thread will be required to do work. This is true for both CSS and JavaScript animations, and the overhead of layout or paint will likely dwarf any work associated with CSS or JavaScript execution, rendering the question moot.

Create interesting image shapes with CSS's clip-path property

2020-09-14T00:00:00Z

Elements on web pages are all defined inside a rectangular box. However that doesn't mean that we have to make everything look like a box. You can use the CSS clip-path property to clip away parts of an image or other element, to create interesting effects.

In the example above, the balloon image is square (source). Using clip-path and the basic shape value of circle() the additional sky around the balloon is clipped away leaving a circular image on the page.

As the image is a link you can see something else about the clip-path property. Only the visible area of the image can be clicked on, as events do not fire on the hidden parts of the image.

Clipping can be applied to any HTML element, not just images. There are a few different ways to create a clip-path, in this post we will take a look at them.

Browser compatibility #

Browser support

Chrome 55, Supported 55
Firefox 3.5, Supported 3.5
Edge 79, Supported 79
Safari 9.1, Supported 9.1

Source

For legacy browsers a fallback may be to allow the browser to ignore the clip-path property and show the unclipped image. If this is a problem you could test for clip-path in a feature query and offer an alternate layout for unsupporting browsers.

@supports(clip-path: circle(45%)) {
  /* code that requires clip-path here. */
}

Basic shapes #

The clip-path property can take a number of values. The value used in the initial example was circle(). This is one of the basic shape values, which are defined in the CSS Shapes specification. This means that you can clip an area, and also use the same value for shape-outside to cause text to wrap around that shape.

The full list of basic shapes is:

`inset()` #

The inset() value insets the clipped area from the edge of the element, and can be passed values for the top, right, bottom, and left edges. A border-radius can also be added to curve the corners of the clipped area, by using the round keyword.

In my example I have two boxes both with a class of .box. The first box has no clipping, the second is clipped using inset() values.

`circle()` #

As you have seen, the circle() value creates a circular clipped area. The first value is a length or a percentage and is the radius of the circle. A second optional value allows you to set the center of the circle. In the example below I am using keyword values to set my clipped circle top right. You could also use lengths or percentages.

Watch out for flat edges! #

Be aware with all of these values that the shape will be clipped by the margin box on the element. If you create a circle on an image, and that shape would extend outside of the natural size of the image, you will get a flat edge.

The image used earlier now has circle(50%) applied. As the image is not square, we hit the margin box at the top and bottom and the circle is clipped.

`ellipse()` #

An ellipse is essentially a squashed circle, and so acts very much like circle() but accepts a radius for x and a radius for y, plus the value for the center of the ellipse.

`polygon()` #

The polygon() value can help you create fairly complex shapes, defining as many points as you need, by setting the coordinates of each point.

To help you create polygons and see what is possible check out Clippy, a clip-path generator, then copy and paste the code into your own project.

Shapes from box values #

Also defined in CSS Shapes are shapes from box values. These relate to the CSS Box Model -- the content box, padding box, border box, and margin box with keyword values of content-box, border-box, padding-box, and margin-box.

These values can be used alone, or alongside a basic shape to define the reference box used by the shape. For example, the following would clip the shape to the edge of the content.

.box {
  clip-path: content-box;
}

In this example the circle would use the content-box as the reference box rather than the margin-box (which is the default).

.box {
  clip-path: circle(45%) content-box;
}

Currently browsers do not support the use of box values for the clip-path property. They are supported for shape-outside however.

Using an SVG element #

For more control over your clipped area than is possible with basic shapes, use an SVG clipPath element. Then reference that ID, using url() as the value for clip-path.

Animating the clipped area #

CSS transitions and animations can be applied to the clip-path to create some interesting effects. In this next example I am animating a circle on hover by transitioning between two circles with a different radius value.

There are lots of creative ways in which animation can be used with clipping. Animating with clip-path on CSS Tricks runs through some ideas.

Photo by Matthew Henry on Burst.

Apply effects to images with CSS's mask-image property

2020-09-14T00:00:00Z

When you clip an element using the clip-path property the clipped area becomes invisible. If instead you want to make part of the image opaque or apply some other effect to it, then you need to use masking. This post explains how to use the mask-image property in CSS, which lets you specify an image to use as a mask layer. This gives you three options. You can use an image file as your mask, an SVG, or a gradient.

Browser compatibility #

Most browsers only have partial support for the standard CSS masking property. You will need to use the -webkit- prefix in addition to the standard property in order to achieve the best browser compatibility. See Can I use CSS Masks? for full browser support information.

Browser support

Chrome 1, Supported 1
Firefox 53, Supported 53
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

While browser support using the prefixed property is good, when using masking to make text on top of an image visible take care of what will happen if masking is unavailable. It may be worth using feature queries to detect support for mask-image or -webkit-mask-image and providing a readable fallback before adding your masked version.

@supports(-webkit-mask-image: url(#mask)) or (mask-image: url(#mask)) {
  /* code that requires mask-image here. */
}

Masking with an image #

The mask-image property works in a similar way to the background-image property. Use a url() value to pass in an image. Your mask image needs to have a transparent or semi-transparent area.

A fully transparent area will cause the part of the image under that area to be invisible. Using an area which is semi-transparent however will allow some of the original image to show through. You can see the difference in the Glitch below. The first image is the original image of balloons with no mask. The second image has a mask applied which has a white star on a fully transparent background. The third image has a white star on a background with a gradient transparency.

In this example I am also using the mask-size property with a value of cover. This property works in the same way as background-size. You can use the keywords cover and contain or you can give the background a size using any valid length unit, or a percentage.

You can also repeat your mask just as you might repeat a background image, in order to use a small image as a repeating pattern.

Masking with SVG #

Rather than using an image file as the mask, you could use SVG. There are a couple of ways this can be achieved. The first is to have a <mask> element inside the SVG and reference the ID of that element in the mask-image property.

<svg width="0" height="0" viewBox="0 0 400 300">
  <defs>
    <mask id="mask">
      <rect fill="#000000" x="0" y="0" width="400" height="300"></rect>
      <circle fill="#FFFFFF" cx="150" cy="150" r="100" />
      <circle fill="#FFFFFF" cx="50" cy="50" r="150" />
    </mask>
  </defs>
</svg>

<div class="container">
    <img src="balloons.jpg" alt="Balloons">
</div>

.container img {
  height: 100%;
  width: 100%;
  object-fit: cover;
  -webkit-mask-image: url(#mask);
  mask-image: url(#mask);
}

The advantage of this approach is that the mask could be applied to any HTML element, not just an image. Unfortunately Firefox is the only browser that supports this approach.

All is not lost however, as for the most common scenario of masking an image, we can include the image in the SVG.

Masking with a gradient #

Using a CSS gradient as your mask is an elegant way of achieving a masked area without needing to go to the trouble of creating an image or SVG.

A simple linear gradient used as a mask could ensure that the bottom part of an image will not be too dark underneath a caption, for example.

You can use any of the supported gradient types, and get as creative as you like. This next example uses a radial gradient to create a circular mask to illuminate behind the caption.

Using multiple masks #

As with background images you can specify multiple mask sources, combining them to get the effect that you want. This is particularly useful if you want to use a pattern generated with CSS gradients as your mask. These typically will use multiple background images and so can be translated easily into a mask.

As an example, I found a nice checkerboard pattern in this article. The code, using background images, looks like this:

background-image:
  linear-gradient(45deg, #ccc 25%, transparent 25%),
  linear-gradient(-45deg, #ccc 25%, transparent 25%),
  linear-gradient(45deg, transparent 75%, #ccc 75%),
  linear-gradient(-45deg, transparent 75%, #ccc 75%);
background-size:20px 20px;
background-position: 0 0, 0 10px, 10px -10px, -10px 0px;

To turn this, or any other pattern designed for background images, into a mask, you will need to replace the background-* properties with the relevant mask properties, including the -webkit prefixed ones.

-webkit-mask-image:
  linear-gradient(45deg, #000000 25%, rgba(0,0,0,0.2) 25%),
  linear-gradient(-45deg, #000000 25%, rgba(0,0,0,0.2) 25%),
  linear-gradient(45deg, rgba(0,0,0,0.2) 75%, #000000 75%),
  linear-gradient(-45deg, rgba(0,0,0,0.2) 75%, #000000 75%);
-webkit-mask-size:20px 20px;
  -webkit-mask-position: 0 0, 0 10px, 10px -10px, -10px 0px;

There are some really nice effects to be made by applying gradient patterns to images. Try remixing the Glitch and testing out some other variations.

Along with clipping, CSS masks are a way to add interest to images and other HTML elements without needing to use a graphics application.

Photo by Julio Rionaldo on Unsplash.

Content reordering

2020-05-29T00:00:00Z

The order of content in your document is important for the accessibility of your site. A screen reader will read out content based on the document order, using the HTML elements that you have selected to give meaning to that content. A person navigating the site using a keyboard, rather than a touchscreen or mouse, will tab around the document. This means that they will jump from active element to active element, tabbing between links and form fields, once again in the order they exist in the document.

Starting with a well-structured document and using all of the right HTML elements is therefore a key part of creating an accessible site. However, it is possible to undo some of that good work when you start using CSS. Let's take a look at why.

Source vs. visual order #

Website navigation is often marked up as a list of links. You can then use Flexbox to turn these into a horizontal bar. In the Glitch example below, I have created this commonly used pattern. Click into the example, and tab between the links. The focus will move in a logical direction from left to right, the order that we read in English.

If you have created this sort of pattern and then were asked to move Contact Us, which is second in the source, to the end. You could use the order property which works in Flexbox. Try tabbing through the items in the example below, which has used the order property to rearrange the items.

The focus jumps to the final item and then back again. As far as the tab order is concerned that item is the second item. Visually however, it's the last item.

The above example highlights the problem that we face if we rearrange and reorder content using CSS. If you were dealing with this issue then the right thing to do would be to change the order in the source, rather than using CSS.

Which CSS properties can cause reordering? #

Any layout method that allows you to move elements around can cause this problem. The following CSS properties commonly cause content reordering problems:

Using position: absolute and taking an item out of flow visually.
The order property in Flexbox and Grid layout.
The row-reverse and column-reverse values for flex-direction in Flexbox.
The dense value for grid-auto-flow in Grid Layout.
Any positioning by line name or number, or with grid-template-areas in Grid Layout.

In this next example, I have created a layout using CSS Grid and positioned the items using line numbers, without considering where they are in the source.

Try tabbing around this example, and see how the focus jumps about. This makes for a very confusing experience, especially if this is a long page.

Testing for the problem #

A very simple test is to keyboard navigate through your page. Can you get to everything? Are there any strange jumps as you do so?

For a visual demonstration of content reordering, try the Tab Stop checker in the Accessibility Insights extension for Chrome. The image below shows the CSS Grid example in that tool. You can see how the focus has to jump around the layout.

Content reordering and responsive web design #

If you only have one presentation of your content, then having your source in a logical order, and reflecting that in layout is not usually difficult. It can become harder, when you consider the layout at different breakpoints. It might make sense to have an element moved to the bottom of the layout on smaller screens for example.

There is not at this time a good solution for this problem. In most situations developing "mobile first", will help you keep your source and layout in order. The choices you make about priority on mobile, are often solid ones for the content in general. The key is to be aware when there is a possibility of this type of content reordering, and to test that the end experience is not too jarring at each breakpoint.

Accessible tap targets

2020-03-31T00:00:00Z

When your design is displayed on a mobile device, you should ensure that interactive elements like buttons or links are large enough, and have enough space around them, to make them easy to press without accidentally overlapping onto other elements. This benefits all users, but is especially helpful for anyone with a motor impairment.

A minimum recommended touch target size is around 48 device independent pixels on a site with a properly set mobile viewport. For example, while an icon may only have a width and height of 24px, you can use additional padding to bring the tap target size up to 48px. The 48x48 pixel area corresponds to around 9mm, which is about the size of a person's finger pad area.

In the demo, I have added padding to all of the links in order to make sure they meet the minimum size.

Touch targets should also be spaced about 8 pixels apart, both horizontally and vertically, so that a user's finger pressing on one tap target does not inadvertently touch another tap target.

Testing your touch targets #

If your target is text and you have used relative values such as em or rem to size the text and any padding, you can use DevTools to check that the computed value of that area is large enough. In the example below I am using em for my text and padding.

Inspect the a of the link, and in Chrome DevTools switch to the Computed pane where you can inspect the various parts of the box and see what pixel size they resolve to. In Firefox DevTools there is a Layout Panel. In that Panel you get the actual size of the inspected element.

Using media queries to detect touchscreen use #

Instead of simply testing for viewport dimensions, and then guessing that small dimensions are likely to be phones or tablets, which in turn use a touchscreen, there are now more robust ways to adapt your design based on actual device capabilities.

One of the media features we can now test for with media queries is whether the user's primary input is a touchscreen (pointer) and whether any of the currently detected inputs is a touchscreen (any-pointer). The pointer and any-pointer features will return fine or coarse. A fine pointer will be someone using a mouse or trackpad, even if that mouse is connected via Bluetooth to a phone. A coarse pointer indicates a touchscreen, which could be a mobile device but may also be a laptop screen or large tablet.

If you are adjusting your CSS within a media query to increase the touch target, testing for a coarse pointer allows you to increase the tap targets for all touchscreen users. This gives the larger tap area whether the device is a phone or larger device.

.container a {
  padding: .2em;
}

@media (any-pointer: coarse) {
  .container a {
    padding: .8em;
  }
}

You can find out more about interaction media features such as pointer in the Responsive web design basics article.

Accessible responsive design

2020-03-31T00:00:00Z

We know that it's a good idea to design responsively to provide the best multi-device experience, but responsive design also yields a win for accessibility.

Consider a site like Udacity:

A low-vision user who has difficulty reading small print might zoom in the page, perhaps as much as 400%. Because the site is designed responsively, the UI will rearrange itself for the "smaller viewport" (actually for the larger page), which is great for desktop users who require screen magnification and for mobile screen reader users as well. It's a win-win. Here's the same page magnified to 400%:

In fact, just by designing responsively, we're meeting rule 1.4.4 of the WebAIM checklist, which states that a page "… should be readable and functional when the text size is doubled."

Going over all of responsive design is outside the scope of this guide, but here are a few important takeaways that will benefit your responsive experience and give your users better access to your content.

Use the viewport meta tag #

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Setting width=device-width will match the screen's width in device-independent pixels, and setting initial-scale=1 establishes a 1:1 relationship between CSS pixels and device-independent pixels. Doing this instructs the browser to fit your content to the screen size, so users don't just see a bunch of scrunched-up text.

See Size content to viewport to learn more.

Allow users to zoom #

It is possible to use the viewport meta tag to prevent zooming, by setting maximum-scale=1 or user-scaleable=no. Avoid doing this, and let your users zoom in if they need to.

Design with flexibility #

Avoid targetting specific screen sizes and instead use a flexible grid, making changes to the layout when the content dictates. As we saw with the Udacity example above, this approach ensures that the design responds whether the reduced space is due to a smaller screen or a higher zoom level.

You can read more about these techniques in the Responsive web design basics article.

Use relative units for text #

To get the best out of your flexible grid use relative units like em or rem for things like text size, instead of pixel values. Some browsers support resizing text only in user preferences, and if you're using a pixel value for text, this setting will not affect your copy. If, however, you've used relative units throughout, then the site copy will update to reflect the user's preference.

This will enable the whole site to reflow as the user zooms, creating the reading experience they need to use your site.

Avoid disconnecting the visual view from the source order #

A visitor who is tabbing through your site with the keyboard will be following the order of the content in the HTML document. When using modern layout methods such as Flexbox and Grid, it is easy to make the visual rendering not match the source order. This can lead to disconcerting jumps around the page for someone using the keyboard to move around.

Make sure to test your design at each breakpoint by tabbing through the content, does the flow through the page still make sense?

Take care with spatial clues #

When writing microcopy avoid using language which indicates the location of an element on the page. For example, referring to navigation "on your left" makes no sense in a mobile version when the navigation is at the top of the screen.

Ensure tap targets are large enough on touchscreen devices #

On touchscreen devices make sure your tap targets are large enough to make them easy to activate without hitting other links. A good size for any tappable element is 48px, read more guidance on tap targets.

Color and contrast accessibility

2020-03-31T00:00:00Z

If you have good vision, it's easy to assume that everyone perceives colors, or text legibility, the same way you do—but of course that's not the case.

As you might imagine, some color combinations that are easy for some people to read are difficult or impossible for others. This usually comes down to color contrast, the relationship between the foreground and background colors' luminance. When the colors are similar, the contrast ratio is low; when they are different, the contrast ratio is high.

The WebAIM guidelines recommend an AA (minimum) contrast ratio of 4.5:1 for all text. An exception is made for very large text (120-150% larger than the default body text), for which the ratio can go down to 3:1. Notice the difference in the contrast ratios shown below.

The contrast ratio of 4.5:1 was chosen for level AA because it compensates for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/40 vision. 20/40 is commonly reported as typical visual acuity of people at about age 80. For users with low vision impairments or color deficiencies, we can increase the contrast up to 7:1 for body text.

You can use the Accessibility Audit in Lighthouse to check your color contrast. Open DevTools, click Audits, and select Accessibility to run the report.

Chrome also includes an experimental feature to help you detect all the low contrast texts of your page. You can also use the accessible color suggestion to fix the low contrast text.

For a more complete report, install the Accessibility Insights Extension. One of the checks in the Fastpass report, is color contrast. You will get a detailed report of any failing elements.

Advanced Perceptual Contrast Algorithm (APCA) #

The Advanced Perceptual Contrast Algorithm (APCA) is a new way to compute contrast based on modern research on color perception.

Compared to AA/AAA guidelines, APCA is more context-dependent.

The contrast is calculated based on the following features:

Spatial properties (font weight and text size)
Text color (perceived lightness difference between text and background)
Context (ambient light, surroundings, and intended purpose of the text)

Chrome includes an experimental feature to replace the AA/AAA contrast ratio guidelines with APCA.

Don't convey information with color alone #

There are roughly 320 million people worldwide with color vision deficiency. About 1 in 12 men and 1 in 200 women have some form of "color blindness"; that means about 1/20th, or 5%, of your users will not experience your site the way you intended. When we rely on color to convey information, we push that number to unacceptable levels.

For example, in an input form, a telephone number might be underlined in red to show that it is invalid. But to a color deficient or screen reader user, that information is not conveyed well, if at all. Thus, you should always try to provide multiple avenues for the user to access critical information.

The WebAIM checklist states in section 1.4.1 that "color should not be used as the sole method of conveying content or distinguishing visual elements." It also notes that "color alone should not be used to distinguish links from surrounding text" unless they meet certain contrast requirements. Instead, the checklist recommends adding an additional indicator such as an underscore (using the CSS text-decoration property) to indicate when the link is active.

An easy way to fix the previous example is to add an additional message to the field, announcing that it is invalid and why.

When you're building an app, keep these sorts of things in mind and watch out for areas where you may be relying too heavily on color to convey important information.

If you're curious about how your site looks to different people, or if you rely heavily on the use of color in your UI, you can use DevTools to simulate various forms of visual impairment, including different types of color blindness. Chrome includes an Emulate Vision Deficiencies feature. To access it open DevTools and then open the Rendering tab in the Drawer, you can then emulate the following color deficiencies.

Protanopia: the inability to perceive any red light.
Deuteranopia: the inability to perceive any green light.
Tritanopia: the inability to perceive any blue light.
Achromatopsia: the inability to perceive any color except for shades of grey (extremely rare).

High contrast mode #

High-contrast mode allows a user to invert foreground and background colors, which often helps text stand out better. For someone with a low vision impairment, high-contrast mode can make it much easier to navigate the content on the page. There are a few ways to get a high-contrast setup on your machine.

Operating systems like Mac OSX and Windows offer high-contrast modes that can be enabled for everything at the system level.

A useful exercise is to turn on high-contrast settings and verify that all of the UI in your application is still visible and usable.

For example, a navigation bar might use a subtle background color to indicate which page is currently selected. If you view it in a high-contrast extension, that subtlety completely disappears, and with it goes the reader's understanding of which page is active.

Similarly, if you consider the example from the previous lesson, the red underline on the invalid phone number field might be displayed in a hard-to-distinguish blue-green color.

If you are meeting the contrast ratios covered earlier you should be fine when it comes to supporting high-contrast mode. But for added peace of mind, consider installing the High Contrast Chrome Extension and giving your page a once-over just to check that everything works, and looks, as expected.

Fixing mixed content

2019-09-07T00:00:00Z

Supporting HTTPS for your website is an important step to protecting your site and your users from attack, but mixed content can render that protection useless. Increasingly insecure mixed content will be blocked by browsers, as explained in What is mixed content?

In this guide we will demonstrate techniques and tools for fixing existing mixed content issues and preventing new ones from happening.

Finding mixed content by visiting your site #

When visiting an HTTPS page in Google Chrome, the browser alerts you to mixed content as errors and warnings in the JavaScript console.

In What is mixed content?, you can find a number of examples and see how the problems are reported in Chrome DevTools.

The example of passive mixed content will give the following warnings. If the browser is able to find the content at an https URL it automatically upgrades it, then shows a message.

Active mixed content is blocked and displays a warning.

If you find warnings like these for http:// URLs on your site, you need to fix them in your site's source. It's helpful to make a list of these URLs, along with the page you found them on, for use when you fix them.

Finding mixed content in your site #

You can search for mixed content directly in your source code. Search for http:// in your source and look for tags that include HTTP URL attributes. Note that having http:// in the href attribute of anchor tags (<a>) is often not a mixed content issue, with some notable exceptions discussed later.

If your site is published using a content management system, it is possible that links to insecure URLs are inserted when pages are published. For example, images may be included with a full URL rather than a relative path. You will need to find and fix these within the CMS content.

Fixing mixed content #

Once you've found mixed content in your site's source, you can follow these steps to fix it.

If you get a console message that a resource request has been automatically upgraded from HTTP to HTTPS, you can safely change the http:// URL for the resource in your code to https://. You can also check to see if a resource is available securely by changing http:// to https:// in the browser URL bar and attempting to open the URL in a browser tab.

If the resource is not available via https://, you should consider one of the following options:

Include the resource from a different host, if one is available.
Download and host the content on your site directly, if you are legally allowed to do so.
Exclude the resource from your site altogether.

Having fixed the problem, view the page where you found the error originally and verify that the error no longer appears.

Beware of non-standard tag usage #

Beware of non-standard tag usage on your site. For instance, anchor (<a>) tag URLs don't result in mixed content errors, as they cause the browser to navigate to a new page. This means they usually don't need to be fixed. However some image gallery scripts override the functionality of the <a> tag and load the HTTP resource specified by the href attribute into a lightbox display on the page, causing a mixed content problem.

Handle mixed content at scale #

The manual steps above work well for smaller websites; but for large websites or sites with many separate development teams, it can be tough to keep track of all the content being loaded. To help with this task, you can use content security policy to instruct the browser to notify you about mixed content and ensure that your pages never unexpectedly load insecure resources.

Content security policy #

Content security policy (CSP) is a multi-purpose browser feature that you can use to manage mixed content at scale. The CSP reporting mechanism can be used to track mixed content on your site, and provide enforcement policies to protect users by upgrading or blocking mixed content.

You can enable these features for a page by including the Content-Security-Policy or Content-Security-Policy-Report-Only header in the response sent from your server. Additionally you can set Content-Security-Policy (though not Content-Security-Policy-Report-Only) using a <meta> tag in the <head> section of your page.

Finding mixed content with content security policy #

You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.

Response header:

Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri https://example.com/reportingEndpoint

Whenever a user visits a page on your site, their browser sends JSON-formatted reports regarding anything that violates the content security policy to https://example.com/reportingEndpoint. In this case, anytime a subresource is loaded over HTTP, a report is sent. These reports include the page URL where the policy violation occurred and the subresource URL that violated the policy. If you configure your reporting endpoint to log these reports, you can track the mixed content on your site without visiting each page yourself.

The two caveats to this are:

Users have to visit your page in a browser that understands the CSP header. This is true for most modern browsers.
You only get reports for pages visited by your users. So if you have pages that don't get much traffic, it might be some time before you get reports for your entire site.

The Content security policy guide has more information and an example endpoint.

Alternatives to reporting with CSP #

If your site is hosted for you by a platform such as Blogger, you may not have access to modify headers and add a CSP. Instead, a viable alternative could be to use a website crawler to find issues across your site for you, such as HTTPSChecker or Mixed Content Scan.

Upgrading insecure requests #

Browser support

Chrome 44, Supported 44
Firefox 48, Supported 48
Edge 17, Supported 17
Safari 10.1, Supported 10.1

Source

Browsers are beginning to upgrade and block insecure requests. You can use CSP directives to force automatic upgrading or blocking of these assets.

The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.

As an example, if a page contains an image tag with an HTTP URL such as <img src="http://example.com/image.jpg">

The browser instead makes a secure request for https://example.com/image.jpg, thus saving the user from mixed content.

You can enable this behavior either by sending a Content-Security-Policy header with this directive:

Content-Security-Policy: upgrade-insecure-requests

Or by embedding that same directive inline in the document's <head> section using a <meta> element:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

As with browser automatic upgrading, if the resource is not available over HTTPS, the upgraded request fails and the resource is not loaded. This maintains the security of your page. The upgrade-insecure-requests directive will go further than automatic browser upgrading, attempting to upgrade requests that the browser currently does not.

The upgrade-insecure-requests directive cascades into <iframe> documents, ensuring the entire page is protected.

What is mixed content?

2019-09-07T00:00:00Z

Mixed content occurs when initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, scripts) are loaded over an insecure HTTP connection. This is called mixed content because both HTTP and HTTPS content are being loaded to display the same page, and the initial request was secure over HTTPS.

Requesting subresources using the insecure HTTP protocol weakens the security of the entire page, as these requests are vulnerable to on-path attacks, where an attacker eavesdrops on a network connection and views or modifies the communication between two parties. Using these resources, attackers can track users and replace content on a website, and in the case of active mixed content, take complete control over the page, not just the insecure resources.

Although many browsers report mixed content warnings to the user, by the time this happens, it is too late: the insecure requests have already been performed and the security of the page is compromised.

This is why browsers are increasingly blocking mixed content. If you have mixed content on your site, then fixing it will ensure the content continues to load as browsers become more strict.

The two types of mixed content #

The two types of mixed content are: active and passive.

Passive mixed content refers to content that doesn't interact with the rest of the page, and thus a man-in-the-middle attack is restricted to what they can do if they intercept or change that content. Passive mixed content is defined as images, video, and audio content.

Active mixed content interacts with the page as a whole and allows an attacker to do almost anything with the page. Active mixed content includes scripts, stylesheets, iframes, and other code that the browser can download and execute.

Passive mixed content #

Passive mixed content is seen as less problematic yet still poses a security threat to your site and your users. For example, an attacker can intercept HTTP requests for images on your site and swap or replace these images; the attacker can swap the save and delete button images, causing your users to delete content without intending to; replace your product diagrams with lewd or pornographic content, defacing your site; or replace your product pictures with ads for a different site or product.

Even if the attacker doesn't alter the content of your site, an attacker can track users via mixed content requests. The attacker can tell which pages a user visits and which products they view based on images or other resources that the browser loads.

If passive mixed content is present most browsers will indicate in the URL bar that the page is not secure, even when the page itself was loaded over HTTPS. You can observe this behavior with this demo that contains examples of passive mixed content.

Until recently passive mixed content was loaded in all browsers, as to block it would have broken many websites. This is now beginning to change and so it is vital to update any instances of mixed content on your site.

Chrome is currently rolling out automatic upgrading of passive mixed content where possible. Automatic upgrading means that if the asset is available over HTTPS, but has been hardcoded as HTTP, the browser will load the HTTPS version. If no secure version can be found the asset will not load.

Whenever it detects mixed content or auto-upgrades passive mixed content, Chrome logs detailed messages to the Issues tab in DevTools to guide you on how to fix the specific issue.

Active mixed content #

Active mixed content poses a greater threat than passive mixed content. An attacker can intercept and rewrite active content, thereby taking full control of your page or even your entire website. This allows the attacker to change anything about the page, including displaying entirely different content, stealing user passwords or other login credentials, stealing user session cookies, or redirecting the user to a different site entirely.

Due to the severity of this threat, most browsers already block this type of content by default to protect users, but functionality varies between browser vendors and versions.

This other demo contains examples of active mixed content. Load the example over HTTP to see the content that's blocked when you load the example over HTTPS. Blocked content will also be detailed in the Issues tab.

The mixed content specification #

Browsers follow the mixed content specification, which defines the optionally blockable content and blockable content categories.

From the spec, a resource qualifies as optionally blockable content "when the risk of allowing its usage as mixed content is outweighed by the risk of breaking significant portions of the web"; this is a subset of the passive mixed content category described above.

All content that is not optionally blockable is considered blockable, and should be blocked by the browser.

In recent years, HTTPS usage has risen dramatically, and has become the clear default on the web. This makes it more feasible now for browsers to consider blocking all mixed content, even those subresource types defined in the mixed content specification as optionally blockable. This is why we now see Chrome taking a stricter approach to these subresources.

Older browsers #

It is important to remember that not every visitor to your website uses the most up-to-date browsers. Different versions from different browser vendors each treat mixed content differently. At worst, older browsers and versions don't block any mixed content at all, which is very unsafe for the user.

By fixing your mixed content problems you ensure that your content is visible in new browsers. You also help protect users from dangerous content that isn't blocked by older browsers.

Use lazy loading to improve loading speed

2019-08-16T00:00:00Z

The portion of images and video in the typical payload of a website can be significant. Unfortunately, project stakeholders may be unwilling to cut any media resources from their existing applications. Such impasses are frustrating, especially when all parties involved want to improve site performance, but can't agree on how to get there. Fortunately, lazy loading is a solution that lowers initial page payload and load time, but doesn't skimp on content.

What is lazy loading? #

Lazy loading is a technique that defers loading of non-critical resources at page load time. Instead, these non-critical resources are loaded at the moment of need. Where images are concerned, "non-critical" is often synonymous with "off-screen". If you've used Lighthouse and examined some opportunities for improvement, you may have seen some guidance in this realm in the form of the Defer offscreen images audit:

One of Lighthouse's performance audits is to identify off screen images, which are candidates for lazy loading.

You've probably already seen lazy loading in action, and it goes something like this:

You arrive at a page, and begin to scroll as you read content.
At some point, you scroll a placeholder image into the viewport.
The placeholder image is suddenly replaced by the final image.

An example of image lazy loading can be found on the popular publishing platform Medium, which loads lightweight placeholder images at page load, and replaces them with lazily-loaded images as they're scrolled into the viewport.

An example of image lazy loading in action. A placeholder image is loaded at page load (left), and when scrolled into the viewport, the final image loads at the time of need.

If you're unfamiliar with lazy loading, you might be wondering just how useful the technique is, and what its benefits are. Read on to find out!

Why lazy-load images or video instead of just loading them? #

Because it's possible you're loading stuff the user may never see. This is problematic for a couple reasons:

It wastes data. On unmetered connections, this isn't the worst thing that could happen (although you could be using that precious bandwidth for downloading other resources that are indeed going to be seen by the user). On limited data plans, however, loading stuff the user never sees could effectively be a waste of their money.
It wastes processing time, battery, and other system resources. After a media resource is downloaded, the browser must decode it and render its content in the viewport.

Lazy loading images and video reduces initial page load time, initial page weight, and system resource usage, all of which have positive impacts on performance.

Implementing lazy loading #

There are a number of ways to implement lazy loading. Your choice of solution must take into account the browsers you support, and also what you are trying to lazy-load.

Modern browsers implement browser-level lazy loading, which can be enabled using the loading attribute on images and iframes. To provide compatibility with older browsers or to perform lazy loading on elements without built-in lazy loading you can implement a solution with your own JavaScript. There are also a number of existing libraries to help you to do this. See the posts on this site for full details of all of these approaches:

Also, we have compiled a list of potential issues with lazy loading, and things to watch out for in your implementation.

Conclusion #

Used with care, lazy loading images and video can seriously lower the initial load time and page payloads on your site, including Core Web Vitals. Users won't incur unnecessary network activity—including network contention on slower connections—and processing costs of media resources they may never see, but they can still view those resources if they want.

As far as performance improvement techniques go, lazy loading is reasonably uncontroversial. If you have a lot of inline imagery in your site, it's a perfectly fine way to cut down on unnecessary downloads. Your site's users and project stakeholders will appreciate it!

Lazy loading video

2019-08-16T00:00:00Z

As with image elements, you can also lazy-load video. Videos are commonly loaded with the <video> element (although an alternate method using <img> has emerged with limited implementation). How to lazy-load <video> depends on the use case, though. Let's discuss a couple of scenarios that each require a different solution.

For video that doesn't autoplay #

For videos where playback is initiated by the user (that is, videos that don't autoplay), specifying the preload attribute on the <video> element may be desirable:

<video controls preload="none" poster="one-does-not-simply-placeholder.jpg">
  <source src="one-does-not-simply.webm" type="video/webm">
  <source src="one-does-not-simply.mp4" type="video/mp4">
</video>

The example above uses a preload attribute with a value of none to prevent browsers from preloading any video data. The poster attribute gives the <video> element a placeholder that will occupy the space while the video loads. The reason for this is that default behaviors for loading video can vary from browser to browser:

In Chrome, the default for preload used to be auto, but as of Chrome 64, it now defaults to metadata. Even so, on the desktop version of Chrome, a portion of the video may be preloaded using the Content-Range header. Other Chromium-based browsers and Firefox behave similarly.
As with Chrome on desktop, 11.0 desktop versions of Safari will preload a range of the video. From version 11.2, only the video metadata is preloaded. In Safari on iOS, videos are never preloaded.
When Data Saver mode is enabled, preload defaults to none.

Because browser default behaviors with regard to preload are not set in stone, being explicit is probably your best bet. In this cases where the user initiates playback, using preload="none" is the easiest way to defer loading of video on all platforms. The preload attribute isn't the only way to defer the loading of video content. Fast Playback with Video Preload may give you some ideas and insight into working with video playback in JavaScript.

Unfortunately, it doesn't prove useful when you want to use video in place of animated GIFs, which is covered next.

For video acting as an animated GIF replacement #

While animated GIFs enjoy wide use, they're subpar to video equivalents in a number of ways, particularly in file size. Animated GIFs can stretch into the range of several megabytes of data. Videos of similar visual quality tend to be far smaller.

Using the <video> element as a replacement for animated GIF is not as straightforward as the <img> element. Animated GIFs have three characteristics:

They play automatically when loaded.
They loop continuously (though that's not always the case).
They don't have an audio track.

Achieving this with the <video> element looks something like this:

<video autoplay muted loop playsinline>
  <source src="one-does-not-simply.webm" type="video/webm">
  <source src="one-does-not-simply.mp4" type="video/mp4">
</video>

The autoplay, muted, and loop attributes are self-explanatory. playsinline is necessary for autoplaying to occur in iOS. Now you have a serviceable video-as-GIF replacement that works across platforms. But how to go about lazy loading it? To start, modify your <video> markup accordingly:

<video class="lazy" autoplay muted loop playsinline width="610" height="254" poster="one-does-not-simply.jpg">
  <source data-src="one-does-not-simply.webm" type="video/webm">
  <source data-src="one-does-not-simply.mp4" type="video/mp4">
</video>

You'll notice the addition of the poster attribute, which lets you specify a placeholder to occupy the <video> element's space until the video is lazy-loaded. As with the <img> lazy-loading examples, stash the video URL in the data-src attribute on each <source> element. From there, use JavaScript code similar to the Intersection Observer-based image lazy loading examples:

document.addEventListener("DOMContentLoaded", function() {
  var lazyVideos = [].slice.call(document.querySelectorAll("video.lazy"));

  if ("IntersectionObserver" in window) {
    var lazyVideoObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(video) {
        if (video.isIntersecting) {
          for (var source in video.target.children) {
            var videoSource = video.target.children[source];
            if (typeof videoSource.tagName === "string" && videoSource.tagName === "SOURCE") {
              videoSource.src = videoSource.dataset.src;
            }
          }

          video.target.load();
          video.target.classList.remove("lazy");
          lazyVideoObserver.unobserve(video.target);
        }
      });
    });

    lazyVideos.forEach(function(lazyVideo) {
      lazyVideoObserver.observe(lazyVideo);
    });
  }
});

When you lazy-load a <video> element, you need to iterate through all of the child <source> elements and flip their data-src attributes to src attributes. Once you've done that, you need to trigger loading of the video by calling the element's load method, after which the media will begin playing automatically per the autoplay attribute.

Using this method, you have a video solution that emulates animated GIF behavior, but doesn't incur the same intensive data usage as animated GIFs do, and you can lazy-load that content.

Lazy loading libraries #

The following libraries can help you to lazy-load video:

vanilla-lazyload and lozad.js are super lightweight options that use Intersection Observer only. As such, they are highly performant, but will need to be polyfilled before you can use them on older browsers.
yall.js is a library that uses Intersection Observer and falls back to event handlers. It can also lazy load video poster images using a data-poster attribute.
If you need a React-specific lazy loading library, you might consider react-lazyload. While it doesn't use Intersection Observer, it does provide a familiar method of lazy loading images for those accustomed to developing applications with React.

Each of these lazy loading libraries is well documented, with plenty of markup patterns for your various lazy loading endeavors.

Lazy loading images

2019-08-16T00:00:00Z

Images can appear on a webpage due to being inline in the HTML as <img> elements or as CSS background images. In this post you will find out how to lazy-load both types of image.

Inline images #

The most common lazy loading candidates are images as used in <img> elements. With inline images we have three options for lazy loading, which may be used in combination for the best compatibility across browsers:

Using browser-level lazy loading #

Chrome and Firefox both support lazy loading with the loading attribute. This attribute can be added to <img> elements, and also to <iframe> elements. A value of lazy tells the browser to load the image immediately if it is in the viewport, and to fetch other images when the user scrolls near them.

See the loading field of MDN's browser compatibility table for details of browser support. If the browser does not support lazy loading then the attribute will be ignored and images will load immediately, as normal.

For most websites, adding this attribute to inline images will be a performance boost and save users loading images that they may not ever scroll to. If you have large numbers of images and want to be sure that users of browsers without support for lazy loading benefit you will need to combine this with one of the methods explained next.

To learn more, check out Browser-level lazy loading for the web.

Using Intersection Observer #

To polyfill lazy loading of <img> elements, we use JavaScript to check if they're in the viewport. If they are, their src (and sometimes srcset) attributes are populated with URLs to the desired image content.

If you've written lazy loading code before, you may have accomplished your task by using event handlers such as scroll or resize. While this approach is the most compatible across browsers, modern browsers offer a more performant and efficient way to do the work of checking element visibility via the Intersection Observer API.

Intersection Observer is easier to use and read than code relying on various event handlers, because you only need to register an observer to watch elements rather than writing tedious element visibility detection code. All that's left to do is to decide what to do when an element is visible. Let's assume this basic markup pattern for your lazily loaded <img> elements:

<img class="lazy" src="placeholder-image.jpg" data-src="image-to-lazy-load-1x.jpg" data-srcset="image-to-lazy-load-2x.jpg 2x, image-to-lazy-load-1x.jpg 1x" alt="I'm an image!">

There are three relevant pieces of this markup that you should focus on:

The class attribute, which is what you'll select the element with in JavaScript.
The src attribute, which references a placeholder image that will appear when the page first loads.
The data-src and data-srcset attributes, which are placeholder attributes containing the URL for the image you'll load once the element is in the viewport.

Now let's see how to use Intersection Observer in JavaScript to lazy-load images using this markup pattern:

document.addEventListener("DOMContentLoaded", function() {
  var lazyImages = [].slice.call(document.querySelectorAll("img.lazy"));

  if ("IntersectionObserver" in window) {
    let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          let lazyImage = entry.target;
          lazyImage.src = lazyImage.dataset.src;
          lazyImage.srcset = lazyImage.dataset.srcset;
          lazyImage.classList.remove("lazy");
          lazyImageObserver.unobserve(lazyImage);
        }
      });
    });

    lazyImages.forEach(function(lazyImage) {
      lazyImageObserver.observe(lazyImage);
    });
  } else {
    // Possibly fall back to event handlers here
  }
});

On the document's DOMContentLoaded event, this script queries the DOM for all <img> elements with a class of lazy. If Intersection Observer is available, create a new observer that runs a callback when img.lazy elements enter the viewport.

Intersection Observer is available in all modern browsers. Therefore using it as a polyfill for loading="lazy" will ensure that lazy loading is available for most visitors.

Images in CSS #

While <img> tags are the most common way of using images on web pages, images can also be invoked via the CSS background-image property (and other properties). Browser-level lazy loading does not apply to CSS background images, so you need to consider other methods if you have background images to lazy-load.

Unlike <img> elements which load regardless of their visibility, image loading behavior in CSS is done with more speculation. When the document and CSS object models and render tree are built, the browser examines how CSS is applied to a document before requesting external resources. If the browser has determined a CSS rule involving an external resource doesn't apply to the document as it's currently constructed, the browser doesn't request it.

This speculative behavior can be used to defer the loading of images in CSS by using JavaScript to determine when an element is within the viewport, and subsequently applying a class to that element that applies styling invoking a background image. This causes the image to be downloaded at the time of need instead of at initial load. For example, let's take an element that contains a large hero background image:

<div class="lazy-background">
  <h1>Here's a hero heading to get your attention!</h1>
  <p>Here's hero copy to convince you to buy a thing!</p>
  <a href="/buy-a-thing">Buy a thing!</a>
</div>

The div.lazy-background element would normally contain the hero background image invoked by some CSS. In this lazy loading example, however, you can isolate the div.lazy-background element's background-image property via a visible class added to the element when it's in the viewport:

.lazy-background {
  background-image: url("hero-placeholder.jpg"); /* Placeholder image */
}

.lazy-background.visible {
  background-image: url("hero.jpg"); /* The final image */
}

From here, use JavaScript to check if the element is in the viewport (with Intersection Observer!), and add the visible class to the div.lazy-background element at that time, which loads the image:

document.addEventListener("DOMContentLoaded", function() {
  var lazyBackgrounds = [].slice.call(document.querySelectorAll(".lazy-background"));

  if ("IntersectionObserver" in window) {
    let lazyBackgroundObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          entry.target.classList.add("visible");
          lazyBackgroundObserver.unobserve(entry.target);
        }
      });
    });

    lazyBackgrounds.forEach(function(lazyBackground) {
      lazyBackgroundObserver.observe(lazyBackground);
    });
  }
});

Effects on Largest Contentful Paint (LCP) #

Lazy loading is a great optimization that reduces both overall data usage and network contention during startup by deferring the loading of images to when they're actually needed. This can improve startup time, and reduce processing on the main thread by reducing time needed for image decodes.

However, lazy loading is a technique that can affect your website's Largest Contentful Paint LCP in a negative way if you're too eager with the technique. One thing you will want to avoid is lazy loading images that are in the viewport during startup.

When using JavaScript-based lazy loaders, you will want to avoid lazy loading in-viewport images because these solutions often use a data-src or data-srcset attribute as a placeholder for src and srcset attributes. The problem here is that the loading of these images will be delayed because the browser preload scanner can't find them during startup.

Even using browser-level lazy loading to lazy load an in-viewport image can backfire. When loading="lazy" is applied to an in-viewport image, that image will be delayed until the browser knows for sure it's in the viewport, which can affect a page's LCP.

Never lazy load images that are visible in the viewport during startup. It's a pattern that will affect your site's LCP negatively, and therefore the user experience. If you need an image at startup, load it at startup as quickly as possible by not lazy loading it!

Lazy loading libraries #

You should use browser-level lazy loading whenever possible, but if you find yourself in a situation where that isn't an option—such as a significant group of users still reliant on older browsers—the following libraries can be used to lazy-load images:

lazysizes is a full-featured lazy loading library that lazy-loads images and iframes. The pattern it uses is quite similar to the code examples shown here in that it automatically binds to a lazyload class on <img> elements, and requires you to specify image URLs in data-src and/or data-srcset attributes, the contents of which are swapped into src and/or srcset attributes, respectively. It uses Intersection Observer (which you can polyfill), and can be extended with a number of plugins to do things like lazy-load video. Find out more about using lazysizes.
vanilla-lazyload is a lightweight option for lazy loading images, background images, videos, iframes, and scripts. It leverages Intersection Observer, supports responsive images, and enables browser-level lazy loading.
lozad.js is a another lightweight option that uses Intersection Observer only. As such, it's highly performant, but will need to be polyfilled before you can use it on older browsers.
If you need a React-specific lazy loading library, consider react-lazyload. While it doesn't use Intersection Observer, it does provide a familiar method of lazy loading images for those accustomed to developing applications with React.

Lazy loading best practices

2019-08-16T00:00:00Z

While lazy loading images and video have positive and measurable performance benefits, it's not a task to be taken lightly. If you get it wrong, there could be unintended consequences. As such, it's important to keep the following concerns in mind.

Mind the fold #

It may be tempting to lazy-load every single media resource on the page with JavaScript, but you need to resist this temptation. Anything resting above the fold shouldn't be lazy-loaded. Such resources should be considered critical assets, and thus should be loaded normally.

Lazy loading delays the loading of resources until after the DOM is interactive when scripts have finished loading and begin execution. For images below the fold, this is fine, but critical resources above the fold should be loaded with the standard <img> element so they're displayed as soon as possible.

Of course, where the fold lies is not so clear these days when websites are viewed on so many screens of varying sizes. What lies above the fold on a laptop may well lie below it on mobile devices. There's no bulletproof advice for addressing this optimally in every situation. You'll need to conduct an inventory of your page's critical assets, and load those images in typical fashion.

Additionally, you may not want to be so strict about the fold line as the threshold for triggering lazy loading. It may be more ideal for your purposes to establish a buffer zone some distance below the fold so that images begin loading well before the user scrolls them into the viewport. For example, the Intersection Observer API allows you to specify a rootMargin property in an options object when you create a new IntersectionObserver instance. This effectively gives elements a buffer, which triggers lazy loading behavior before the element is in the viewport:

let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
  // lazy-loading image code goes here
}, {
  rootMargin: "0px 0px 256px 0px"
});

If the value for rootMargin looks similar to values you'd specify for a CSS margin property, that's because it is! In this case, the bottom margin of the observed element (the browser viewport by default, but this can be changed to a specific element using the root property) is broadened by 256 pixels. That means the callback function will execute when an image element is within 256 pixels of the viewport and the image will begin to load before the user actually sees it.

To achieve this same effect in browsers that don't support Intersection Observe, use scroll event handling code and adjust your getBoundingClientRect check to include a buffer.

Layout shifting and placeholders #

Lazy loading media can cause shifting in the layout if placeholders aren't used. These changes can be disorienting for users and trigger expensive DOM layout operations that consume system resources and contribute to jank. At a minimum, consider using a solid color placeholder occupying the same dimensions as the target image, or techniques such as LQIP or SQIP that hint at the content of a media item before it loads.

For <img> tags, src should initially point to a placeholder until that attribute is updated with the final image URL. Use the poster attribute in a <video> element to point to a placeholder image. Additionally, use width and height attributes on both <img> and <video> tags. This ensures that transitioning from placeholders to final images won't change the rendered size of the element as media loads.

Image decoding delays #

Loading large images in JavaScript and dropping them into the DOM can tie up the main thread, causing the user interface to be unresponsive for a short period of time while decoding occurs. Asynchronously decoding images using the decode method prior to inserting them into the DOM can cut down on this sort of jank, but beware: It's not available everywhere yet, and it adds complexity to lazy loading logic. If you want to use it, you'll need to check for it. Below shows how you might use Image.decode() with a fallback:

var newImage = new Image();
newImage.src = "my-awesome-image.jpg";

if ("decode" in newImage) {
  // Fancy decoding logic
  newImage.decode().then(function() {
    imageContainer.appendChild(newImage);
  });
} else {
  // Regular image load
  imageContainer.appendChild(newImage);
}

Check out this CodePen link to see code similar to this example in action. If most of your images are fairly small, this may not do much for you, but it can certainly help cut down on jank when lazy loading large images and inserting them into the DOM.

When stuff doesn't load #

Sometimes media resources fail to load for one reason or another and errors occur. When might this happen? It depends, but here's one hypothetical scenario for you: You have an HTML caching policy for a short period of time (e.g., five minutes), and the user visits the site or a user has a left a stale tab open for a long period of time (e.g., several hours) and comes back to read your content. At some point in this process, a redeployment occurs. During this deployment, an image resource's name changes due to hash-based versioning, or is removed altogether. By the time the user lazy-loads the image, the resource is unavailable, and thus fails.

While these are relatively rare occurrences, it may behoove you to have a backup plan if lazy loading fails. For images, such a solution may look something like this:

var newImage = new Image();
newImage.src = "my-awesome-image.jpg";

newImage.onerror = function(){
  // Decide what to do on error
};
newImage.onload = function(){
  // Load the image
};

What you decide to do in the event of an error depends on your application. For example, you could replace the image placeholder area with a button that allows the user to attempt to load the image again, or simply display an error message in the image placeholder area.

Other scenarios could arise as well. Whatever you do, it's never a bad idea to signal to the user when an error has occurred, and possibly give them an action to take if something goes awry.

JavaScript availability #

It shouldn't be assumed that JavaScript is always available. If you're going to lazy-load images, consider offering <noscript> markup that will show images in case JavaScript is unavailable. The simplest possible fallback example involves using <noscript> elements to serve images if JavaScript is turned off:

If JavaScript is turned off, users will see both the placeholder image and the image contained with the <noscript> elements. To get around this, place a class of no-js on the <html> tag like so:

<html class="no-js">

Then place one line of inline script in the <head> before any style sheets are requested via <link> tags that removes the no-js class from the <html> element if JavaScript is on:

<script>document.documentElement.classList.remove("no-js");</script>

Finally, use some CSS to hide elements with a class of lazy when JavaScript is unavailable:

.no-js .lazy {
  display: none;
}

This doesn't prevent placeholder images from loading, but the outcome is more desirable. People with JavaScript turned off get something more than placeholder images, which is better than placeholders and no meaningful image content at all.

Responsive web design basics

2019-02-12T00:00:00Z

The use of mobile devices to surf the web continues to grow at an astronomical pace, and these devices are often constrained by display size and require a different approach to how content is laid out on the screen.

Responsive web design, originally defined by Ethan Marcotte in A List Apart, responds to the needs of the users and the devices they're using. The layout changes based on the size and capabilities of the device. For example, on a phone users would see content shown in a single column view; a tablet might show the same content in two columns.

In this video the design moves from a narrow to a wide viewport, responding to the available screen real estate.

A multitude of different screen sizes exist across phones, "phablets," tablets, desktops, game consoles, TVs, and even wearables. Screen sizes are always changing, so it's important that your site can adapt to any screen size, today or in the future. In addition, devices have different features with which we interact with them. For example some of your visitors will be using a touchscreen. Modern responsive design considers all of these things to optimize the experience for everyone.

Set the viewport #

Pages optimized for a variety of devices must include a meta viewport tag in the head of the document. A meta viewport tag gives the browser instructions on how to control the page's dimensions and scaling.

To attempt to provide the best experience, mobile browsers render the page at a desktop screen width (usually about 980px, though this varies across devices), and then try to make the content look better by increasing font sizes and scaling the content to fit the screen. This means that font sizes may appear inconsistent to users, who may have to double-tap or pinch-to-zoom in order to see and interact with the content.

<!DOCTYPE html>
<html lang="en">
  <head>
    …
    <meta name="viewport" content="width=device-width, initial-scale=1">
    …
  </head>
  …

Using the meta viewport value width=device-width instructs the page to match the screen's width in device-independent pixels. A device (or density) independent pixel being a representation of a single pixel, which may on a high density screen consist of many physical pixels. This allows the page to reflow content to match different screen sizes, whether rendered on a small mobile phone or a large desktop monitor.

An example of how the page loads in a device without the viewport meta tag. See this example on Glitch.

An example of how the page loads in a device with the viewport meta tag. See this example on Glitch.

Some browsers keep the page's width constant when rotating to landscape mode, and zoom rather than reflow to fill the screen. Adding the value initial-scale=1 instructs browsers to establish a 1:1 relationship between CSS pixels and device-independent pixels regardless of device orientation, and allows the page to take advantage of the full landscape width.

The Does not have a <meta name="viewport"> tag with width or initial-scale Lighthouse audit can help you automate the process of making sure that your HTML documents are using the viewport meta tag correctly.

Ensure an accessible viewport #

In addition to setting an initial-scale, you can also set the following attributes on the viewport:

minimum-scale
maximum-scale
user-scalable

When set, these can disable the user's ability to zoom the viewport, potentially causing accessibility issues. Therefore we would not recommend using these attributes.

Size content to the viewport #

On both desktop and mobile devices, users are used to scrolling websites vertically but not horizontally; forcing the user to scroll horizontally or to zoom out in order to see the whole page results in a poor user experience.

When developing a mobile site with a meta viewport tag, it's easy to accidentally create page content that doesn't quite fit within the specified viewport. For example, an image that is displayed at a width wider than the viewport can cause the viewport to scroll horizontally. You should adjust this content to fit within the width of the viewport, so that the user does not need to scroll horizontally.

The Content is not sized correctly for the viewport Lighthouse audit can help you automate the process of detecting overflowing content.

Images #

An image has fixed dimensions and if it is larger than the viewport will cause a scrollbar. A common way to deal with this problem is to give all images a max-width of 100%. This will cause the image to shrink to fit the space it has, should the viewport size be smaller than the image. However because the max-width, rather than the width is 100%, the image will not stretch larger than its natural size. It is generally safe to add the following to your stylesheet so that you will never have a problem with images causing a scrollbar.

img {
  max-width: 100%;
  display: block;
}

Add the dimensions of the image to the img element #

When using max-width: 100% you are overriding the natural dimensions of the image, however you should still use the width and height attributes on your <img> tag. This is because modern browsers will use this information to reserve space for the image before it loads in, this will help to avoid layout shifts as content loads.

Layout #

Since screen dimensions and width in CSS pixels vary widely between devices (for example, between phones and tablets, and even between different phones), content should not rely on a particular viewport width to render well.

In the past, this required setting elements used to create layout in percentages. In the example below, you can see a two-column layout with floated elements, sized using pixels. Once the viewport becomes smaller than the total width of the columns, we have to scroll horizontally to see the content.

A floated layout using pixels. See this example on Glitch.

By using percentages for the widths, the columns always remain a certain percentage of the container. This means that the columns become narrower, rather than creating a scrollbar.

Modern CSS layout techniques such as Flexbox, Grid Layout, and Multicol make the creation of these flexible grids much easier.

Flexbox #

This layout method is ideal when you have a set of items of different sizes and you would like them to fit comfortably in a row or rows, with smaller items taking less space and larger ones getting more space.

.items {
  display: flex;
  justify-content: space-between;
}

In a responsive design, you can use Flexbox to display items as a single row, or wrapped onto multiple rows as the available space decreases.

CSS Grid Layout #

CSS Grid Layout allows for the straightforward creation of flexible grids. If we consider the earlier floated example, rather than creating our columns with percentages, we could use grid layout and the fr unit, which represents a portion of the available space in the container.

.container {
  display: grid;
  grid-template-columns: 1fr 3fr;
}

Grid can also be used to create regular grid layouts, with as many items as will fit. The number of available tracks will be reduced as the screen size shrinks. In the below demo, we have as many cards as will fit on each row, with a minimum size of 200px.

Multiple-column layout #

For some types of layout you can use Multiple-column Layout (Multicol), which can create responsive numbers of columns with the column-width property. In the demo below, you can see that columns are added if there is room for another 200px column.

Use CSS media queries for responsiveness #

Sometimes you will need to make more extensive changes to your layout to support a certain screen size than the techniques shown above will allow. This is where media queries become useful.

Media queries are simple filters that can be applied to CSS styles. They make it easy to change styles based on the types of device rendering the content, or the features of that device, for example width, height, orientation, ability to hover, and whether the device is being used as a touchscreen.

To provide different styles for printing, you need to target a type of output so you could include a stylesheet with print styles as follows:

<!DOCTYPE html>
<html lang="en">
  <head>
    …
    <link rel="stylesheet" href="print.css" media="print">
    …
  </head>
  …

Alternatively, you could include print styles within your main stylesheet using a media query:

@media print {
  /* print styles go here */
}

For responsive web design, we are typically querying the features of the device in order to provide a different layout for smaller screens, or when we detect that our visitor is using a touchscreen.

Media queries based on viewport size #

Media queries enable us to create a responsive experience where specific styles are applied to small screens, large screens, and anywhere in between. The feature we are detecting here is therefore screen size, and we can test for the following things.

width (min-width, max-width)
height (min-height, max-height)
orientation
aspect-ratio

All of these features have excellent browser support, for more details including browser support information see width, height, orientation, and aspect-ratio on MDN.

Media queries based on device capability #

Given the range of devices available, we cannot make the assumption that every large device is a regular desktop or laptop computer, or that people are only using a touchscreen on a small device. With some newer additions to the media queries specification we can test for features such as the type of pointer used to interact with the device and whether the user can hover over elements.

hover
pointer
any-hover
any-pointer

Try viewing this demo on different devices, such as a regular desktop computer and a phone or tablet.

These newer features have good support in all modern browsers. Find out more on the MDN pages for hover, any-hover, pointer, any-pointer.

Using `any-hover` and `any-pointer` #

The features any-hover and any-pointer test if the user has the capability to hover, or use that type of pointer even if it is not the primary way they are interacting with their device. Be very careful when using these. Forcing a user to switch to a mouse when they are using their touchscreen is not very friendly! However, any-hover and any-pointer may be useful if it is important to work out what kind of device a user has. For example, a laptop with a touchscreen and trackpad should match coarse and fine pointers, in addition to the ability to hover.

How to choose breakpoints #

Don't define breakpoints based on device classes. Defining breakpoints based on specific devices, products, brand names, or operating systems that are in use today can result in a maintenance nightmare. Instead, the content itself should determine how the layout adjusts to its container.

Pick major breakpoints by starting small, then working up #

Design the content to fit on a small screen size first, then expand the screen until a breakpoint becomes necessary. This allows you to optimize breakpoints based on content and maintain the least number of breakpoints possible.

Let's work through the example we saw at the beginning: the weather forecast. The first step is to make the forecast look good on a small screen.

The app at a narrow width.

Next, resize the browser until there is too much white space between the elements, and the forecast simply doesn't look as good. The decision is somewhat subjective, but above 600px is certainly too wide.

The app at a point where we feel we should tweak the design.

To insert a breakpoint at 600px, create two media queries at the end of your CSS for the component, one to use when the browser is 600px and below, and one for when it is wider than 600px.

@media (max-width: 600px) {

}

@media (min-width: 601px) {

}

Finally, refactor the CSS. Inside the media query for a max-width of 600px, add the CSS which is only for small screens. Inside the media query for a min-width of 601px add CSS for larger screens.

Pick minor breakpoints when necessary #

In addition to choosing major breakpoints when layout changes significantly, it is also helpful to adjust for minor changes. For example, between major breakpoints it may be helpful to adjust the margins or padding on an element, or increase the font size to make it feel more natural in the layout.

Let's start by optimizing the small screen layout. In this case, let's boost the font when the viewport width is greater than 360px. Second, when there is enough space, we can separate the high and low temperatures so that they're on the same line instead of on top of each other. And let's also make the weather icons a bit larger.

@media (min-width: 360px) {
  body {
    font-size: 1.0em;
  }
}

@media (min-width: 500px) {
  .seven-day-fc .temp-low,
  .seven-day-fc .temp-high {
    display: inline-block;
    width: 45%;
  }

  .seven-day-fc .seven-day-temp {
    margin-left: 5%;
  }

  .seven-day-fc .icon {
    width: 64px;
    height: 64px;
  }
}

Similarly, for the large screens it's best to limit to maximum width of the forecast panel so it doesn't consume the whole screen width.

@media (min-width: 700px) {
  .weather-forecast {
    width: 700px;
  }
}

Optimize text for reading #

Classic readability theory suggests that an ideal column should contain 70 to 80 characters per line (about 8 to 10 words in English). Thus, each time the width of a text block grows past about 10 words, consider adding a breakpoint.

The text as read on a mobile device.

The text as read on a desktop browser with a breakpoint added to constrain the line length.

Let's take a deeper look at the above blog post example. On smaller screens, the Roboto font at 1em works perfectly giving 10 words per line, but larger screens require a breakpoint. In this case, if the browser width is greater than 575px, the ideal content width is 550px.

@media (min-width: 575px) {
  article {
    width: 550px;
    margin-left: auto;
    margin-right: auto;
  }
}

Avoid simply hiding content #

Be careful when choosing what content to hide or show depending on screen size. Don't simply hide content just because you can't fit it on the screen. Screen size is not a definitive indication of what a user may want. For example, eliminating the pollen count from the weather forecast could be a serious issue for spring-time allergy sufferers who need the information to determine if they can go outside or not.

View media query breakpoints in Chrome DevTools #

Once you've got your media query breakpoints set up, you'll want to see how your site looks with them. You could resize your browser window to trigger the breakpoints, but Chrome DevTools has a built-in feature that makes it easy to see how a page looks under different breakpoints.

DevTools showing the weather app as it looks at a wider viewport size.

DevTools showing the weather app as it looks at a narrower viewport size.

To view your page under different breakpoints:

Open DevTools and then turn on Device Mode. This opens in responsive mode by default.

To see your media queries, open the Device Mode menu and select Show media queries to display your breakpoints as colored bars above your page.

Click on one of the bars to view your page while that media query is active. Right-click on a bar to jump to the media query's definition.

Using the HTML5 Drag and Drop API

2010-09-30T00:00:00Z

The HTML5 Drag and Drop API means that we can make almost any element on our page draggable. In this post we'll explain the basics of drag and drop.

Creating draggable content #

It's worth noting that in most browsers, text selections, images, and links are draggable by default. For example, if you drag a link on a web page you will see a small box with a title and URL. You can drop this box on the address bar or the desktop to create a shortcut or to navigate to the link. To make other types of content draggable you need to use the HTML5 Drag and Drop APIs.

To make an object draggable set draggable=true on that element. Just about anything can be drag-enabled: images, files, links, files, or any markup on your page.

Our example creates an interface to rearrange columns that have been laid out with CSS Grid. The basic markup for the columns looks like this, with each column having the draggable attribute set to true.

<div class="container">
  <div draggable="true" class="box">A</div>
  <div draggable="true" class="box">B</div>
  <div draggable="true" class="box">C</div>
</div>

Here's the CSS for the container and box elements. Note that the only CSS related to drag and drop functionality is the cursor: move property. The rest of the code just controls the layout and styling of the container and box elements.

.container {
  display: grid;
  grid-template-columns: repeat(5, 1fr);
  gap: 10px;
}

.box {
  border: 3px solid #666;
  background-color: #ddd;
  border-radius: .5em;
  padding: 10px;
  cursor: move;
}

At this point you will find that you can drag the items, however nothing else will happen. To add the drag and drop functionality we need to use the JavaScript API.

Listening for dragging events #

There are a number of different events to attach to for monitoring the entire drag and drop process.

To handle the drag and drop flow, you need some kind of source element (where the drag originates), the data payload (what you're trying to drop), and a target (an area to catch the drop). The source element can be an image, list, link, file object, block of HTML, etc. The target is the drop zone (or set of drop zones) that accepts the data the user is trying to drop. Keep in mind that not all elements can be targets, for example an image can't be a target.

Starting and ending a drag and drop sequence #

Once you have draggable="true" attributes defined on your content, attach a dragstart event handler to kick off the drag and drop sequence for each column.

This code will set the column's opacity to 40% when the user begins dragging it, then return it to 100% when the dragging event ends.

function handleDragStart(e) {
  this.style.opacity = '0.4';
}

function handleDragEnd(e) {
  this.style.opacity = '1';
}

let items = document.querySelectorAll('.container .box');
items.forEach(function (item) {
  item.addEventListener('dragstart', handleDragStart);
  item.addEventListener('dragend', handleDragEnd);
});

The result can be seen in the Glitch demo below. Drag an item and it becomes opaque. As the dragstart event's target is the source element, setting this.style.opacity to 40% gives the user visual feedback that the element is the current selection being moved. Once you drop the item, although the drop functionality is not in place, the source element returns to 100% opacity.

Add additional visual cues with `dragenter`, `dragover`, and `dragleave` #

To help the user understand how to interact with your interface, use the dragenter, dragover and dragleave event handlers. In this example the columns are drop targets in addition to being draggable. Help the user to understand this by making the border dashed as they hold a dragged item over a column. For example, in your CSS you might create an over class to represent elements that are drop targets:

.box.over {
  border: 3px dotted #666;
}

Then, in your JavaScript set up the event handlers, add the over class when the column is dragged over, and remove it when we leave. In the dragend handler we also make sure to remove the classes at the end of the drag.

document.addEventListener('DOMContentLoaded', (event) => {

  function handleDragStart(e) {
    this.style.opacity = '0.4';
  }

  function handleDragEnd(e) {
    this.style.opacity = '1';

    items.forEach(function (item) {
      item.classList.remove('over');
    });
  }

  function handleDragOver(e) {
    e.preventDefault();
    return false;
  }

  function handleDragEnter(e) {
    this.classList.add('over');
  }

  function handleDragLeave(e) {
    this.classList.remove('over');
  }

  let items = document.querySelectorAll('.container .box');
  items.forEach(function(item) {
    item.addEventListener('dragstart', handleDragStart);
    item.addEventListener('dragover', handleDragOver);
    item.addEventListener('dragenter', handleDragEnter);
    item.addEventListener('dragleave', handleDragLeave);
    item.addEventListener('dragend', handleDragEnd);
    item.addEventListener('drop', handleDrop);
  });
});

There are a couple of points worth covering in this code:

The default action for dragover event is to set the dataTransfer.dropEffect property to "none". The dropEffect property is covered later in this article. For now, just know that it prevents the drop event from being fired. To override this behavior, call e.preventDefault(). Another good practice is to return false in that same handler.
The dragenter event handler is used to toggle the over class instead of dragover. If you use dragover, the CSS class would be toggled many times as the event dragover continued to fire on a column hover. Ultimately, that would cause the browser's renderer to do a large amount of unnecessary work. Keeping redraws to a minimum is always a good idea. If you need to use the dragover event for something, consider throttling or debouncing your event listener.

Completing the drop #

To process the actual drop, add an event listener for the drop event. In the drop handler, you'll need to prevent the browser's default behavior for drops, which is typically some sort of annoying redirect. You can prevent the event from bubbling up the DOM by calling e.stopPropagation().

function handleDrop(e) {
  e.stopPropagation(); // stops the browser from redirecting.
  return false;
}

Be sure to register the new handler in amongst the other handlers:

  let items = document.querySelectorAll('.container .box');
  items.forEach(function(item) {
    item.addEventListener('dragstart', handleDragStart);
    item.addEventListener('dragover', handleDragOver);
    item.addEventListener('dragenter', handleDragEnter);
    item.addEventListener('dragleave', handleDragLeave);
    item.addEventListener('dragend', handleDragEnd);
    item.addEventListener('drop', handleDrop);
  });

If you run the code at this point, the item will not drop to the new location. To achieve this you need to use the DataTransfer object.

The dataTransfer property is where all the drag and drop magic happens. It holds the piece of data sent in a drag action. dataTransfer is set in the dragstart event and read/handled in the drop event. Calling e.dataTransfer.setData(mimeType, dataPayload) lets you set the object's MIME type and data payload.

In this example, we're going to allow users to rearrange the order of the columns. To do that, first you need to store the source element's HTML when the drag starts:

function handleDragStart(e) {
  this.style.opacity = '0.4';

  dragSrcEl = this;

  e.dataTransfer.effectAllowed = 'move';
  e.dataTransfer.setData('text/html', this.innerHTML);
}

In the drop event you process the column drop, setting the source column's HTML to the HTML of the target column that you dropped on, first checking that the user is not dropping back onto the same column they dragged from.

function handleDrop(e) {
  e.stopPropagation();

  if (dragSrcEl !== this) {
    dragSrcEl.innerHTML = this.innerHTML;
    this.innerHTML = e.dataTransfer.getData('text/html');
  }

  return false;
}

You can see the result in the following demo. For this to work, you'll need a desktop browser. The Drag and Drop API isn't supported on mobile. Drag and release the A column on top of the B column and notice how they change places:

More dragging properties #

The dataTransfer object exposes properties to provide visual feedback to the user during the drag process. These properties can also be used to control how each drop target responds to a particular data type.

dataTransfer.effectAllowed restricts what 'type of drag' the user can perform on the element. It is used in the drag-and-drop processing model to initialize the dropEffect during the dragenter and dragover events. The property can be set to the following values: none, copy, copyLink, copyMove, link, linkMove, move, all, and uninitialized.
dataTransfer.dropEffect controls the feedback that the user is given during the dragenter and dragover events. When the user hovers over a target element, the browser's cursor indicates what type of operation is going to take place (e.g. a copy, a move, etc.). The effect can take one of the following values: none, copy, link, move.
e.dataTransfer.setDragImage(imgElement, x, y) means that instead of using the browser's default 'ghost image' feedback, you can optionally set a drag icon.

File upload with drag and drop #

This simple example uses a column as both the drag source and drag target. This might be seen in a UI where the user is asked to rearrange the items. In some situations the drag target and source may be different, such as an interface where the user needs to select one image to be the main image for a product by dragging the selected image onto a target.

Drag and Drop is frequently used to allow users to drag items from their desktop into an application. The main difference is in your drop handler. Instead of using dataTransfer.getData() to access the files, their data will be contained in the dataTransfer.files property:

function handleDrop(e) {
  e.stopPropagation(); // Stops some browsers from redirecting.
  e.preventDefault();

  var files = e.dataTransfer.files;
  for (var i = 0, f; (f = files[i]); i++) {
    // Read the File objects in this FileList.
  }
}

You can find more information about this in Custom drag-and-drop.

Rachel Andrew on web.dev

New to the web platform in September

Stable browser releases #

Beta browser releases #

Submit your proposals for Interop 2024

New to the web platform in August

Stable browser releases #

Beta browser releases #

New to the web platform in July

Stable browser releases #

Multiple values for the CSS display property #

Scroll-driven animations #

Privacy Sandbox APIs #

The animation-composition property #

Array methods #

Beta browser releases #

New to the web platform in June

Stable browser releases #

WebTransport API #

The SVG crossorigin attribute #

Beta browser releases #

New CSS color spaces and functions in all major engines

Accessing color spaces from CSS #

The color-mix() function #

New to the web platform in May

Stable browser releases #

WebGPU #

First-Party Sets #

CSS media features and more #

CSS Color Level 4 features #

More control over :nth-child() selections #

Compressions Streams API #

CSS nesting #

Balancing headlines with text-wrap: balance #

CHIPS: Cookies Having Independent Partitioned State #

The Popover API #

Beta browser releases #

Introducing Baseline

Keeping up with changes to the web platform #

Getting our own house in order #

Working with others #

Creating platform-wide clarity with Baseline #

What's next? #

New to the web platform in April

Stable browser releases #

The inert attribute #

The linear() easing function #

CSS nesting #

CSS animation-composition #

New headless mode #

Beta browser releases #

New to the web platform in March

Stable browser releases #

Global HTML attributes #

Origin Private File System (OPFS) #

The View Transitions API #

New CSS color spaces and functions #

More control over :nth-child() selections #

Support for previous and next slide in the Media Session API #

Pseudo-class support in Safari #

New range syntax for media queries #

CSS Properties and Values #

CSS API support #

Web Push and the Badging API #

Import maps #

Beta browser releases #

New to the web platform in February

Stable browser releases #

Container queries in all three engines #

CSS initial letters #

ReadableStream async iteration #

AudioContext.setSinkId() #

IFrame credentialless #

Early stable #

Beta browser releases #

Introducing Learn Privacy

All of Learn HTML! is available

Last baseline alignment

First baseline alignment #

Last baseline alignment #

Multiple values for the CSS `display` property #

The `animation-composition` property #

The SVG `crossorigin` attribute #

The `color-mix()` function #

More control over `:nth-child()` selections #

Balancing headlines with `text-wrap: balance` #

The `inert` attribute #

The `linear()` easing function #

CSS `animation-composition` #

More control over `:nth-child()` selections #

The `scrollend` event #

The `lh` CSS length unit and `hyphenate-limit-chars` #

Content-Security-Policy (CSP) `prefetch-src` #

Support for `height` and `width` attributes of `<source>` #

CSS `font-variant-alternates` #

Support for the CSS fragmentation `avoid` keyword #

Additions to `getDisplayMedia()` #