New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 394 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-07-01
OS: All
Pri: 2
Type: Feature


Sign in to add a comment

Implement backdrop-filter from Filter Effects Module Level 2

Reported by baileypa...@gmail.com, Jun 7 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2421.0 Safari/537.36

Example URL:
http://jsbin.com/fibokagifo/1/edit?html,css,output

Steps to reproduce the problem:
1. Visit http://jsbin.com/fibokagifo/1/edit?html,css,output
2. The box's background should be a blurred version of its backdrop
3. Adjusting the sliders should change the effect

What is the expected behavior?
The box has a background of a blurred version of its backdrop.

What went wrong?
The backdrop-filter property isn't supported, so nothing.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? No 

Does this work in other browsers? No Everything that isn't webkit nightlies...so admittedly everything

Chrome version: 45.0.2421.0  Channel: canary
OS Version: OS X 10.10.3
Flash Version: Shockwave Flash 18.0 r0

This has already been implemented in Webkit nightlies (although a few months later and its still in the nightlies). Could this be implemented in Chromium nightlies as well?
 
Showing comments 36 - 135 of 135 Older

Comment 36 by trusktr@gmail.com, Dec 15 2015

In the second image, assume there's also CSS perspective applied.
Blockedon: chromium:570040
This is a spectacular feature, that makes possible some stunning designs, therefore I hope the implementation will be hardened a bit. Some informal feedback:

- As mentioned above here already by another user, when an element has backdrop filter and a box-shadow, the backdrop filter is also applied to the box-shadow area, which is incorrect. Webkit on iOS does not do this.

- I'm experiencing some buggy behavior wrt scrolling. The situation is a header bar that lies on top of a background image, where the header bar has a backdrop filter: blur applied. When I scroll with my mouse wheel, there is this flashing square in the top left corner, as if there is some redrawing issue. Strangely, when scrolling by dragging the scroll bar down, this issue does not occur.

- This next one I am not sure about, whether it is a feature or a bug. Imagine you have a fixed bar of 960px by 100px. this bar lies on top of a 960px by 600px image. The fixed bar has a blur backdrop filter applied. Imagine that the image is overall a deep blue. However, the background of the overall web page is white. What I am experiencing is that the edges of the header bar have a blurred white tone. What I was expecting is for the backdrop filter to only blur the underlying element, the image, however, it also seems to blur the webpage as a whole, hence the white creeping into the corners of the element. It seems the effect is not contained, if that makes sense.

Comment 39 Deleted

Comment 40 by phistuck@gmail.com, Jan 18 2016

Please, make sure all of the issues are filed separately (obviously, do not duplicate existing separate issues). You can comment here with all of the issue numbers so we could mark them as blocking this.
@ferdy, point 3 seems to be a feature. It works like that in OS X Yosemite. It should blur anything that's beneath it.
@beni: But in my interpretation, the white of the page background is not underneath it, it is underneath it in terms of layers (Z), but it sits on the side of the blurred element. I would not expect it to creep in like that, it makes a very common use case look quite ugly. Anyway, if this is as intended, so be it :) 
@ferdy I too think that the behavior is incorrect. It essentially samples the pixels for blurring outside of the element's borders. It makes sense at the implementation level, but I don't think that is the desired/expected effect. 
@beni: thank you, at least I'm not alone in thinking this :)
@ferdy I think you're right afterall. This does work differently in Safari right now.

I've been playing around with this in Safari and Chrome Canary and there do appear to be some differences. I've put this test online: http://benimation.nl/backdrop

The first difference is when you disable the animation. For some reason it works the same as in Safari when animated, but differently when standing still. When it's still it has some white "bleeding" into it.

The 2nd difference I notice is that it doesn't work together with mix-blend-mode. This does work in Safari. (see screenshot)
Screen-Shot-2016-02-29-at-4.36.13-PM.jpg
1.3 MB View Download
Folks, all of your comments and reports are appreciated. However, it's much easier for the Chrome team if each issue is reported as a separate bug, with its own repro steps and reduced test case. That way, they can be triaged, tracked and fixed separately. Thanks!
@senorblanco. You are right, and sorry for the informal level of feedback. I just want to say that isolating these issues into a reproducible test case and properly reporting them costs a lot of time, which I do not have. It's not an excuse, just an explanation.
Did something happen to this feature? None of the demos work anymore for me.

Comment 49 by h...@ashleyw.co.uk, May 16 2016

@ferdy:  `-webkit-backdrop-filter` no longer works, but `backdrop-filter` does (assuming you've enabled #enable-experimental-web-platform-features)
@ashley: I do have experimental web platform features enabled, and still it never works for me in Chrome, where before it did, regardless of which of the two properties I use. It's not working at all in any of the public codepens either. 

Example codepen:
http://codepen.io/joshuapekera/pen/waPVjN

If I remove the -webkit- prefix from the property there, the whole thing just turns black. Are you getting the same results as me?
ferdy.christant: could you open a new bug for this regression, and attach the results of about:gpu on the affected machine to it? At this point I'm suspecting something configuration-specific. Thanks!
Done, and I think you're right that it may be a local issue. I did a browserstack test and there I had no issues. Issue created:
https://bugs.chromium.org/p/chromium/issues/detail?id=612238&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

Comment 53 by gabri...@gavro.nl, Jul 1 2016

It seems that Chrome is handling the backdrop-filter differently than other webkit based browsers. See attachments; Safari [9.1.1 (11601.6.17)] vs Chrome [52.0.2743.60 beta (64-bit)].

Chrome is applying the filter to any present box-shadows as well. I'd say: Apply the filter to inset box shadows, not to regular box shadows (treat as 'outside the bounding box').

Used filter:
  backdrop-filter: blur(10px);
  -webkit-backdrop-filter: blur(10px);

Box shadow:
  box-shadow: 0 1px 3px 0 rgba(0, 0, 0, 0.1);

(it doesn't matter what kind of box-sizing is applied)
safari.png
157 KB View Download
chrome.png
125 KB View Download
I agree with @gabri, and have reported this earlier. It makes no sense that the shadow of the current element is blurred, the whole point of "backdrop" is to apply to the layer beneath.

Comment 55 by f...@opera.com, Jul 1 2016

Blockedon: 618913
That bug has been reported as issue 618913. I'll set it as blocking this.
If it doesn’t go against the spec, I think that the filter should only apply to behind the area limited by `border-radius`.
Indeed an interesting feature - what's the status on the implementation of this? 

Comment 58 by pat...@grabyo.com, Sep 21 2016

Yeah, when is this coming out?
Hi there :) Any updates about this feature? We are really looking forward to use it in our products.
Working fine here if you enabled the new features, although it does NOT work with the -webkit prefix.  Also, it seems to only work on previous layer IMG tags, not on   images that are part of element's background ... ie works on elements, not element backgrounds.  I don't know if this is a bug or feature.

Comment 61 by phistuck@gmail.com, Sep 23 2016

The -webkit- prefixed property is not supposed to work, so this is by design.
I am not sure regarding the background-image. I expected it to be filtered as well.
https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4502
But it is not.
I looking for this feature!!! 
Blockedon: 593307
Blockedon: 615722
Blockedon: 582219
Blockedon: 547937
Blockedon: 632979
Owner: jaydasika@chromium.org
Blockedon: 659501
jaydasika@, what is the current status of this work? Predictability program has set an OKR to gain traction on the top 50 starred bugs this quarter: either by closing them, stating what milestone the fix will ship, or setting a NextAction date so that we know when to check back.
NextAction: 2017-04-03
I am focusing this quarter completely on finishing up work on cc property trees and will not be able to do anything for this bug. So, setting the NextAction date to beginning of next quarter. 

Comment 74 Deleted

Thanks, jaydasika@. So, is this work planned for next quarter, or is that when you will assess if that is the case?
How does the work going? When can we expect to be able to use the feature? Thanks for informations and good luck !
Components: -Blink>CSS>Filters Blink>Compositing>Filters
Cc: chrishtr@chromium.org
NextAction: 2017-07-01
I don't expect much work to happen for this in Q2 as we decided not to have a OKR for this in Q2. Setting the NextAction date to beginning of next quarter. 
Blockedon: 626762
Owner: ----
Status: Available (was: Assigned)

Comment 81 by m14...@gmail.com, May 13 2017

Hi. Does it mean it will be released in chrome on July 1st 2017? (version 62?)
I hope for it so much, this feature would be really game changing for web design, I can't wait for it !

Comment 83 by phistuck@gmail.com, May 13 2017

#81 - it only means the team will not get to it before July 1st. The team may get to it a lot later. No time frame at all.

Comment 84 by m14...@gmail.com, May 13 2017

Oh ok. Thank you for the clarification. I was confused by this `Status:	Available`. Thanks!

Comment 85 by phistuck@gmail.com, May 13 2017

If the status is Fixed or Verified, it means that the feature is fully implemented (modulo bugs). The rest of them means it is not fully implemented yet.
Hallo! Just wanted to add (I am sure you already know this, but just incase) that when you set a border-radius, the filter does not abide by the rules. For instance, if you use the blur filter, you will still see a square blur, not a cornered blur.
I updated https://bugs.chromium.org/p/chromium/issues/detail?id=618913 but I don't know how to re-open it. I think someone else needs to.

The border-radius bug is related to that one, because the basic problem is that the effect is not clipped to the edges of the background painting area.
The NextAction date has arrived: 2017-07-01

Comment 89 by xxep...@gmail.com, Jul 13 2017

I'd love to see this feature this year. It will change the look of the internet.

Comment 90 Deleted

I strongly endorse the Comment 89. Examples of real world use cases: blur filters in context menus, sidebars, toolbars, docks, are out there for a considerable amount of time now, firstly in macOS and iOS and more recently in Windows 10 with the Fluent Design System. It's more than time for the Web to evolve into a path that avoids us using hacks to solve trivial design problems. A terrible hack with duplicated background fixed images (https://codepen.io/ErickPetru/pen/eRzBgJ) would be so easily solved with backdrop-filter (https://codepen.io/ErickPetru/pen/GEzyVW)
@Eric: Backdrop blurs date as far back as Windows 7, aero theme. Not that it matters, just to agree it's about time we get this on the web. Gimmick or not, sometimes the web needs something exciting and beautiful. 

Would be great to get it working on chrome rather soon. I agree, I don't think it is only a gimmick, it adds value and new possibilities for the web.
I agree with everyone, Chrome really need this feature, It's anormal that Safari already have it for years instead of Chrome...
Do these comment have any effect? Does Google prioritize thing based on user feedback?

Comment 96 by phistuck@gmail.com, Jul 20 2017

#95 - they probably have a negative effect (waste the time of Chrome engineers).
Interested people should just star the issue instead of adding a me-too comment, unless it mentions a yet-unmentioned use case.
Concur with #93 - this is not some "nice to have" it really is a significant ability to filter the things below a div in a z-organized stack of elements. I will add that Android material design, ios/macos, and windows 10 fluent design all provide this kind of functionality.
Computationally blur is expensive. Hopefully Chromium developers are taking the time to carefully consider how to maintain good user experience (in terms of performance and battery life). 

Comment 99 by gar...@cityseer.io, Aug 14 2017

Hugely useful feature. Any chance of an update on general progress / prospects for general release?
yes, this would be awesome.

Comment 101 by d2p...@gmail.com, Aug 29 2017

my most expected feature of this year!
I would really like to see this feature land in Firefox (and all other browsers). It is such a simple and powerful way to achieve effects that make UIs easier on the eyes, more readable, etc. (Sharp text on top of blurred backgrounds is far easier to read and more 'natural' for our eyes to make sense of than the same text on top of a semi-opaque but still-crisp background.) 

The blur-behind paradigm has been crucial for Apple UIs for a very long time and it would be really great to have simple parity in this regard on the Web.

I know that a similar effect is possible by blurring everything except the foreground, but this is not a practical approach very often, and it breaks the principle that components/widgets/elements/etc should only care about their own concerns. With backdrop-filter, I can ship a modal dialog implementation with a backdrop that blurs whatever is behind it. I do not have to touch anything else in the document. Without backdrop-filter, I have no other choice but to go and blur everything else manually, which may not even be possible if the rest of the page is re-rendering itself and discarding my DOM manipulations.

Been using/testing this feature for the past few days. Yesterday after an update to Chrome the blur effect seems a lot more stable (it was a bit twitchy before, for lack of a better word)

Is this an indication that it will be ready soon? 

:)
Blockedon: 767997
Is there any hint about a potential public release date yet?

From what I see in the with the flag enabled, the filter looks quite good actually.
The feature is on hold and no further development is happening. No timeline yet
on when it might be finished, sorry.

Comment 107 by trusktr@gmail.com, Nov 25 2017

We can learn how to achieve this in vanilla WebGL faster than waiting for this to be released. xD

But seriously, this would be an awesome feature to have. Just imagine the beauty that UIs will have with this feature. It would be a huge benefit for the web if all browsers had this.
Other browsers: Edge, Windows 10 build 17063: CSS backdrop-filter is now enabled by default
Comment 106 from chrishtr@chromium.org:

For real? Is this a real statement about this highly requested and demanded feature? We users, we web designers and developers need this feature, is a all new way to build awesome UI's for our users! Please, don't let this feature to drop. 

By the way: Edge 17 support this feature by default in Windows 10 Insider Preview Build 17063. So we have to move to Edge?


 Issue 798267  has been merged into this issue.
It's been 2.5 years now of having a 80% implementation with no sign of getting to a full implementation. With Apple having this for years now, Edge having it soon and Firefox committed to it, this could be the year to bring this to the web across the board.

I really hope the priority gets bumped. It seems starring the issue is the go-to way for democratic voting, but the backlog seems full of issues with 10 times more stars for issues that are tiny, having little value to only a tiny user base. Whilst this is a design game changer across the board.

I respect that we don't fully control priority, but this one is so close and halting for so long, whilst being such a delightful feature. 

Sorry, I'm just passionate about this one. I can't help with coding but willing to help in testing.
All: please star this issue if you would like it implemented, rather than
commenting further. We use stars as one measure of whether to implement a 
feature.
Blockedon: 813796
I think chrome guys are that jealous of Apple, Since Apple products seems to use more blur filters including iOS. other than that no reason to implement this feature already in chrome.
#114 - Blur filters would be a very nice feature to have, both from the design aesthetics perspective, and also have more practical uses (eg focusing user attention on areas of the screen requiring their attention.)

Yes, Apple use it a lot, to good effect, so no harm in giving them credit for taking the lead. But we also see Edge supporting it, and Firefox committed to it too. So soon it will just be Chrome perceived as the one left behind, as the down-level browser with 'ugly' looking sites.

Jealous? Maybe, but more positively, excited with the anticipation of being able to use it once the bugs round the edges are ironed out. Either way, I'd encourage anyone who wants to see this to star it. Let's get it done!
A full page div with backdrop filter result in vignette like appearance over the edges of my screen. 
Screenshot_20180328-222840.jpg
551 KB View Download
I definitely support adding this. Our designers are asking for it, and it'd help us out a lot!
Back in January at #112 chrishtr@chromium.org said "All: please star this issue if you would like it implemented, rather than commenting further. We use stars as one measure of whether to implement a feature." and since then we've had a lot more people starring this - right now it is at 300, and it has leapfrogged a large number of other issues.

So it would be great to have some insight into the official thinking about how this fits into current priorities, given how popular this would be.
Wouldn't this be easier to implement in Chrome since it's already in Safari stable?
we designers really need this !
Yeah, this is really a good effect to have as soon as Safari and Edge are already including it ! Thanks
I'm a designer and would really appreciate this being implemented in Chrome! Especially since the other browsers already support it. Thank you!
I use this feature too and would appreciate it being prioritized.
Any updates on this?
Waiting for that since 3.5 years now
That's the only thing I'm missing for a perfect interface

Agree with comment 118: we were asked to star. We did. Current position is #15 in the total list. Serious question:  how many stars does it take to get this issue moving again?

What's the status of this? It's an amazing feature and Safari and Edge already support it (without a flag).

I noticed apple.com is actually already using this in their menu bar.
I suspect we need to demonstrate the desire in the design community for this, and I suggest a multi-pronged approach:

First, get as many stars as possible: tell your friends and colleagues, and get them to do so too. Let's get the numbers of stars right up. They asked for stars; let's give them stars!

Secondly, as part of that, but also to spread the word to a less technical audience, blog about the issue, provide examples of designs with-and-without, and generally whip up enthusiasm for this. Bonus points if you can get it covered in the technical press.

Finally, maybe even use a browser-detecting script to give Chrome users of your sites a notice that says "Sounds crazy, but this site looks better in Safari or Edge. Click here to find out why" etc.

And to any Chromium people reading this who can shed any light on what the hold-up is: please post your insights here - or nudge someone who can. Ultimately we're all on the same side just trying to make the product better, but it's really hard when you're not communicating with us.
Starred.  Been watching this property for over a year.  Personally I really want gaussian blur on the backdrop to do iOS-style blurred translucency.  But for now I am stuck not using such an effect since there really exists no suitable fallback effect for Chrome.  Does anyone know what's blocking the feature from coming out from behind the flag?
Currently on the one hand Edge and Safari do have better support than Chrome ones and do not require any flag to be enabled to use it. On the other hand, it also requires Webkit prefix in order to work on these browsers (Edge and Safari)
Let's bring backdrop-filter to chrome!
Hi all,

Thanks for all of your enthusiasm. While we can't promise when
the feature will be added, I wanted to let you know that we did hear your comments.
We're going to try to make progress on this feature in the next few months.
@chrishtr@chromium.org Thanks a lot for the update, much appreciated, and good luck. Can't help with coding, but if I can contribute in other ways (describing use cases, testing alphas/betas), I'd happily chime in. I'm sure there's lots of willingness from the community to help with this one.
Showing comments 36 - 135 of 135 Older

Sign in to add a comment