2019-07-31
787
#chrome#web design#what's new
Facundo Corradini
4338
Jul 31, 2019 ⋅ 2 min read

New in Chrome 76: The frosted glass effect with backdrop-filter

Facundo Corradini Frontend developer, CSS specialist, best cebador de mates ever.

Recent posts:

How to Use React Router v6 in React Apps

How to use React Router v7 in React apps

A practical guide to React Router v7 that walks through declarative routing, nested layouts, dynamic routes, navigation, and protecting routes in modern React applications.

Aman Mittal
Jan 16, 2026 ⋅ 15 min read

TanStack AI vs. Vercel AI SDK: Choosing the right AI library for React

TanStack AI vs. Vercel AI SDK for React: compare isomorphic tools, type safety, and portability to pick the right SDK for production.

Ikeh Akinyemi
Jan 16, 2026 ⋅ 8 min read
Authentication With React Router V6: A Complete Guide

Authentication with React Router v7: A complete guide

Handle user authentication with React Router v7, with a practical look at protected routes, two-factor authentication, and modern routing patterns.

Vijit Ail
Jan 15, 2026 ⋅ 15 min read

A developer’s guide to designing AI-ready frontend architecture

AI now writes frontend code too. This article shows how to design architecture that stays predictable, scalable, and safe as AI accelerates development.

Nelson Michael
Jan 15, 2026 ⋅ 9 min read
View all posts

2 Replies to "New in Chrome 76: The frosted glass effect with backdrop-filter"

  1. Instead of writing

    @supports (backdrop-filter: none) {

    backdrop-filter: blur(8px);

    }

    one should be writing

    @supports (backdrop-filter: blur(8px)) {

    backdrop-filter: blur(8px);

    }

    because you’re not in fact interested if the browser supports “backdrop-filter: none”, right?

    This is especially important once you realize that the same property (e.g. display) supports values with wide range of support by different UAs.

  2. Hi Mikko,

    The idea is to query the support of the property instead of the value. Querying for “backdrop-filter: none” will throw the same true / false result as querying for “backdrop-filter: 8px”, but allow us to change the value in a single place if for whatever reason we decide to do that in the future.

    It might not be such a dramatic impact in the small scale, but going with a query for property+value can lead to issues as the codebase grows and we start to have a lot of repetition and forgotten queries that doesn’t really make sense.

    Your point is certainly valid for properties such as display or position, but for most others, querying for property instead of property+value is a better approach in my opinion.

Leave a Reply

Would you be interested in joining LogRocket's developer community?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now