Intent to Implement and Ship: Backdrop Filter

[Mason Freed]

Contact emails

mason...@chromium.org, chri...@chromium.org

Explainer / Design Doc

Located here.

Spec

Located here.

Tag Review

Requested here.

Original Intent to Implement (from 2015)

Located here.

Summary

Backdrop-filter is a proposed CSS property that applies one or more filters to the "backdrop" of an element. The "backdrop" basically means all of the painted content that lies behind the element. This allows designers to construct "frosted glass" dialog boxes, video overlays, translucent navigation headers, and more.

Motivation

Ever since Webkit shipped a prefixed version of this feature in 2015, developers have been asking for Chromium to implement it. The main Chromium feature tracking bug has 531 stars as of March 12, 2019. A number of web design blogs highlight this "cool" feature, and bemoan the lack of Chromium support. It is clear from the comments on the bug, and in the general discussions around the web, that this feature is highly desired by designers. We should make it available to them.

Risks

Interoperability and Compatibility

This feature only affects the appearance of the page, and not the behavior, so interop concerns are limited to visual effects. Webkit has had a shipping prefixed version of backdrop-filter since 2015. Edge has had a shipping non-prefixed backdrop-filter implementation since 2018. Mozilla has not implemented this feature. Neither of the shipping implementations adhere to the spec: they filter everything behind the element, rather than stopping at the Backdrop Root. (See the Motivation section of the spec for much more detail on this issue.) However, the expectation is that there will be very little difference in appearance among the implementations, for most typical use patterns. Given that Edge is moving to Chromium, and Webkit’s implementation is prefixed, the interop risk here is quite small.

Edge: Shipped

Firefox: Public support

Safari: Shipped, Prefixed

Web / Framework developers: All positive, e.g.:

• https://ferdychristant.com/please-help-make-backdrop-filter-a-reality-f81805ba3d52

• https://css-tricks.com/the-backdrop-filter-css-property

• https://webdesign.tutsplus.com/tutorials/css-backdrop-filters--cms-27314

• https://www.reddit.com/r/webdev/comments/3zgpnb/we_figured_out_a_way_to_recreate_the_blurred

• https://stackoverflow.com/questions/38145368/css-workaround-to-backdrop-filter

• https://www.sitepoint.com/create-stunning-image-effects-with-css-backdrop-filter

• Comments on the Chromium bug: https://crbug.com/497522

Ergonomics

The backdrop-filter feature is computationally intensive, as are filters in general, so it may impact the performance of sites that use it. However, this should be comparable to existing filter usage, and should be manageable.

Activation

There is no known way to polyfill this feature, unfortunately. Once shipped in Chrome, it will have support from 3 of 4 implementations, so it should be relatively easy to use immediately.

Debuggability

This CSS property is supported in DevTools currently.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Yes. All tests starting with backdrop-filter-* here.

Link to entry on the feature dashboard

Yes, here.

Requesting approval to ship?

Yes.

[Daniel Bratell]

Cool!

The Tag Review was filed just the other day so we should wait for them to look at it. Have you done the necessary (*insert slightly undefined action*) to get the review expedited?

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjagt%3Ds4kWw41onfHK2j7YSH1hHpzJej51DAmmELaiRuw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Alex Russell]

LGTM

[Philip Jägenstedt]

LGTM2, 531 stars is an impressive amount, thanks for prioritizing this!

Looking at https://wpt.fyi/results/css/filter-effects/ I wonder if the existing test suite is good enough, since the passes and fails don't line up with what the implementation status seems to be. When implementing this, can you also vet the test suite and improve it where necessary?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/187610d7-0694-4120-8978-377702b7b4af%40chromium.org.

[Mason Freed]

Cool!

The Tag Review was filed just the other day so we should wait for them to look at it. Have you done the necessary (*insert slightly undefined action*) to get the review expedited?

/Daniel

 

Thanks! I didn't do anything to expedite the review. Is the "non-expedited" lead time particularly slow (or infinite)?

[Mason Freed]

LGTM2, 531 stars is an impressive amount, thanks for prioritizing this!

Looking at https://wpt.fyi/results/css/filter-effects/ I wonder if the existing test suite is good enough, since the passes and fails don't line up with what the implementation status seems to be. When implementing this, can you also vet the test suite and improve it where necessary?

Thanks! I need to dig into that dashboard, that's the first time I've seen it. I wrote most of those tests, and while I'm still working through the implementation to fix some of them, our local pass rate is higher than the dashboard shows. Is there a way to see the actual pixel output on there? Anyway, thanks for pointing it out, I'll dig in and figure it out. And I'll definitely try to make sure the WPT suite covers the feature. One note: until WPT tests can support "fuzzy" passes, I will need to keep some non-WPT layout tests for this feature. For example, I cannot make a WPT test for rounded corner clipping.

[Daniel Bratell]

Yes, it's known that tag reviews can take a while which is why we recommend filing one early. I don't know exactly how to tell that a certain review is more time constrained than others, but Alex Russell or Alice Boxhall should know (+CC).

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhr%3DSwiuyOzqWYa4tRwVSWzq%2BBNhneyQHprqiQip4D5Ww%40mail.gmail.com.

[Yoav Weiss]

On Tue, Mar 12, 2019 at 8:11 PM 'Mason Freed' via blink-dev <blin...@chromium.org> wrote:

Contact emails

mason...@chromium.org, chri...@chromium.org

Explainer / Design Doc

Located here.

Spec

Located here.

That doesn't seem like an official specification link. Is this based on a PR that hasn't landed yet? Can you point to the PR itself?

It would make it easier for me to evaluate how much of a spec change this represents vs. what's currently shipped in other browsers.

 

[Mason Freed]

You're right - the PR is here. It looks like I have one more round of comments to address there.

[Philip Jägenstedt]

I didn't follow the spec link before LGTM2, but still LGTM on the assumption that the changes are merged before the flag is flipped in Chromium.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgjqKSogEz7%3DReajDEbD4x0VuSWbMJtYBLTPA5x7txpog%40mail.gmail.com.

[Chris Harrelson]

FYI: The changes were merged just now.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfrHVnJ%2BSe9Oir1Ly6xQDY0M5Y_B5SRoRBYXVhZOg9bRg%40mail.gmail.com.

[Mason Freed]

Thanks Chris. The spec is now located here: https://drafts.fxtf.org/filter-effects-2/

[Yoav Weiss]

Thank you! Reading through the minutes on the issue, I see that it was decided to land this change to the specification, but to include a note saying that this is still under discussion.

If the currently specified behavior shipped, and then it required changes due to further discussions, my understanding is that such changes may result in visual breakage in some cases. Is that correct?

If it is, how confident are we that these changes will stick? Is the "under discussion" label somehow timeboxed?

[Mason Freed]

Thanks for the questions, Yoav.

Yes, that's correct - we added a note to indicate that the behavior is still under discussion. There is fairly strong support for our proposal from both Microsoft and Mozilla. However, Webkit still feels that the backdrop-filter should filter *everything* behind the element, all the way to the root. As you know from reading the spec, there is a fairly detailed motivation section that lays out some technical problems with that behavior. Webkit would like time to rebut that discussion - hence the note. Given the strength of our opinion that the technical problems with Webkit's proposal are real and difficult to solve, and given the support of 3 of 4 implementations, I would say the chances are high that this will "stick". There is no timebox on the discussion - it is waiting for Webkit's rebuttal.

If we ship Chromium with the newly-specified behavior, and then later change to adopt the position being championed by Webkit, there could definitely be visual differences. However, in our survey of current/typical uses of the feature, there would not be a visual breakage. We were unable to find any existing uses of this feature that nested the backdrop-filtered element inside an element with filters or opacity. So our perception is that the risk here is quite low.

[Yoav Weiss]

On Fri, Mar 22, 2019 at 11:58 PM Mason Freed <mason...@google.com> wrote:

Thanks for the questions, Yoav.

Yes, that's correct - we added a note to indicate that the behavior is still under discussion. There is fairly strong support for our proposal from both Microsoft and Mozilla. However, Webkit still feels that the backdrop-filter should filter *everything* behind the element, all the way to the root. As you know from reading the spec, there is a fairly detailed motivation section that lays out some technical problems with that behavior. Webkit would like time to rebut that discussion - hence the note. Given the strength of our opinion that the technical problems with Webkit's proposal are real and difficult to solve, and given the support of 3 of 4 implementations, I would say the chances are high that this will "stick". There is no timebox on the discussion - it is waiting for Webkit's rebuttal.

If we ship Chromium with the newly-specified behavior, and then later change to adopt the position being championed by Webkit, there could definitely be visual differences. However, in our survey of current/typical uses of the feature, there would not be a visual breakage. We were unable to find any existing uses of this feature that nested the backdrop-filtered element inside an element with filters or opacity. So our perception is that the risk here is quite low.

Thank you for clarifying.

Given that:

* The rebuttal is not timeboxed

* From the minutes, CSS-knowledgeable TAG folks have already taken part of those discussions, even if under different hats

* If we would like to change course in the future, we would be able to without wide-spread visual breakage

LGTM3

[Mason Freed]

Thanks!

[in...@digitaldesksolutions.com]

Not sure where to put this, but I'm on version 73.0.3683.86 (Official Build) (64-bit). Backdrop filter worked fine until I updated and now I get:

I'm on Windows 8.1, and I have 2 monitors, one is 4k and the other 1080p. When the window is on the 1080p mon it's fine, but on the 4k mon, I get the above result.

To be clear: it broke with the update.

[Chris Harrelson]

Please file a bug at crbug.com/new with instructions on how to reproduce this issue.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bf06067a-7f60-49ad-ac39-6e9c80c98d82%40chromium.org.

[mason...@google.com]

Thanks. This is almost surely the same as https://crbug.com/944388. So unless you disagree, there is no need to file another bug for this one.

Thanks,

Mason

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.