backdrop-filter demo says the feature is not supported by Safari (but it is)

[electrovir]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/CSS/backdrop-filter

What specific section or headline is this issue about?

Try It

What information was incorrect, unhelpful, or incomplete?

The "Try It" demo says This feature is not supported by your current browser. Check Browser compatibility for more details. However, it is supported in my browser: the browser compatibility chart says it's supported and I'm using it right now in my own code (and it works).

What did you expect to see?

The demo

Do you have any supporting links, references, or citations?

Using Safari Version 16.3

Do you have anything more you want to share?

No response

MDN metadata

Page report details

• Folder: en-us/web/css/backdrop-filter
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/CSS/backdrop-filter
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/css/backdrop-filter/index.md
• Last commit: mdn/content@42c1bb8
• Document last modified: 2023-02-21T06:27:49.000Z

[Josh-Cena]

Hi, this feature is actually not supported.

document.createElement("div").style.backdropFilter; // returns undefined in Safari

You can try a minimal example:

<div style="background-image: url('https://interactive-examples.mdn.mozilla.net/media/examples/balloon.jpg'); width: 250px; height: 300px; display: flex; justify-content: center; flex-direction: column;">
  <div style="backdrop-filter: blur(10px); text-align: center;">
    <p>Hello</p>
  </div>
</div>

This doesn't work in my Safari 16.3. The reason why the live example below works is because it uses the -webkit-backdrop-filter: blur(10px); fallback, which is mentioned in the compat table:

Implemented with the vendor prefix: -webkit-

[electrovir]

Does that not count as support? It just seems strange to me that the demo up top would show an error like that when it's trivial to make it work (just add the prefix).

[Josh-Cena]

Well, the demo demonstrates the un-prefixed API. It could try to automatically "polyfill" with prefixes, but that would be hard to generalize since you can edit the CSS however you wish. In that case this would be re-purposed as an enhancement request.

[NiedziolkaMichal]

We could apply autoprefixer for CSS properties used in the initial example and make it work even if the user changes a property value. Making it work for all possible properties would probably significantly increase bundle size, but I think users very rarely edit the example to a completely different property, so it's not really needed.

[Josh-Cena]

I reckon the bundle size won't be huge (especially since it can be lazy-loaded), but wondering whether it would create more confusions (why something is allegedly not available but still working, etc.)

[NiedziolkaMichal]

@Josh-Cena 256kb minified. I guess for CSS properties that were entered by the user in a "choice box", we could just apply all vendor prefixes without even checking if they exist, but it wouldn't work for rare cases in which property is implemented under a bit different property name.

[wbamberg]

FWIW we use prefixes manually in examples sometimes: https://developer.mozilla.org/en-US/docs/web/css/box-decoration-break.

I think applying but hiding prefixes (if that is the suggestion) would be very confusing for people.

[NiedziolkaMichal]

@wbamberg How about if the editor would show either prefixed property or unprefixed property, based on what it supports?

In the backdrop-filter example, Chrome would show:

and Safari would show:

[wbamberg]

I think this would be fine. Main thing is that what people see in the editor should be what's actually getting used :).