[filter-effects-2] Backdrop filters should not use BackgroundImage

[grorg]

Currently, the spec says "The first filter function or filter reference in the list takes the element's BackgroundImage as the input image."

This was a mistake on my part. BackgroundImage is defined as the backdrop up to the isolation parent.

What we really want is a new term, BackdropImage, which is the backdrop of the element, including all parents and siblings that have been painted up to the point of the filter. There is no isolation.

[AmeliaBR]

Is there going to be a BackdropAlpha or any other way to interpret the backdrop? If not, I think "backdrop" is both shorter and less likely to be confused with CSS background images.

But while we're on the subject:

Why no isolation? How would this interact with mix-blend-modes in general?

What do you mean "parents and sibling that have been painted"? Is that, after proper re-ordering for z-index, or only previous DOM siblings?

How do you determine which section of the backdrop is affected by the filter? Is it clipped to the current element's content/border/margin-box? Is it masked by the current element's painted alpha channel?

[grorg]

Many great questions!

Why no isolation? How would this interact with mix-blend-modes in general?

It's not that it isn't isolated, just that the backdrop isn't clamped at the isolation root.

The mix-blend-mode affects how this element is then composited. So it is effectively rendered offscreen and then blended. Backdrop filters won't change that.

What do you mean "parents and sibling that have been painted"? Is that, after proper re-ordering for z-index, or only previous DOM siblings?

I meant in paint order, not DOM order. I just couldn't think of an existing term for that.

The way backdrop filter works is that you do a separate rendering pass just for the backdrop. This is why it is expensive.

How do you determine which section of the backdrop is affected by the filter? Is it clipped to the current element's content/border/margin-box? Is it masked by the current element's painted alpha channel?

At the moment it is the border box. It isn't masked by the element's painted alpha. Maybe we'll need an option to do that for SVG elements.

[mstange]

Can you say more about why you chose to make backdrop filter not respect isolation? I had always assumed they respected isolation (i.e. just operated on the implied intermediate surface of the nearest stacking context, the way blend modes do), and was quite surprised when I played with them in Safari a few weeks ago and found out that this was not the case. I also noticed very inconsistent behavior, see below. Do you have scenarios in mind where respecting isolation would impose unnecessary limitations on what authors could do?

If you're inside a stacking context and render a backdrop filter, does the separate rendering pass include the contents of the current stacking context up to the current element? This testcase shows rather contradictory behavior in Safari:

<div style="height: 200px; opacity: 0.5; background: black;">
  <div style="height: 100px; -webkit-backdrop-filter: opacity(1);"></div>
</div>

On initial load, I just get a 200px high gray box (i.e. white + 50% black). If I then use the Web Inspector to change opacity(1) to opacity(0) and back to opacity(1), suddenly the upper half of the box becomes white. What's the intended behavior here?

[mstange]

I've filed the problem from the previous comment as https://bugs.webkit.org/show_bug.cgi?id=164606.

[mstange]

@grorg This issue definitely needs clarification before we can agree to implementing backdrop-filter in Firefox.

In particular, it needs to be clear how the testcase in #53 (comment) should behave.

There are strong parallels to mix-blend-mode here: If you have an element with mix-blend-mode, blending needs to happen between that element's contents and the element's backdrop. We have an existing definition for what exactly the mix-blend-mode backdrop is, and that definition respects isolation. If backdrop-filter ends up using a different definition for what the backdrop is, there should be a good justification for the difference.

[AmeliaBR]

I created a test case. For what it's worth, the Chrome implementation respects isolation. (On the other hand, the Chrome implementation *doesn't respect border-radius, which is another thing not well defined in the spec.)

Screenshots (the element with the green border has isolation, the circles on the left are using an invert backdrop filter; the circles on the right are using a difference blend mode):

Chrome 65:

Safari 11:

[AmeliaBR]

One of the weird side effects of Safari's implementation (and the original reason I built the test) is how a an element with blend mode can "escape" isolation by blending in with a sibling that has a backdrop filter: that overlap section is created from the blend mode inverting the colors on its sibling, which include the inverted colors from the body background.

[dirkschulze]

@AmeliaBR @mstange From looking at the example, nothing escapes isolation as far as I can see.

1. Backdrop filter takes the entire content of the backdrop.
2. Everything drawn up to the backdrop filter respects the isolation property.
3. The white circle is drawn on top of the element that is drawn with the backdrop filter (and the actual backdrop)
4. Difference filter is still isolated to the common group of the element with the backdrop filter and the white circle with difference.

I understand that it sounds strange but isolation rules are still met for blending. The one is independent of the other.

As @grorg says, we need a new term to describe this behavior.

• BackgroundImage and BackgroundAlpha stop at isolation. Nothing before the isolation gets used.
• Backdrop wouldn't stop at isolation but the rest of the drawing (filter, mix-blend-mode) would still respect isolation.

It would be interesting to see if Safari runs into issues where it normally would create a compositing layer. So if the group would have an animation of the transform property for instance. Or a 3D transform gets applied. This usually complicates things for implementations. I would be impressed if both still work. If not, we probably need separate definitions of isolation.

[dirkschulze]

See discussion in previous comment. Ran 2 different tests:

• One with 2D transform animation
• One with 3D transform animation and perspective.

2D tranform animation

https://codepen.io/krit/pen/XqXvyo

• Once an animation with a transform gets specified and starts, the group starts getting isolated. So the 2nd circle in the first example gets white on hover.
• backdrop-filter continues to get the content from the backdrop.

This actually makes sense. Even when split into compositing layers, the implementation still has access to the different "raster images"/compositing layers and can composite those for the backdrop blur filter. At least when you implement backdrop-blur in the paint pipeline you have.

3D transform animation with perspective

https://codepen.io/krit/pen/zjrgmy
Then I modified the example with a perspective property and a rotateX (I always struggle to make things look 3D but it works for this test 😆 ).

• On hover, the backdrop-filter stops working. This is expected since we no longer have two 2D planes that simply needs to get composited.

Conclusion

The question is:

• Do we make backdrop-filter stop at isolation as filter and mix-blend-mode do or
• do we define a new isolation term based on the existence of perspective?

And extended question:

• If we go with the new isolation term, can we have it for BackgroundImage too?

[AmeliaBR]

BTW, Edge 17 supports backdrop-filter (but still no blend modes!!!). They follow Chrome in using a square box, unaffected by border-radius, but follow Safari in not respecting isolation (which is probably related to not supporting blend modes).

[Benimation]

Why not just do it the same way Safari/WebKit did it? It works the best visually and it was their initial idea..

[mfreed7]

@grorg, this definitely needs a few clarifications before we can get it shipped in Chrome. The main sticking point is whether backdrop-filter respects isolation. Our reading of the spec agrees with your interpretation - it states that the filter takes the BackgroundImage as its input, and that is defined (here)
to be the contents of the current isolation group up to the current element. For several reasons, we like that definition:

• Making backdrop-filter respect isolation boundaries would make it behave in exactly the same way that other filter effects do, including mix-blend-mode and filter (with in=’BackgroundImage’). This should reduce developer confusion, as compared to introducing another brand-new concept specifically for use with backdrop-filter.

• If backdrop-filter is re-defined to filter everything behind the element, including items outside the parent stacking context, the implementation gets much more technically involved. Two complete rendering passes need to be performed, one to build the image “behind” the element as input to the filter, and the other to actually render it all together. This additional complexity can lead to more bugs and performance degradation.

We believe that having backdrop-filter respect isolation boundaries will not pose a practical limitation to developers, assuming they understand the behavior correctly. For example, if they nest the popup window (with backdrop-filter) directly within the <html> node, it will filter everything painted before it. The only real issue would be deeply-nested elements with backdrop-filters.

In addition to the isolation question, as @AmeliaBR pointed out, several other things are unclear at the moment. In particular, the spec does not describe which portion of the backdrop is affected by the filter. This needs to be defined, both in terms of border (content/border/margin) and whether the current element’s painted alpha masks the filter. It seems to us like it should be clipped to the border (respecting border radius), but painted alpha shouldn’t mask the effect. This is the most straightforward, both to understand and to implement.

[mfreed7]

Another issue with defining backdrop-filter to read back everything (not respecting isolation) is that there are some situations where the behavior is ambiguous or at least not easily anticipated. For example, if an element (call it “A”) has 0.5 opacity (creating a stacking context), and a child of that element (call it “B”) has a backdrop-filter applied, the 0.5 opacity will potentially be “applied twice” if the isolation is not respected. First, during the read back of “everything before” the backdrop-filter on B, the 0.5 opacity will be applied to A to blend it with its backdrop (call that “R” for root). The resulting backdrop-filtered image will then be used as the starting canvas for element B. Once B is painted, this entire stacking context (containing A, the backdrop-filtered image, and B) will be composited into R using the 0.5 opacity for the group. So the portion of A under B will effectively have opacity 0.25.

Please see this example for this effect possibly happening, in Box 3. I’ve included screenshots from Chrome, Safari, and Edge below. In Chrome, all three boxes seem to have the right amount of blur and opacity applied. (Don’t worry, there are plenty of other bugs in Chrome’s backdrop-filter, just not here.) In Safari, Box 3 looks like it is at 0.25 opacity - double-counted. And incidentally, Box 1 also shows another bug (I believe) in Safari. It has a background color, which seems to turn off the backdrop-filter entirely. On Edge, I’m not sure what is happening. The edges of the red box are crisp all the way around, so perhaps the red background is being repainted on top of the blur? Or maybe some form of opacity double-counting here too?

Just to make the point again - having backdrop-filter respect isolation should lead to fewer bugs, and a less confusing experience for developers.

Chrome 69:

Safari 12:

Edge 42:

[Benimation]

I think it's most important that this will work the same way it does in Safari. In my opinion, it would be more confusing for developers if it didn't work the same everywhere. Do note that the same effect is present in iOS, where it does work similarly to the way it works in Safari (if not exactly the same way).

I really do think that the backdrop should include everything behind an element, as it's supposed to be a filter that can be put on top of anything (and filter anything behind it). If it doesn't work this way, it won't look good in countless situations.

[mfreed7]

@Benimation, I definitely agree that we need to clarify the standard and then make sure the behavior is the same on all browsers.

Can you give an example of the effect "not looking good" with backdrop filter stopping at the parent stacking context? It would be helpful to see what the limitations would actually be.

[css-meeting-bot]

The CSS Working Group just discussed backdrop-filter.

The full IRC log of that discussion

<gregwhitworth> Topic: backdrop-filter
<Rossen> github: https://github.com//issues/53
<gregwhitworth> chrishtr: for reasons of implementation complexity, number 1 and avoiding situations developers would find confusing
<gregwhitworth> chrishtr: I want backdrop-filter to only apply to containing isolated group, which in spec terms is the background image of the group
<gregwhitworth> chrishtr: takes the group - applies filter and then clips and paint behind it and then paint on top
<gregwhitworth> chrishtr: issue 53, was originally filed to change the spec to not image but all the images from the root
<gregwhitworth> chrishtr: the prefixed impl that Safari has that draws everything up to the root - and unprefixed version in Edge also has that
<gregwhitworth> chrishtr: the reason I prefer it to the isolated group is because it's easier to implement and more performant
<gregwhitworth> chrishtr: whereas if you draw all the way up to the root we'll need to implement a new algo
<gregwhitworth> chrishtr: if you go to an isolated group that is above the containing isolated group you may have to take into account other graphical effects into account with filters that move pixels, etc
<gregwhitworth> chrishtr: this inreases complexity a lot
<gregwhitworth> chrishtr: this makes it complicated for developers - there are a few scenarios in the issue
<gregwhitworth> chrishtr: there's an element with backdrop-filter, somewhere in the ancestor an alement has opacity but it isn't in the isolated group but that opacity must be included - so you're getting doulbe opacity
<gregwhitworth> krit: I have to agree that opacity is indeed strange, did you do testing on Edge/Safari
<gregwhitworth> chrishtr: yes, there are screenshots in the issue and they do double opacity
<gregwhitworth> krit: I think there is developer desire to do it on the entire section, not just the isolated group
<gregwhitworth> mstange: can you mention a case that would be impossible?
<gregwhitworth> krit: when you do an animation that has a filter on it
<gregwhitworth> krit: there wouldn't be any backdrop filter on it since it's animating
<gregwhitworth> mstange: that sounds like an animation issue
<gregwhitworth> mstange: that sounds like an ordering issue
<gregwhitworth> mstange: I agree with chrishtr that it would be easier to implement and be more predictable for authors
<gregwhitworth> krit: how does it work more consisted with mix-blend-modes?
<gregwhitworth> krit: you have two divs on top of each other, the second would be an isolation group - you would blend them together
<gregwhitworth> chrishtr: mix blend mode and isolation groups are not always the same
<gregwhitworth> s/chrishtr/mstange
<krit> https://codepen.io/krit/pen/pxOMdz
<gregwhitworth> mstange: I'm interested in seeing scenarios in which I'm wrong
<gregwhitworth> krit: or maybe I'm missing some
<gregwhitworth> ... looking at codepen
<gregwhitworth> Simon: as I understand anything that creates a stacking context creates an isolation group
<gregwhitworth> Simon that is contrary to the point of backdrop-filter which should apply to everything behind you
<gregwhitworth> chrishtr: yeah
<gregwhitworth> chrishtr: I think this needs more discussion offline
<gregwhitworth> Rossen: ok, thank you chrishtr
<krit> mstange: https://dbaron.org/log/20130306-compositing-blending

[chrishtr]

Note that the codepen posted by @dirkschulze has a typo in it (isolation: isolated instead of isolation: isolate).

If that is fixed then the codepen shows that indeed mix-blend-mode only mixes with the containing isolated group, not all the way to the root.

So the semantics of backdrop-filter that @mfreed7 is proposing are consistent with mix-blend-mode.

[mfreed7]

I just wanted to quickly add a comment about the limitations of stopping backdrop-filter at an isolation boundary. It seems like there may be some misconception about how that limits what gets filtered. Please see this jsbin, which shows a dialog element floating over the top of (and filtering) all other elements on the page. The dialog is first in the DOM hierarchy, and the other elements include several nested stacking contexts. The point is that the stacking context limitation only applies if the backdrop-filtered element itself is nested inside a stacking context for some reason. As long as it sits outside, everything behind it on the page, including other stacking contexts, gets filtered. See also, https://www.apple.com - they use exactly this DOM structure for the nav bar at the top. I'd be very interested to see examples where the backdrop filtered element needs to be inside a stacking context for some reason - i.e. what type of effect isn't possible with the proposed isolation behavior?

[mfreed7]

To see how people are using backdrop-filter today, I did some research using HTTP Archive and Chrome Platform Stats. The current usage rate for backdrop-filter (unprefixed) is very low, about 0.0003%. That number does not include prefixed (-webkit-backdrop-filter) usage, so I used HTTP Archive to pull all pages that use backdrop-filter. Of those, about half use only the prefixed version, so the actual usage rate might be higher by 2-5X, which is still quite small. Another analysis based on summed Alexa ranks for each page results in a factor of about 3x. In all cases, the existing usage is quite small.

I also looked at the pages themselves that currently make use of backdrop-filter. I was only able to locate two high-ranking sites that have a visible element styled with backdrop-filter. One is Apple, and the other is the Github Blog. Both use nearly the same DOM structure, as I mentioned above: an element nested directly within the <body> with a high z-index value. And as I mentioned, this works perfectly well with our proposal to have backdrop-filter respect isolation boundaries.

We are still curious what effects would be difficult to achieve, if backdrop-filter were specified to respect isolation boundaries. Input appreciated!

[mstange]

I took a closer look at the example from #53 (comment) and found a potential problem with making backdrop-filter respect isolation. Here's a variation of the example with the following changes: The opacity on the ancestor element .colorbox was removed, and the opacity on .box1 and .box3 was reduced to 0.1. This variation of the example no longer demonstrates what happens when an ancestor item is isolated, but it demonstrates what happens when opacity and backdrop-filter are applied to the same element. Here's how Chrome and Safari render it:

Chrome 72 Canary:

Safari 12:

In Chrome, it seems that the opacity on the element does not reduce the opacity of what's rendered by backdrop-filter on that element; the blur in the example fully blocks out the non-blurred element underneath. In Safari, the blurred backdrop is only rendered at 0.1 opacity. I think Safari's behavior makes more sense here.

However, if we want to adopt Safari's behavior for this case, in terms of the compositing effect graph, I think this requires rendering the backdrop filter inside the opacity, if opacity and backdrop-filter are applied to the same element. But if the backdrop filter rendering goes inside of the opacity, then we have the same problem as in this issue: Opacity is an isolation boundary, so backdrop-filter on such an element would not have any effect. @mfreed7, any ideas for how we should solve this case?

[AmeliaBR]

I was only able to locate two high-ranking sites that have a visible element styled with backdrop-filter.

Instagram uses it for their "please log in" banner when you follow a link directly to a photo page. It's nested many divs deep & some of those divs use position: relative, but the banner itself is position: fixed, so for isolation I guess that count's as a direct child of the window? (In general, looking only for "visible elements" with the style may undercount usage, because a common use case is for pop-ups and other dynamic content.)

[mfreed7]

@AmeliaBR, thanks for the comment, I hadn't noticed the Instagram photo page in my search. The numbers I quoted were for any document containing "backdrop-filter", including CSS or embedded style within an HTML. The platform stats numbers are counted any time the feature is actually used, e.g. when the pop-up pops up. So I think my numbers are still good; correct me if I'm wrong. My subsequent hand-analysis was to just use document.querySelectorAll() for the selector containing backdrop-filter and see what comes back, and it is definitely possible I missed some cases there. Again, thanks for the pointer to Instagram. From the sound of it, though, the Instagram banner would filter everything on the page, given that its parent stacking context is the root element. I am assuming none of the position:relative parents use z-index. Let me know if you disagree. (And if you could post a link directly to a photo from Instagram, that'd be helpful too.)

@mstange, thanks also for the comment about mixing opacity and backdrop-filter. It is definitely an interesting question, though I don't think it actually affects the isolation question. It does call into question the order-of-operations for backdrop-filter. We are debating it now, and I'll have a more detailed response soon.

[mfreed7]

@mstange, I definitely understand the point you’re trying to make - that the results of the backdrop-filter operation are not being painted along with the element itself, including other effects applied to the element (opacity in this case). And I agree that the spec is not very clear on the order of operations for other effects applied to the same element. However, it is important to note that this question is (I think) entirely separate from the question of whether backdrop-filter respects isolation boundaries. The isolation question merely affects which elements get included in the background image that forms the starting point for the backdrop filter. Orthogonal to that, there is the question of how to process that background image, including your question about opacity.

Turning to the specific question of filtering and backdrop-filtering on the same element, I would submit that there are many such ambiguities that really need to be nailed down in this spec. The “right” way to specify and implement it is a grey area. For example, your description assumes that the result of the backdrop-filter should be used as the starting image within the new stacking context created by the backdrop filter. Under that definition, you’re right, the opacity should be applied to the filtered backdrop. But the spec actually doesn’t mention exactly what the behavior is supposed to be. We can see good cases to be made on both sides of this question.

@chrishtr and I currently think that the behavior should be defined to be something like the steps listed below. I believe this clearly defines the order of operations, including filters and transforms, and it also clears up some other ambiguities about the clip border for the backdrop. In addition, and importantly, it is relatively straightforward to implement this in a performant manner. Your feedback is appreciated:

1. Draw the ancestor stacking context (call it A), in paint order, up to the backdrop-filtered element (call it B). Assume the buffer being drawn to this point is called A’.
2. Copy everything painted so far into a temporary buffer (call it T’), and apply the backdrop-filter’s filter operations to that temporary buffer.
3. Apply a clip to the contents of T’, using the border box of element B. Note that the children of B are not considered for this clip.
4. Draw all of element B and the children of B, including any transforms and other effects, into T’.
5. Composite the contents of T’ into A’, using source-over compositing.
6. Continue drawing the remainder of the children of A.

Without a definition such as the above, it is our belief that many interactions (such as your opacity example) will be difficult for developers to reason about, and will also lead to implementation issues and performance problems. With this definition, the behavior is clear and the implementation is straightforward. It also does not change the order of operations that currently apply to stacking contexts. Notably, this does not address your initial point/example - opacity applied to B will not be applied to the backdrop-filtered backdrop. To achieve that, however, you could just change your filter spec to backdrop-filter: blur(10px) opacity(0.1);. That would apply the opacity to the filtered content, and should do exactly what you expect.

Thoughts appreciated.

[smfr]

I'm still strongly in favor of having backdrop-filter affect all of the content behind, not just the enclosing isolation group. We want this example to blur the striped body background:

[mfreed7]

@dirkschulze, the difference here is that the ancestor stacking context of the backdrop-filtered element would need to be made a containing block. Not the element itself, unfortunately.

[mfreed7]

@mstange, we were discussing your comment above concerning opacity. There are several examples where it would make sense for the filtered backdrop to form the starting point for the backdrop-filtered element, so that opacity (and other filters) would apply to that filtered content. One example would be a dialog box that “fades out”. Given that this change should not cause any performance issues, I’ve modified our proposed definition for backdrop-filter. I also included more detail about transforms applied to the backdrop-filtered element, to clarify those as well. Your feedback is appreciated:

1. Draw the ancestor stacking context (call it A), in paint order, up to the backdrop-filtered element (call it B). Assume the buffer being drawn to this point is called A’.
2. Copy everything painted so far into a temporary buffer (call it T’), and apply the backdrop-filter’s filter operations to that temporary buffer.
3. If element B has any transforms, apply the inverse of those transforms to the contents of T’.
4. Apply a clip to the contents of T’, using the border box of element B. Note that the children of B are not considered for this clip.
5. Draw all of element B and the children of B into T’.
6. If element B has any transforms, effects, or clips, apply those to T’.
7. Composite the contents of T’ into A’, using source-over compositing.
8. Continue drawing the remainder of the children of A.

Again, we believe that having backdrop-filter only apply up to the parent stacking context makes sense for these reasons:

1. It is the only definition that can be unambiguous for the case of nested elements with filters and opacity applied. If we simply define it to filter “everything behind”, there will be many corner cases that will need to be very carefully and explicitly defined; otherwise, each implementation will inevitably produce different output. See, e.g., my original example with three different behaviors from three browsers, for just the simple case of opacity applied to the parent element.
2. It will allow performant implementations. As far as we can tell, nested backdrop-filters that don’t respect isolation will suffer exponential performance degradation, as each one doubles the required rendering work.
3. It is exactly analogous to mix-blend-mode, and we see no reason to have different behavior for similar operations. In addition, all of the logic that went into making mix-blend-mode respect isolation should also apply to backdrop-filter.

[mfreed7]

In trying to demonstrate what we see as a fundamental problem with allowing backdrop-filter to filter everything that comes before it, we created this example page. This page did not behave as we (or anyone?) would have expected, when loaded within Safari, which filters everything behind the element. I have included screenshots from Chrome and Safari below.

This example contains a parent element (the big one containing the text) that has an invert filter applied, so it shows up as black background with white text. The "dialog" element is a child of that inverted element, so it should inherit the invert filter. So our expectation was that the already-inverted backdrop of the dialog would be used as the starting background for the dialog element, then the remainder of the dialog would be rendered (e.g. the blue border) and then the entire thing would be inverted again, because of the inherited filter. That should result in the text within the dialog going back to white background with black text, and a yellow, inverted border. What happened instead is some strange mix of the two. Only one invert was applied, as the text inside the box is still white on black background (inverted only once). The borders did get inverted, because they're yellow. And even more confusing, the background outside the text region is also inverted to black background and white text. So the right half of this dialog is inverting the background, and the left half is not. And this is all interesting, because naively, we expected almost exactly the opposite. It is this confusion that we are concerned about, in general. It will lead to differences in implementation, and general confusion among developers. Keep in mind - the point here isn’t that there is a bug in this particular implementation. The point is that it is very difficult to define what “correct” means, when filtering passes beyond an element with effects applied.

Chrome 72:

Safari 12:

[mfreed7]

The most common argument we've heard against making backdrop-filter respect stacking context isolation boundaries is that it is too restrictive. Particularly when the stacking context is created by an operation that shouldn't cause any real problems for backdrop-filter, such as 2D transforms and fixed position elements. These are definitely valid points. We still believe (strongly) that there are fundamental problems with having backdrop-filter "see" above an element with effects applied, however. To attempt to relax some of the constraints of stacking contexts, while still retaining the needed boundaries for effects, we have defined a new concept, which we're very tentatively calling the Backdrop Root. Please see this document for a detailed explanation of both the solution and the problem, as we see it. Comments are very welcome - this is a draft idea.

[ChumpChief]

I realize I'm a bit late to the party, but I'm really glad to see motion in the direction of a formal definition of "backdrop", and I think Mason's doc also does a great job of outlining possible problem scenarios that we should be able to iterate through and reach consensus on what should happen. I suspect everyone on the thread would agree that at minimum the root element should form the root of the backdrop, so then it's just the other bullets we'll need to agree on :)

I also share concerns about the restrictions surprising developers or blocking potentially valid usage, so I think it will be good to reason out why each of these scenarios can't be solved or alternatively how to overcome that challenge. I see some of this discussion in Mason's doc already - what would be the most productive way to open up discussion/iterate on each of these points? Maybe we can resolve to start by adding an initial formal definition of "backdrop" or "backdrop root" to the spec with minimal restrictions (just root element) and then open issues for each additional restriction we'd like to consider for discussion? Or just comment directly in Mason's doc and later try for a resolution on the full definition all at once? Or something else?

A final couple thoughts:

• I think it makes a lot of sense for mix-blend-mode's "backdrop" to ultimately share a definition with backdrop-filter's "backdrop" as others mention above (hopefully at least somewhat more relaxed than stacking context).
• My instinct is that relaxing restrictions on the definition of backdrop should generally be a compatible change for content authored against the more restrictive definition. Both because it's primarily a visual-only change but also I'm having a hard time hypothesizing a scenario where a developer takes a hard dependency on content behind the element in question dodging the filter/blend.

[mfreed7]

We would like to publish a proposal for spec changes for backdrop-filter. It includes many of the ideas discussed on this issue, plus a lot of extra background and motivation for the changes. I have created a PR for the fxtf-drafts repo, and I've included the rendered spec output here:

https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html

We would love to hear comments on this proposal.

@ChumpChief, thanks for your comments. In our proposed spec, I've included a lot of detail in the "Motivation" section. In particular, I added a rationale for each of the restrictions included in the definition of the Backdrop Root. Hopefully that's a good starting point for the discussion!

[AmeliaBR]

@mfreed7 Is this proposal a description of what one of the browsers currently does, or would it require some changes for everyone?

[mfreed7]

Good question, @AmeliaBR. Only one browser currently ships backdrop-filter: Edge. Webkit has a prefixed version, and Mozilla and Chromium don't have a shipped backdrop-filter implementation.
In terms of what's actually implemented in code, behind flags:

• We have been working towards this proposal in our implementation over the last several months in Chromium, so we are likely closest to this description at this point. We still have some work to do.
• Webkit's and Edge's implementations mostly differ in that they do not stop filtering at filter, opacity, or mask/clip nodes.
• I do not know what is implemented in Mozilla, if anything. (@mstange has previously sounded supportive of some parts of this proposal - I would love to hear his thoughts here.)

[mstange]

• I do not know what is implemented in Mozilla, if anything. (@mstange has previously sounded supportive of some parts of this proposal - I would love to hear his thoughts here.)

Mozilla has not started implementing backdrop-filter, mostly because of the lack of clarity on this very issue. (And also due to resource constraints.)

I've taken a look at the proposal, and I think it's great! Really terrific work. It clarifies all the previously-unspecified points (at least the ones I can think of), and it addresses the use cases that have been brought up before which would have been limited by the previously-proposed approach of respecting isolation.
However, I do have a few concerns:

• I don't believe making the backdrop root a containing block is a good idea. More on that below.

• I would like to see some discussion of how the isolation property plays into this. I see that isolation: isolate is not among the properties that cause backdrop roots. Should it be?

• Making rounded-corner overflow clips cause backdrop roots seems like an unnecessary restriction to me. In Firefox, we make no attempt to apply the rounded corner clip to the entire contents of the clipped element in one step; instead, the rounded clip can be pushed down into the "leaves" of the effect tree whenever necessary, and we accept the imperfect anti-aliasing (and the possibility of bleeding) that this creates. And in some cases, applying the rounded overflow clip to the entire contents isn't even possible, and the clip has to be applied to different parts of the element's contents individually. (I'm referring to the interleaved <roundedclip><A/><fixedposition/><B/></roundedclip> case.) This is an existing scenario that browsers have to support, and I think in Firefox, our existing solution to this would just work for the purposes of computing the backdrop-blur input.

• Speaking of Firefox's implementation, our compositor currently has two more triggers for intermediate surfaces that are not on the list of backdrop root triggers:

  • Clipped transforms (even if the clip is just a rectangle overflow clip without rounded corners): If you have <rectangleclip><rotation>layerized contents</rotation></rectangleclip>, then our compositor creates an intermediate surface for the rotation and applies the rectangle clip when drawing the rotated surface into the outer render target.
  • 3D transforms, even unclipped, always get an intermediate surface.

  I don't think we should add these two cases to the list of backdrop root triggers, because it would defeat much of the point, but this does mean that, at least in our initial implementation, Firefox will likely need to do an extra render pass to compute the backdrop input inside transforms, and won't be able to just use the contents of the current render target.

Now, to my main objection: The creation of a containing block for the backdrop root. Quoting from the proposed text:

Note: In addition to the stacking context and containing block formed by the element with backdrop-filter, the corresponding Backdrop Root element also forms a Containing Block for all descendants. This is to avoid child absolute or fixed position elements that do not get clipped by parent clips or overflow:scroll elements, but which need to be read back to form the Backdrop Root Image.

I think this is not a good idea for two reasons: 1. It has non-local effects and 2. it doesn't seem necessary to me.

Here's an example to demonstrate the first point:

<div style="opacity: 0.9; height: 100px;">
  <div style="position: fixed; bottom: 0; background: green; width: 20px; height: 20px;"></div>
  <div style="backdrop-filter: blur(1px)"></div>
</div>

As far as I can tell, the mere presence of the element with the backdrop-filter changes the position of the fixed element: If the backdrop-filter element is not present, then the fixed element will be fixed with respect to the page and will be located at the bottom of the browser viewport. But if the backdrop-filter element is present, then the wrapper element with the opacity becomes a backdrop root and suddenly turns into the containing block for the fixed element, and the fixed element ends up in a completely different place. I think this behavior would be very surprising to web authors.
It would also mean that the answer to the question "Is element A a containing block for fixed-position descendants?" depends on element A's descendants, which is very unusual.

I realize that this point was brought up in November by @chrishtr on this issue.

(*) Example to avoid: a position:{fixed/absolute} element which is a child of the containing isolated group to backdrop-filter. Without making the isolated group a containing block for such elements, this element can skip clips and scrolls above the backdrop-filter in the DOM, which is illogical.

I agree it's not intuitive, but I think we're kinda stuck with the behavior of elements escaping clips and scrolling while still being subject to effects from DOM ancestors. Browsers already have to support nesting such as <scrollbox><opacity><A/><fixed/><B/></opacity></scrollbox>; in this case the opacity group contains both the fixed content and the non-fixed content. It seems to me that taking this "mixed content" as the input to a backdrop-filter is just as hard as applying opacity to it. Or, in other words, the Firefox implementation would not benefit from a new restriction for backdrop-filter since our existing infrastructure should be able to handle this case just fine.

[AmeliaBR]

Would it be possible to extend isolation to have a third value that means "don't isolate, even if this is a stacking context or other element that usually causes auto isolation". This would be similar to how transform-style: preserve-3d works.

(Currently, isolation only has two values, isolate vs auto.)

This would address the authoring issue (authors often expect the backdrop filter to filter everything behind the element, but maybe they also expect isolation to limit it if they're using blending or opacity). But it could be more complicated for implementers, as they would need to implement both behaviors, both for backdrop filtering and for blend modes.

Edit: Whoops, missed the comment about this above: #53 (comment)

[css-meeting-bot]

The CSS Working Group just discussed Backdrop Filters, and agreed to the following:

• RESOLVED: Add the proposal with an issue

The full IRC log of that discussion

<fantasai> Topic: Backdrop Filters
<fantasai> chrishtr: Backdrop filters was discussed last year at F2Fs and at tpac, and the concerns raised were all about efficient implementaility and clear semantics
<fantasai> chrishtr: In aprticular cases having to do with whatppanes if there are filters above backdrop filter element
<fantasai> chrishtr: Did a bunch of research on explicit examples
<fantasai> chrishtr: looking for undesired behaviors
<astearns> github: https://github.com//issues/53#issuecomment-451599995
<fantasai> chrishtr: Also researched use case that are considered important
<fantasai> chrishtr: Number of uses cases involving rtransforms, for example, the folks at Apple, smfr et al. mentioned wnating to use transforms to rotate something inside an overlay of a video element
<fantasai> chrishtr: So don't want backdrop filter to stop at the transform
<fantasai> chrishtr: New proposal that avoids strange behavior of filters and opacity
<fantasai> chrishtr: And problems of not applying atomically
<fantasai> chrishtr:while also supporting stacking context without visual effects
<fantasai> chrishtr: or stacking contexts that should be able to with more clever code support in compositing systems
<fantasai> chrishtr: ...
<fantasai> chrishtr: backdrop filter root would only be applied for elements with filters
<fantasai> chrishtr: opacity
<fantasai> chrishtr: and masks and clip path and mix-blend-mode
<AmeliaBR> The proposal: https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html
<fantasai> chrishtr: and in our proposal a border ardius clip
<fantasai> chrishtr: got general positive feedback from experts form MSFT
<fantasai> chrishtr: and also some feedback from Markus from Mozilla
<fantasai> chrishtr: Markus raised some concerns, Mason and I were whiteboarding to solve
<fantasai> chrishtr: Feedback was browers have a lot of complexity around how containing blocks and DOM parentage don't agree
<fantasai> chrishtr: Browsers in effect have to push clips, particularly background corner clipis, and apply them non-atopically
<fantasai> chrishtr: can have undesired bleeding and fringes around rounded corners
<fantasai> chrishtr: we thought it through and agreed that's the case, and agree that it shouldn't be necessary to require backdrop root for rounded corner clips
<fantasai> chrishtr: second concern was that current spec proposal, there's an action at a distance going on
<fantasai> chrishtr: If you put background filter on an element, the background filter root implied by that element becomes a containing block for all of its descendants
<fantasai> fantasai: including fixedpos items?
<fantasai> chrishtr: Yes
<florian> fantasai: this seems a little extreme
<fantasai> fantasai: that seems really extreme
<fantasai> smfr: That's the same as filters?
<fantasai> chrishtr: That has to do with excessive difficulty of composititng
<fantasai> chrishtr: Under same rationale under roposal
<florian> fantasai: hang on, what?
<fantasai> chrishtr^: This creates situation where a descendant can change behavior of the parent
<fantasai> chrishtr: Let's suppose you have an element with opacity on it, and then you have a descendant with a backdrop filter
<fantasai> chrishtr: Element with the opacity is the backdrop filter root on that other element
<fantasai> chrishtr: under this proposal, the backdrop filter root becomes a contianing block for all descendants
<fantasai> chrishtr: That means presence of a property on a descendant has side effecct of making some ancestor that has opacity on it ecome a containing block
<florian> fantasai: that's really bad
<fantasai> chrishtr: This avoids the complexity of the problems of mismatch beteween conianing block and dom order
<fantasai> chrishtr: Because the content underneath the backdrop filter root that paints before the backdrop filter element is stuff that needs to be drawn into an image behid the element
<fantasai> chrishtr: that's the point of the feature
<fantasai> chrishtr: We concluded that Markus is right htat we don't need this so we cna remove it from the spec proposal
<fantasai> AmeliaBR: You've obsoleted my question by removing this
<fantasai> AmeliaBR: what are you replacing it with?
<fantasai> chrishtr: There will still be a backdrop root
<fantasai> chrishtr: Everything here except the border radius would be a backdrop root?
<fantasai> AmeliaBR: Are these all things that create a conaining block?
<fantasai> chrishtr: no, opacity doesn't create a containing block
<fantasai> chrishtr: in certian stiuations you'll be able to see a fringing effet
<fantasai> chrishtr: Way opacity is implemented, browsers commute with clip
<fantasai> chrishtr: we push the clips down below the opacity
<fantasai> chrishtr: multiple clips that can occur
<fantasai> chrishtr: can even have mutliple mask textures happening
<fantasai> chrishtr: these clips are not necessarily atomic. Opacity is atomic but others aren't
<fantasai> chrishtr: you might see certian effets at the corners
<fantasai> chrishtr: We have no choice but to push down the clip because of opacity vs clip
<fantasai> chrishtr: because clip is applied before the blur filter, someof the colors of pixesl that were outside the clip will no longer appear in the output
<fantasai> AmeliaBR: My general comment is that I don't like having yet another category of properties that cause a special behavior
<fantasai> AmeliaBR: we already have stacking contexts and containing blocks and isolation and certian properties affect one but not the other
<fantasai> AmeliaBR: if anyone wants to make a table which propertis trigger which behaviors?
<fantasai> dbaron: I did that!
<fantasai> dbaron: My table came with tests, and I filed a bunch of bugs with it
<fantasai> dbaron: Some of the bugs are just described at the bottom of the table
<fantasai> dbaron: not necessarily all filed...
<fantasai> chrishtr: Table was great!
<dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order
<fantasai> AmeliaBR: If we can make sense to synchronize one of the existing definitions, would be great
<fantasai> AmeliaBR: Otherwise need to be really clear with authors why differences
<fantasai> AmeliaBR: With transform-style and 3D, authors got really annoyed when some browsers triggered flattinging on opacity and others didn't
<fantasai> chrishtr: Things that trigger flatting are almost the same as this list
<fantasai> AmeliaBR: If we can sync the lists that'd be very helpful
<fantasai> chrishtr: Transforms spec has a lot of compat restrictions. Open question of can we move the Web to that model without breaking things.
<fantasai> chrishtr: Could have a common name for htis
<fantasai> chrishtr: new concept
<dbaron> (and the above table is actually a *test* and will produce different results in different browsers)
<fantasai> chrishtr: When mix-blend-mode was specified, the final decision was to make it only to the conaining stacking context
<fantasai> chrishtr: I think that was chosen because it doesn't introduce a new concept
<fantasai> chrishtr: but there's been rightly some concern that this make the feature not as expressive as it could be
<fantasai> chrishtr: Apple engineers had this position
<fantasai> chrishtr: So we could maybe even change mix-blend-mode to match this and make it better than today
<fantasai> astearns: So you are concerned about introducing notion of backround root?
<fantasai> AmeliaBR: Just concerned that it's similar but slightly different from other concerns
<fantasai> AmeliaBR: If we can sysnc them, that woudl be great.
<fantasai> chrishtr: Wrt your comment about isolation, yeah, isolation: isolate creates a stacking context, not a contianing block. Maybe a different hting could do that.
<fantasai> AmeliaBR: Another thing is that contain: layout does almost the same thing
<fantasai> AmeliaBR: It creates stacking context, conatining block, etc. Maybe that property suffices
<fantasai> s/Amelia/christr/ x2
<fantasai> smfr: ...
<fantasai> smfr: Backdrop was always intended to be everyting under the element all the way up to the root
<fantasai> smfr: There are some issues with ancestors, but I think that's what the author want.s
<fantasai> dino: it also means they don't have to tweak their content to do what they want to do
<fantasai> dino: It's not difficult in our impl
<fantasai> dino: We do need to fix up to define edge cases like ...
<fantasai> dino: It's a shame that it's inefficient in some engines. It's not in ours.
<fantasai> dino: Want to build on what smfr says. Backdrop this way will require authors to change how their content works.
<fantasai> dino: We definitely have bugs in the webkit implementation that we should fix
<fantasai> q+
<fantasai> chrishtr: I can't say I really agree with that.
<fantasai> chrishtr: This is just something that developers can know about. We can describe succintly
<fantasai> TabAtkins: We've had examples of things being double-filtered or otherwise being weird.
<fantasai> TabAtkins: Safaris' definition is just "whatever CoreGraphics does"
<fantasai> TabAtkins: That's not well-enough defined. We don't even know what it does.
<fantasai> smfr: I volunteer Dean to write that up.
<fantasai> Markus: I mostly agree with Chris.
<fantasai> Markus: I think Safari's current behavior is confusing and hard to define what should be the outcome with opacity effets.
<fantasai> Markus: I don't agree that authors will have to change their content
<fantasai> Markus: I think usually there will not be filters on the ancestor of the element with the backdrop filter
<fantasai> Markus: Have yet to see a case where Google's proposal imposes a limitation
<fantasai> dino: we do have example of backdrop filters and opacity on the ancestor
<fantasai> dino: Every video on iOS does this.
<fantasai> dino: The play button on videos fades in and out
<fantasai> dino: It works fine
<fantasai> dino: I we implement this new backdrop root, then have to fix that.
<fantasai> Markus: So opacity is on a different elent than the backdrop filter?
<fantasai> dino: yes
<fantasai> dino: Controls might have things that you don't wnat backdrop filters on, such as subtitles.
<fantasai> dino: With video and controls, have conmplicated structure under the video
<fantasai> dino: Sometimes things have backdrop filter, some don't; some things fade in/out, others don't.
<fantasai> dino: To Google's credit, they figured out how to do this, but it is a change.
<fantasai> dino: I agree that we haven't specced i well enough.
<fantasai> dino: I volunteer smfr to write it up
<fantasai> dino: It's up to us to define exactly what we've implemented.
<fantasai> dino: Will cause us to understand our bugs and fix them too
<fantasai> dino: And we can better analyze what Google has come up with so far
<fantasai> dino: Wrt efficiency, actually on mobile devices implementing it Apple's way might be more efficient based on the way mobile GPUs work.
<fantasai> dino: Also we thought about how wWebKit would implement Google proposal
<fantasai> dino: would have to clear away whatever's under the elemnet
<fantasai> dino: [gives an example]
<fantasai> astearns: ...
<fantasai> dino: Don't want to block work on the proposal. It's up to Apple to provide more info and counter-proposals.
<fantasai> dino: We object in the sense that we don't think it's the right thing to do, but not in the sense that we will fight you on the beaches.
<fantasai> astearns: We have a resolution on having backdrop-filter in general, right?
<fantasai> chrishtr: So we need a resolution to put this into the draft.
<fantasai> s/so//
<fantasai> dino: The core difference in the proposal is adding backdrop-proposal. The core difference is where do you take the backdrop from.
<fantasai> chrishtr: In terms of web compat, this should be quite compatible. We did research finding no examples; didn't find the iOS example
<fantasai> chrishtr: Also Safari's implementation is prefixed. Edge's is not, but that will be Blinkified
<fantasai> chrishtr: With all that we propose to resolve on this?
<fantasai> astearns: So proposal is to add the backdrop-root proposal to the draft minus the rounded corners
<fantasai> chrishtr: and minus the part about backdrop-root causing containg block
<fantasai> fantasai: What are we doing?
<fantasai> chrishtr: We have a backdrop-filter property in the spec, we are adding concept of backdrop root
<AmeliaBR> Current spec definition: https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty
<fantasai> chrishtr: What I'd like to resolve on is that we define a backdrop root to be according to the thing on the screen minus the part about rounded corners and minus the part about backdrop-filter createing a containing block
<AmeliaBR> New section (plus other edits): https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html#BackdropFilterProperty
<fantasai> chrishtr: When a backdrop-filter is present, it means tha tyou draw all content underneath its containign backdrop root into an image buffer and the filters apply to that
<fantasai> chrishtr: and it's drawn underneath the backdrop filter element clipped to its rounded border rect
<fantasai> chrishtr: That clarification about rounded border rect is also a clarification
<fantasai> Markus: Also defines order of operations wrt opacity, wasn't defiend before
<fantasai> astearns: So by putting this into the draft, that becomes the place we discuss whether this is how we do it or whether there's an alternative proposal
<fantasai> dino: Add an issue describing this
<fantasai> hober: We're OK adding it to the spec provided there's an issue noted in the spec describing that this is still under discussion
<fantasai> astearns: So we're not waiting on Apple to have an explanation of CoreGraphics, but here's our current proosal and an issue saying it's still under discussion to maybe make more like Safari
<hober> s/this is still under discussion/there is no consensus on having such a property/
<fantasai> [discussion of how to make an issue note in the spec]
<florian> fantasai: we file issues in the tracker generally, but also sometimes we mark it in the spec, possibly with a link to a gihub issue, to warn the reader about the existing discussion, disagreement, etc,
<fantasai> astearns: Any objections to adding to spec with issue marker?
<fantasai> RESOLVED: Add the proposal with an issue
<florian> s/etc,/etc/
<fantasai> s/issue/issue noted in the spec/

[mfreed7]

I have updated my pull request per the discussion just now:

• Removed overflow:clip with rounded corners as a Backdrop Root trigger
• Removed the containing block induction note - Backdrop Root no longer is a containing block.
• Added an Issue link at the top, currently pointing to this issue, but can be redirected to a new issue.

Link is (still) here: https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html

[mfreed7]

The new spec is located at the "normal" place now: https://drafts.fxtf.org/filter-effects-2/

[css-meeting-bot]

The CSS Working Group just discussed backdrop filter disagreement.

The full IRC log of that discussion

<TabAtkins> Topic: backdrop filter disagreement
<TabAtkins> dbaron: My understanding is that there's disagreement between WK and Blink about how b-f should work
<TabAtkins> dbaron: previous state is that spec is kinda vague
<TabAtkins> dbaron: Current state is that blink engineers wrote a new spec that reflects their engine, and WK disagrees with this.
<TabAtkins> dbaron: a) if would be good to solve this to get with interop
<astearns> github: https://github.com//issues/53
<TabAtkins> dbaron: b) we have a summer intern that should work on this
<TabAtkins> dbaron: If this is a viable project we need to tell this intern what to do
<TabAtkins> dbaron: I think part of teh problem is that we don't necessarily have the righ tpeople in the room
<fantasai> TabAtkins: Sounds like our objection is based on our technical architecture
<fantasai> TabAtkins: WebKit's is based on their technical architecture
<TabAtkins> mstange: I agree with Chrome's proposal entirely; there were some objections, they got addressed
<TabAtkins> mstange: Chrome's proposal is easier to implement and make smore sense to authors imo
<fantasai> TabAtkins^: y'all presumably also have a preference based on your technical architecture?
<TabAtkins> mstange: Other resolution from last time is that if Apple wants their impl in spec they have to write up how that works
<TabAtkins> hober: As far as I understand, Dino still has that action.
<fantasai> TabAtkins: Given questions we had on "how does it work" were "we're not sure"
<fantasai> TabAtkins: I can't in good conscience accept their proposal
<fantasai> TabAtkins: Right now we have a choice between "here's an explicit algorithm" and "we haven't described this yet"
<TabAtkins> dbaron: Having seen some of the discussion...
<TabAtkins> dbaron: I think WK was arguing their stuff is betteer fo rusers
<TabAtkins> dbaron: I think I'm sympathetic to that, looking at examples, but it does require details of how it acutally works
<TabAtkins> mstange: Stil important questions, like does it punch thru group opacity, etc
<TabAtkins> mstange: So in examples where you have opacity but not group opacity, those are simpler cases.
<Rossen_> q?
<TabAtkins> mstange: So putting in a special case into the spec that lets you punch thru opacity when it's not acting as group opacity, that's tricky. And letting it punch thru when it *is* group opacity, that's hard to predict.
<TabAtkins> AmeliaBR: So all we can resolve right now is that we need a clear description...?
<TabAtkins> Rossen_: That's where we left it last time.
<TabAtkins> dbaron: And Apple engineers should be aware that if they don't give details, we're probably defaulting to Chrome's implementation.
<TabAtkins> myles_: The technical burden of altering Core Animation to support Chirome's behavior is on the sam eorder of magnitude of altering CHrome's compositor to support our behavior.
<AmeliaBR> s/.../ of the disagreements between the implementations/
<TabAtkins> iank_: Par tof our reason for our architectur eis because we care about very low-end memory gpu classes
<TabAtkins> dbaron: So that's about it.

[mfreed7]

Ugh. The new spec was written as it was because nesting backdrop filter within elements that inherit (like filters and opacity) causes fundamental problems. Please see the Example under Backdrop Root Motivation, or the example above of when things go wrong, in Webkit, because of this very problem.

[mstange]

FWIW, nothing new was discussed during today's meeting. Please don't read too much into the log. From what I can tell, every browser maker's position remains the same as in March.

(I can clarify my comment about opacity but I don't think it's relevant.)

[mfreed7]

Thanks @mstange. I think I understand what you're going for on the opacity comment - basically, you're saying that "filtering everything" will require special rules for what to do in the myriad nesting cases for opacity (and also filters). Unless the spec is basically "just put something on the screen there, I don't care what it is", it'll be tough to spec, I suspect.

[tabatkins]

Yeah, the core idea is that unless/until WK actually describes their behavior, which they were tasked with doing at the last meeting, we're going with the current spec (Chrome) behavior. And if they don't do that reasonably quickly, Firefox will likely follow the spec, and begin fully locking in that behavior.

[mfreed7]

Thanks @tabatkins. Do you think July 30, 2019 (the M76 stable release date) constitutes "reasonably quickly"?

[tabatkins]

That's up to Firefox, so I dunno.

[cabanier]

Can we update the CSS Compositing spec so it refers to backdrop root instead of stacking context?

[mfreed7]

@cabanier, I would love that change, but don't you think it would cause web compat issues? The use counter is fairly high, and the visual appearance might change if mix-blend-mode starts blending more of the backdrop.

[AmeliaBR]

The compat issue against changing mix-blend-mode could be addressed by adding a new isolation value. auto (the default) could still isolate by stacking context, but there could be an override (dont-isolate?) that uses the full backdrop, if there are no technical reasons not to support that.

Connecting that back to backdrop-filter: the auto value of isolation is defined to be sensitive to a lot of context. If the default isolation behavior creates nonsensical results when combined with backdrop-filter, then a different behavior could be defined specifically for the interaction between the two properties.

[cabanier]

@mfreed7 yeah, there could be content that will suddenly look different. I'm unsure if this could be detected by a use counter; it could be too costly to calculate.

@AmeliaBR in one of the previous versions of the spec, we had the non-isolated property (which matches the Adobe products). Maybe we can bring that back?
An unfortunate drawback is that there will still be content that will always force isolation (ie filters). I'm unsure how confusing this is for users.

[samer-Sp]

Currently, the spec says "The first filter function or filter reference in the list takes the element's BackgroundImage as the input image."
This was a mistake on my part. BackgroundImage is defined as the backdrop up to the isolation parent.
What we really want is a new term, BackdropImage, which is the backdrop of the element, including all parents and siblings that have been painted up to the point of the filter. There is no isolation.