W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > November 2018

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

From: Mason Freed via GitHub <sysbot+gh@w3.org>
Date: Sat, 10 Nov 2018 00:29:18 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-437536695-1541809757-sysbot+gh@w3.org>
@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 <code>backdrop-filter: blur(10px) opacity(0.1);</code>. That would apply the opacity to the filtered content, and should do exactly what you expect.

Thoughts appreciated.

-- 
GitHub Notification of comment by mfreed7
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-437536695 using your GitHub account
Received on Saturday, 10 November 2018 00:29:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 November 2018 00:46:02 UTC