Implement backdrop-filter from Filter Effects Module Level 2

NEW
Unassigned

Status

()

P3
normal
4 years ago
11 days ago

People

(Reporter: jonnyscholes, Unassigned)

Tracking

(Blocks: 2 bugs, 6 keywords)

Trunk
dev-doc-needed, DevAdvocacy, feature, parity-chrome, parity-edge, parity-safari
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted], [DevRel:P2] , URL)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150622004006

Steps to reproduce:

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

Did this work before? No 

Does this work in other browsers? Nothing stable. It's slated for support in the Safari that drops in OSX 10.11

Corresponding Chromium issue: https://code.google.com/p/chromium/issues/detail?id=497522


Actual results:

The backdrop-filter property isn't supported, so nothing.


Expected results:

The box has a background of a blurred version of its backdrop.
Keywords: dev-doc-needed
Component: Untriaged → Graphics
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Version: 40 Branch → Trunk

Updated

4 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Backdrop filters are now supported in the latest webkit nightly

https://www.webkit.org/blog/3632/introducing-backdrop-filters/

Comment 2

4 years ago
(In reply to Mahdi Dibaiee [:mahdi][:mdibaiee] from comment #1)
> Backdrop filters are now supported in the latest webkit nightly
> 
> https://www.webkit.org/blog/3632/introducing-backdrop-filters/
… prefixed with -webkit-

Are we going to reintroduce the -moz- prefix here or stick with putting it behind a pref.

Updated

4 years ago
Flags: needinfo?(mdibaiee)
I'm not in a position to make a decision about this, maybe someone who is more relevant can answer.
Flags: needinfo?(mdibaiee)

Comment 4

4 years ago
Spec heroes & implementers: Would you mind reading over the spec and assessing if it is ready for implementation? If not, can you please provide input to the authors so this can move forward? 

I expect this to be the "next big thing" among Web Designers 'cause The Fruit is doin' it …

Comment 5

4 years ago
I'm neither a hero nor an implementer, but there doesn't seem to be much in the spec that could change.

Comment 6

3 years ago
I can't wait for this. This is one of the last things remaining (besides shader support (will that ever exist?)) to be able to make DOM-based apps that can compare with native. backdrop-filters coupled with 3D transforms will open many doors for creativity...
Comment hidden (offtopic)
Comment hidden (offtopic)
Comment hidden (offtopic)
Comment hidden (offtopic)
Comment hidden (offtopic)
Comment hidden (offtopic)

Comment 16

3 years ago
backdrop-filter is more practical than filter.
Keywords: feature
Whiteboard: [gfx-noted]
Priority: -- → P3
Keywords: DevAdvocacy
Whiteboard: [gfx-noted] → [gfx-noted], [DevRel:P3]
Whiteboard: [gfx-noted], [DevRel:P3] → [gfx-noted], [DevRel:P2]
My understanding is that this is the same feature that's been in SVG filters for ages, but that we've never implemented (bug 437554).
Blocks: 913153

Comment 19

2 years ago
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.

Comment 20

2 years ago
notechnicalvalue
Why does it take browsers so long to implement great things?

Mozilla, do you need more engineers? There seem to be plenty around here in the Bay Area...
Our pace implementing new CSS slowed over the last year because tremendous engineering effort was directed at making Firefox much faster. You can read all about it here: https://www.cnet.com/special-reports/mozilla-firefox-fights-back-against-google-chrome/

We are almost done with a great deal of that effort, and will soon be focusing people on implementing on new stuff rather than improving the old. Look for many more CSS properties shipping in 2018.

And thanks for chiming in about what you want to see most. It does help in making sure important CSS properties are not overlooked.

Comment 22

2 years ago
That's really awesome, I'm looking forward to 57!

Comment 23

a year ago
Not trying to appear to be rushing things, but I'd really like to see this in Firefox now that 57 is shipped to stable! Maybe Q1 2018 :)
If this helps, Edge implements and enables backdrop-filter in its latest Insider version:
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/9160189-backdrop-filters

Safari does it for long time and Chrome under a flag.

Please, Firefox team, make it real.
Alias: css-filter-effects-2
Blocks: 1323667
Summary: Implement backdrop-filter from Filter Effects Module Level 2 → [META] Implement CSS Filter Effects Module Level 2
Whiteboard: [gfx-noted], [DevRel:P2] → [gfx-noted], [DevRel:P2] [parity-edge][parity-blink]
Comment hidden (advocacy)

Comment 26

11 months ago
https://caniuse.com/#feat=css-backdrop-filter

Seems to be implemented in the next Edge, Chrome has it behind a flag and webkit has it behind a perfix.
Other vendors are waiting for the real leader of the web to push this feature :-)
As this was turned into a meta-bug for Filter Effects Level 2, should we create a separate issue for 'backdrop-filter' blocking this one?

Sebastian
Flags: needinfo?(tantek)
Comment hidden (advocacy)

Comment 29

11 months ago
(In reply to Sebastian Zartner [:sebo] from comment #27)
> As this was turned into a meta-bug for Filter Effects Level 2, should we
> create a separate issue for 'backdrop-filter' blocking this one?

Thanks for the heads-up Sebastian. I have reverted the meta-morphosis (since this bug already has plenty of history for 'backdrop-filter' and am filing a new meta bug for Filter Effects Level 2. Stand by.
Alias: css-filter-effects-2
Summary: [META] Implement CSS Filter Effects Module Level 2 → Implement backdrop-filter from Filter Effects Module Level 2

Updated

11 months ago
Blocks: 1456594

Updated

11 months ago
No longer blocks: 1323667
Flags: needinfo?(tantek)

Comment 30

11 months ago
(In reply to Tantek Çelik from comment #29)
> (In reply to Sebastian Zartner [:sebo] from comment #27)
> > As this was turned into a meta-bug for Filter Effects Level 2, should we
> > create a separate issue for `backdrop-filter` blocking this one?
> 
> Thanks for the heads-up Sebastian. I have reverted the meta-morphosis (since
> this bug already has plenty of history for `backdrop-filter` and am filing a
> new meta bug for Filter Effects Level 2. Stand by.

It’s also pointed to by the Firefox Platform Status website¹ as the bug for CSS `backdrop-filter`.

Also, if we do implement this, then we should consider adding the `-webkit-backdrop-filter` prefix for webcompat since Safari currently implemets behind the `-webkit-` prefix², although Edge and Chrome aren’t currently implementing the `-webkit-` prefix, so I don’t really know if it’s really gonna be necessary.

¹ https://platform-status.mozilla.org/#css-backdrop-filter
² https://developer.mozilla.org/docs/Web/CSS/backdrop-filter#Browser_compatibility

Comment 31

11 months ago
(In reply to ExE Boss from comment #30)
> 
> Also, if we do implement this, then we should consider adding the
> `-webkit-backdrop-filter` prefix for webcompat since Safari currently
> implemets behind the `-webkit-` prefix², although Edge and Chrome aren’t
> currently implementing the `-webkit-` prefix, so I don’t really know if it’s
> really gonna be necessary.

By default we should avoid (rather than should consider) implementing any -webkit- prefix properties.

Only when there is documented compat data that makes a case for it, should we bother with implementing.

Mike, is -webkit-backdrop-filter anywhere on the compat radar?
Flags: needinfo?(miket)
From the graphics team side, there are two major blockers that are currently preventing this from being implemented in Firefox:
 - The graphics team is busy implementing WebRender and does not have the capacity to implement other graphics features at the moment.
 - The specification is imprecise in a crucial aspect and requires clarification. This is tracked in https://github.com/w3c/fxtf-drafts/issues/53 .

Once the spec has been changed or clarified, we do not have objections to having this in Firefox.

Comment 33

11 months ago
I think this should be WONTFIX, since the backdrop-filter spec has been replaced by the `filter()` function: https://www.w3.org/TR/filter-effects/#FilterCSSImageValue
No it hasn't. The filter function has existed in a spec for longer than backdrop-filter, and it only filters the image you supply inside the background-image, whereas backdrop-filter filters "everything behind the element".
(In reply to Tantek Çelik from comment #31)
> Only when there is documented compat data that makes a case for it, should
> we bother with implementing.
> 
> Mike, is -webkit-backdrop-filter anywhere on the compat radar?

This hasn't come up for us yet, to my knowledge.
Flags: needinfo?(miket)
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-edge
Whiteboard: [gfx-noted], [DevRel:P2] [parity-edge][parity-blink] → [gfx-noted], [DevRel:P2]

Comment 39

10 months ago
(In reply to Tantek Çelik from comment #31)
> (In reply to ExE Boss from comment #30)
> > 
> > Also, if we do implement this, then we should consider adding the
> > `-webkit-backdrop-filter` prefix for webcompat since Safari currently
> > implemets behind the `-webkit-` prefix², although Edge and Chrome aren’t
> > currently implementing the `-webkit-` prefix, so I don’t really know if it’s
> > really gonna be necessary.
> 
> By default we should avoid (rather than should consider) implementing any
> -webkit- prefix properties.
> 
> Only when there is documented compat data that makes a case for it, should
> we bother with implementing.
> 
> Mike, is -webkit-backdrop-filter anywhere on the compat radar?

If I'm not mistaken, Edge currently requires the `-webkit` prefix on `backdrop-filter`, otherwise it doesn't render the blur. Not sure if/when they'll drop the prefix. Would love it if FF came in without the need for a prefix.

Comment 40

10 months ago
Why is the status of Safari "Developing" Safari release this years ago
(In reply to bh from comment #40)
> Why is the status of Safari "Developing" Safari release this years ago

Obviously, the page isn't up-to-date. You can provide a patch for it at https://github.com/mozilla/platform-status/.

Sebastian
Comment hidden (advocacy)

Comment 43

10 months ago
Will this https://www.bleepingcomputer.com/news/security/css-is-so-overpowered-it-can-deanonymize-facebook-users/ affect speed of implementation? Is there even a way to provide the filter without the security loophole?

Comment 44

9 months ago
(In reply to heyjoeday from comment #39)
> If I'm not mistaken, Edge currently requires the `-webkit` prefix on
> `backdrop-filter`, otherwise it doesn't render the blur. Not sure if/when
> they'll drop the prefix. Would love it if FF came in without the need for a
> prefix.

I don't think a prefix is needed either. I'm pretty sure Edge will drop it in the future. Also, apple.com (the menu bar) uses both prefixed and unprefixed in their CSS code, suggesting this is how they intended it to be used.

Comment 45

6 months ago
Chrome is now working on that feature. https://bugs.chromium.org/p/chromium/issues/detail?id=497522#c134

Three months ago:
> 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.

Three weeks ago:
> We may restart work on this feature soon, please stay tuned. The next step is to fix an error in the specification.

Today it was assigned to someone.

Comment 46

5 months ago
Safari and Edge both support this.
Keywords: parity-safari
Comment hidden (me-too)
Comment hidden (me-too)
Comment hidden (advocacy)

For all that are hoping that this feature gets implemented soon (like me), backdrop-filter is listed in the priorities for 2019, see https://wiki.mozilla.org/CSS#Filter_Effects_Level_2.

Sebastian

You need to log in before you can comment on or make changes to this bug.