Bug 162760 – [css-filters-2] Parent stacking context of backdrop-filter needs to isolate itself

• Component: CSS
• Status: RESOLVED WONTFIX

[Tien-Ren Chen]

Similar to bug 129154, backdrop-filter should only take inputs from the innermost enclosing stacking context, as spec'd in:

https://drafts.fxtf.org/filters-2/#BackdropFilterProperty

"""The first filter function or filter reference in the list takes the element’s BackgroundImage as the input image. Subsequent operations take the output from the previous filter function or filter reference as the input image. filter element reference functions can specify an alternate input, but still uses the previous output as its SourceGraphic."""

https://drafts.fxtf.org/filters/#valdef-in-backgroundimage

"""BackgroundImage
This keyword represents the back drop defined by the current isolation group behind the filter region at the time that the filter element was invoked. See isolation property [COMPOSITING-1]."""

Chromium's fix along with a layout test can be found here: https://codereview.chromium.org/2375203003/

[Dean Jackson]

Unfortunately that's not what we want, and it was my mistake when I wrote the specification.

The backdrop should not be the BackgroundImage as defined in the filters spec. It should be the entire rendering of the page up to the point of the filtered element.

[Dean Jackson]

I filed https://github.com/w3c/fxtf-drafts/issues/53

[Tien-Ren Chen]

But that would be undefined if the backdrop-filter element is inside of an open group effect. I saw a proposal somewhere that in such case we treat parent effects to be no-op and replace special blending with src-over when we draw the backdrop.

So for example:

A + opacity(B + C) * opacity(D + E + Backdrop + F + G)

Where '+' denotes src-over and '*' denotes some special blending. The backdrop will be resolved as:

A + opacity(B + C) + D + E

Is that what we intended to implement and make into the spec?