#chrome#web design#what's new
Facundo Corradini
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:

Using CRDTs To Build Collaborative Rust Web Applications

Using CRDTs to build collaborative Rust web applications

CRDTs, or conflict-free replicated data types, is a concept that underlies applications facing the issue of data replication across a […]

Mario Zupan
Feb 23, 2024 ⋅ 15 min read
Guide to Using TensorFlow in Rust

Guide to using TensorFlow in Rust

We explore the fusion of TensorFlow and Rust, delving into how we can integrate these two technologies to build and train a neural network.

Rosario De Chiara
Feb 22, 2024 ⋅ 8 min read
Using Signaldb With React

Using SignalDB with React: A complete guide

SignalDB enables automatic data synchronization between your components and a local in-memory or persistent database.

Antonello Zanini
Feb 20, 2024 ⋅ 6 min read
Guide To Next Js Layouts And Nested Layouts

A guide to Next.js layouts and nested layouts

Understanding how layouts, nested layouts, and custom layouts work in Next.js is crucial for building complex, user-friendly projects.

Ibadehin Mojeed
Feb 19, 2024 ⋅ 12 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