Quick note that the spec change PR has been approved, so the spec is now located here:

https://drafts.fxtf.org/filter-effects-2/

Is it possible to request that this definitely gets discussed at the F2F on May 21? I'm hoping to ship this in Chrome M76, which branches on May 30. Not much time to incorporate any recommendations or comments!

Worth mentioning that there were web-exposed implementations of backdrop-filter in Webkit and EdgeHTML, in addition to Chrome's flagged feature. They weren't all consistent in the details, but @mfreed7's PR, now incorporated in the draft, addressed many inconsistencies. I'm not sure the status of updating the WebKit implementation to match.

Discussion is mostly contained in https://github.com/w3c/fxtf-drafts/issues/53 (including discussion that strays beyond the title of that issue).

Not sure what is meant by "addressed inconsistencies" but to be clear, Chrome implemented something different from WebKit, there is not consensus that this is correct, and there's an issue marker reflecting the lack of consensus (as shown in that issue). CSS WG agreed to the PR on the condition that the lack of consensus be recorded.

It would be really good to get the spec and all browsers on the same page. But it's wrong to imply that the spec has resolved this, and that WebKit is buggy by not matching it.

At the heart of this disagreement is that WebKit's model is apparently hard to implement in Chrome's compositor, but Chrome's model is hard to implement in WebKit's compositor. "Let's spec what Chrome does" is not an entirely satisfactory resolution to this dilemma. We (WebKit folks) also believe that our model is more useful to authors. And we are also remiss in not having written down our model in more formal spec language.

@othermaciej Apologies for confusing matters. I hadn't realized that the decision to merge the pull request was despite lack of consensus. So — while it specifies many previously unspecified non-interoperably implemented details — saying it “addresses inconsistencies” may have been premature.

Regardless, for the purpose of this TAG review, I thought it was important to record that there were multiple implementations, and some had shipped as non-experimental APIs, and that the shipped implementations weren't fully interoperable, since none of that was in the original request for review.

But your contributions about lack of consensus, & the underlying architectural issues behind it, are equally important for the discussion, so thanks for the clarifications.

Just to add a bit more color to this discussion - if you read through the w3c/fxtf-drafts#53 discussion, you'll see a rather large conversation about the fundamental problems with nesting backdrop-filter inside filter/opacity parents. Our proposed/approved spec addresses this issue by defining the Backdrop Root concept, which avoids these issues while allowing as much of Webkit's shipped (but unspec'd) implementation as possible. We iterated the spec multiple times with comments and discussion from the community, and we were able to remove many (but not all) of the restrictions on backdrop-filter. There is also a large discussion within the spec relating to these issues, and describing why the Backdrop Root is necessary. This issue was discussed at length, both in the github issue, as well as at the Feb 25 F2F, and both Edge and Mozilla gave supporting comments both places. Webkit's objection at the F2F, which is the sole reason for the note about a lack of consensus, is that backdrop filter should "just filter everything". There has been an open action item for Webkit to resolve/address the fundamental problems with that proposal since Oct 2018.

I do apologize for not including a more detailed state of implementation among the browsers.

My response was mainly to @AmeliaBR 's comment, not to the review itself. I agree that this is an accurate history of the issue. WebKit still owes a write-up of our preferred model that is sane and not ambiguous (and I will try to make this happen sooner rather than later). I disagree that the problem you cite is "fundamental" or inconsistent with backdrop-filter filtering everything below the element. Filtering everything below is kind of the point of backdrop-filter. But for the moment, I use wanted to be clear that there is not consensus on the spec text yet, and it's not accurate to suggest that "file bugs on WebKit" is the correct next action.

Hi! I just want to say that we are using Backdrop-filter for years now on the basis that it filters everything behind it regardless of nesting, and we hope that you will not break it!

We are using it in the caramellaapp.com editor (Header toolbox and PopOver menus) We are also stacking Backdrop-filters on top of each others (We gave the buttons in the PopOvers an extra Backdrop-filter to intensify the inherited color tint), and we gave the share button in the header an extra Backdrop-filter also to pop-it out..

Teaser showing the filter (https://www.youtube.com/watch?v=04qRb46m0f0)

Another note: Why is Mix-blend-mode not working on top of Backdrop-filter in any browser? (I mean when the blended element is on top of a backdrop effect created by another element behind it) In Caramella (And in the above screenshot) we are using Backdrop-filter a lot to simulate Mix-blend-mode that is not really working, like the Share button in the top left of the shot can be just blended to give that effect but Mix-blend-mode is so unpredictable because of all the stacking nonsense!

Dear TAG, could I get an update on this review? I see that it was discussed very briefly at the last F2F meeting, but there is no comment on here about it.

Dear TAG, could I get an update on this review? I see that it was discussed very briefly at the last F2F meeting, but there is no comment on here about it.

Hi, sorry about that. @alice and I discussed this issue over the course of several breakout sessions in Reykjavik. We were mostly grappling with the bigger question about how we can help other groups move forward when different implementors have fundamental implementability concerns with each other's preferences. We considered whether our approach to such situations needs to change in light of the major reduction in web engine implementation diversity we've recently experienced.

@hober, ok, thanks for the update.

I just wanted to give you the heads-up about a PR I made to change the spec very slightly. Essentially, the change is that for pixel-moving backdrop-filters, the input image will not be expanded beyond the bounds of the element. This improves compat with Webkit, and seems to be well-received by developers.

My current plan is to ship this feature in Chrome M76, currently in Beta, stable around July 30.

Hi @mfreed7,

@Alice and I are taking another look at this at our Tokyo F2F this week. We're very sorry for the delay. We (the TAG) are working on improving our process to help better catch issues like this one that have fallen through the cracks.

As currently drafted, it would be very easy for spec readers to miss the fact that there isn't consensus on this approach. There's an issue marker to that effect in the Introduction section, but people usually link to specific subsections or specific property definitions. When following such a link, the reader would have no idea that there's a fundamental disconnect in the WG on the design.

Please add other boxes like that one to other likely spec entry points, minimally to the definition of backdrop-root.

Hi @hober, thanks for the comment, and no problem on the delay. I just created a PR with two more issue markers. Let me know if that's what you were looking for.

Hi @hober, thanks for the comment, and no problem on the delay. I just created a PR with two more issue markers. Let me know if that's what you were looking for.

Yes, thank you.

Hi,

@alice, @dbaron, @plinss, and I looked at this today in our Cupertino F2F.

When @alice and I discussed this in our Reykjavík F2F, we filed w3ctag/meetings#31 "How do we balance concerns between interoperability and implementability?" to try to come up with guidance for cases like this. In a comment on that issue, Alice laid out several options for such situations, and concluded that the "best choice of these[...] will ultimately depend on and should be guided by the potential end-user impact, and then following the usual priority of constituencies."

Barring new developments that would make this moot, we think the best way forward at this point would be for the spec to define both models of backdrop filters, and to say that implementations MUST follow one or the other.

We're going to close this review; please file a new one if the situation or API changes significantly.