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

@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](https://drafts.fxtf.org/filter-effects-1/#attr-valuedef-in-backgroundimage))
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.

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

Received on Friday, 12 October 2018 19:49:21 UTC