Re: [fxtf-drafts] Fix the backdrop-filter order of operations to get opacity right (#361)

@mstange, I can see your point about Safari compat. However, there is already a bigger compat issue there, w.r.t. the [Backdrop Root](https://drafts.fxtf.org/filter-effects-2/#BackdropRoot) concept, so I'm not sure the nuances of opacity are as important here. Though clearly we should try to get all of this right, as much as there is a "right".

And I can understand your intuition about expecting fractional opacity to interpolate. But I would disagree about which parts of the behavior matter more for intuition. Your point is that while animating between two opacity values, there could be a tinge of partially filtered content visible. Perhaps I'm wrong, but that seems like a very subtle difference. My concern is that there will be confusion about why the effect isn't working **at all**, when opacity is used. Or there will be confusion about why a background with animated alpha behaves differently from animated opacity on the element. See, e.g., the description given on the [MDN page for backdrop-filter](https://developer.mozilla.org/en-US/docs/Web/CSS/backdrop-filter), or our recent [blog post](https://web.dev/backdrop-filter/) on the feature. Both refer to either making the background transparent, or making the element transparent (with opacity) to "see through" it to the backdrop-filtered content. This seems to indicate that the "default" intuition is that backdrop-filter modifies/filters the "backdrop" of the element, not the element itself. I.e. you're looking **through** the element to see the backdrop-filtered content **behind** it. So you just need to make the element transparent somehow, to see through it. Breaking this symmetry between background alpha and element opacity seems not great. I will definitely concede that the metaphor is imperfect already, as filters and opacity applied to the element also affect the backdrop-filtered content. But I think the points above about the transparency intuition still hold.

As for effect nodes, I think that is implementation dependent. The Chromium implementation still has a single effect node for opacity in this case. In the case of an element with both opacity and backdrop-filter, there will still be only a single effect node, containing both the backdrop-filter list and the opacity value. The filtered backdrop content is drawn as a separate intermediate step after rendering the element's content, and before compositing it into the backdrop surface.

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

Received on Monday, 19 August 2019 21:16:21 UTC