Re: [fxtf-drafts] [filter-effects-2] Backdrop filters should not use BackgroundImage (#53)

> * 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:

```html
<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, I don't see the benefit from a new restriction for `backdrop-filter` since the existing infrastructure for this case should be able to handle it just fine.

-- 
GitHub Notification of comment by mstange
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-466863280 using your GitHub account

Received on Monday, 25 February 2019 03:55:11 UTC