[filter-effects-2] Backdrop filters should not use BackgroundImage #53
Currently, the spec says "The first filter function or filter reference in the list takes the element's BackgroundImage as the input image."
This was a mistake on my part. BackgroundImage is defined as the backdrop up to the isolation parent.
What we really want is a new term, BackdropImage, which is the backdrop of the element, including all parents and siblings that have been painted up to the point of the filter. There is no isolation.
The text was updated successfully, but these errors were encountered:
Is there going to be a BackdropAlpha or any other way to interpret the backdrop? If not, I think "backdrop" is both shorter and less likely to be confused with CSS background images.
But while we're on the subject:
Why no isolation? How would this interact with mix-blend-modes in general?
What do you mean "parents and sibling that have been painted"? Is that, after proper re-ordering for z-index, or only previous DOM siblings?
How do you determine which section of the backdrop is affected by the filter? Is it clipped to the current element's content/border/margin-box? Is it masked by the current element's painted alpha channel?
Many great questions!
It's not that it isn't isolated, just that the backdrop isn't clamped at the isolation root.
The mix-blend-mode affects how this element is then composited. So it is effectively rendered offscreen and then blended. Backdrop filters won't change that.
I meant in paint order, not DOM order. I just couldn't think of an existing term for that.
The way backdrop filter works is that you do a separate rendering pass just for the backdrop. This is why it is expensive.
At the moment it is the border box. It isn't masked by the element's painted alpha. Maybe we'll need an option to do that for SVG elements.
Can you say more about why you chose to make backdrop filter not respect isolation? I had always assumed they respected isolation (i.e. just operated on the implied intermediate surface of the nearest stacking context, the way blend modes do), and was quite surprised when I played with them in Safari a few weeks ago and found out that this was not the case. I also noticed very inconsistent behavior, see below. Do you have scenarios in mind where respecting isolation would impose unnecessary limitations on what authors could do?
If you're inside a stacking context and render a backdrop filter, does the separate rendering pass include the contents of the current stacking context up to the current element? This testcase shows rather contradictory behavior in Safari:
<div style="height: 200px; opacity: 0.5; background: black;"> <div style="height: 100px; -webkit-backdrop-filter: opacity(1);"></div> </div>
On initial load, I just get a 200px high gray box (i.e. white + 50% black). If I then use the Web Inspector to change
@grorg This issue definitely needs clarification before we can agree to implementing backdrop-filter in Firefox.
In particular, it needs to be clear how the testcase in #53 (comment) should behave.
There are strong parallels to
I created a test case. For what it's worth, the Chrome implementation respects isolation. (On the other hand, the Chrome implementation *doesn't respect border-radius, which is another thing not well defined in the spec.)
Screenshots (the element with the green border has isolation, the circles on the left are using an invert backdrop filter; the circles on the right are using a difference blend mode):
One of the weird side effects of Safari's implementation (and the original reason I built the test) is how a an element with blend mode can "escape" isolation by blending in with a sibling that has a backdrop filter: that overlap section is created from the blend mode inverting the colors on its sibling, which include the inverted colors from the body background.
I understand that it sounds strange but isolation rules are still met for blending. The one is independent of the other.
As @grorg says, we need a new term to describe this behavior.
It would be interesting to see if Safari runs into issues where it normally would create a compositing layer. So if the group would have an animation of the
See discussion in previous comment. Ran 2 different tests:
2D tranform animation
This actually makes sense. Even when split into compositing layers, the implementation still has access to the different "raster images"/compositing layers and can composite those for the backdrop blur filter. At least when you implement backdrop-blur in the paint pipeline you have.
3D transform animation with perspective
The question is:
And extended question:
@grorg, this definitely needs a few clarifications before we can get it shipped in Chrome. The main sticking point is whether
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
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.
Another issue with defining
Please see this example for this effect possibly happening, in Box 3. I’ve included screenshots from Chrome, Safari, and Edge below. In Chrome, all three boxes seem to have the right amount of blur and opacity applied. (Don’t worry, there are plenty of other bugs in Chrome’s backdrop-filter, just not here.) In Safari, Box 3 looks like it is at 0.25 opacity - double-counted. And incidentally, Box 1 also shows another bug (I believe) in Safari. It has a background color, which seems to turn off the backdrop-filter entirely. On Edge, I’m not sure what is happening. The edges of the red box are crisp all the way around, so perhaps the red background is being repainted on top of the blur? Or maybe some form of opacity double-counting here too?
Just to make the point again - having backdrop-filter respect isolation should lead to fewer bugs, and a less confusing experience for developers.
I think it's most important that this will work the same way it does in Safari. In my opinion, it would be more confusing for developers if it didn't work the same everywhere. Do note that the same effect is present in iOS, where it does work similarly to the way it works in Safari (if not exactly the same way).
I really do think that the backdrop should include everything behind an element, as it's supposed to be a filter that can be put on top of anything (and filter anything behind it). If it doesn't work this way, it won't look good in countless situations.
@Benimation, I definitely agree that we need to clarify the standard and then make sure the behavior is the same on all browsers.
Can you give an example of the effect "not looking good" with backdrop filter stopping at the parent stacking context? It would be helpful to see what the limitations would actually be.
The CSS Working Group just discussed
The full IRC log of that discussion<gregwhitworth> Topic: backdrop-filter
<Rossen> github: https://github.com//issues/53
<gregwhitworth> chrishtr: for reasons of implementation complexity, number 1 and avoiding situations developers would find confusing
<gregwhitworth> chrishtr: I want backdrop-filter to only apply to containing isolated group, which in spec terms is the background image of the group
<gregwhitworth> chrishtr: takes the group - applies filter and then clips and paint behind it and then paint on top
<gregwhitworth> chrishtr: issue 53, was originally filed to change the spec to not image but all the images from the root
<gregwhitworth> chrishtr: the prefixed impl that Safari has that draws everything up to the root - and unprefixed version in Edge also has that
<gregwhitworth> chrishtr: the reason I prefer it to the isolated group is because it's easier to implement and more performant
<gregwhitworth> chrishtr: whereas if you draw all the way up to the root we'll need to implement a new algo
<gregwhitworth> chrishtr: if you go to an isolated group that is above the containing isolated group you may have to take into account other graphical effects into account with filters that move pixels, etc
<gregwhitworth> chrishtr: this inreases complexity a lot
<gregwhitworth> chrishtr: this makes it complicated for developers - there are a few scenarios in the issue
<gregwhitworth> chrishtr: there's an element with backdrop-filter, somewhere in the ancestor an alement has opacity but it isn't in the isolated group but that opacity must be included - so you're getting doulbe opacity
<gregwhitworth> krit: I have to agree that opacity is indeed strange, did you do testing on Edge/Safari
<gregwhitworth> chrishtr: yes, there are screenshots in the issue and they do double opacity
<gregwhitworth> krit: I think there is developer desire to do it on the entire section, not just the isolated group
<gregwhitworth> mstange: can you mention a case that would be impossible?
<gregwhitworth> krit: when you do an animation that has a filter on it
<gregwhitworth> krit: there wouldn't be any backdrop filter on it since it's animating
<gregwhitworth> mstange: that sounds like an animation issue
<gregwhitworth> mstange: that sounds like an ordering issue
<gregwhitworth> mstange: I agree with chrishtr that it would be easier to implement and be more predictable for authors
<gregwhitworth> krit: how does it work more consisted with mix-blend-modes?
<gregwhitworth> krit: you have two divs on top of each other, the second would be an isolation group - you would blend them together
<gregwhitworth> chrishtr: mix blend mode and isolation groups are not always the same
<gregwhitworth> mstange: I'm interested in seeing scenarios in which I'm wrong
<gregwhitworth> krit: or maybe I'm missing some
<gregwhitworth> ... looking at codepen
<gregwhitworth> Simon: as I understand anything that creates a stacking context creates an isolation group
<gregwhitworth> Simon that is contrary to the point of backdrop-filter which should apply to everything behind you
<gregwhitworth> chrishtr: yeah
<gregwhitworth> chrishtr: I think this needs more discussion offline
<gregwhitworth> Rossen: ok, thank you chrishtr
<krit> mstange: https://dbaron.org/log/20130306-compositing-blending
If that is fixed then the codepen shows that indeed mix-blend-mode only mixes with the containing isolated group, not all the way to the root.
So the semantics of backdrop-filter that @mfreed7 is proposing are consistent with mix-blend-mode.
I just wanted to quickly add a comment about the limitations of stopping backdrop-filter at an isolation boundary. It seems like there may be some misconception about how that limits what gets filtered. Please see this jsbin, which shows a dialog element floating over the top of (and filtering) all other elements on the page. The dialog is first in the DOM hierarchy, and the other elements include several nested stacking contexts. The point is that the stacking context limitation only applies if the backdrop-filtered element itself is nested inside a stacking context for some reason. As long as it sits outside, everything behind it on the page, including other stacking contexts, gets filtered. See also, https://www.apple.com - they use exactly this DOM structure for the nav bar at the top. I'd be very interested to see examples where the backdrop filtered element needs to be inside a stacking context for some reason - i.e. what type of effect isn't possible with the proposed isolation behavior?
To see how people are using backdrop-filter today, I did some research using HTTP Archive and Chrome Platform Stats. The current usage rate for backdrop-filter (unprefixed) is very low, about 0.0003%. That number does not include prefixed (-webkit-backdrop-filter) usage, so I used HTTP Archive to pull all pages that use backdrop-filter. Of those, about half use only the prefixed version, so the actual usage rate might be higher by 2-5X, which is still quite small. Another analysis based on summed Alexa ranks for each page results in a factor of about 3x. In all cases, the existing usage is quite small.
I also looked at the pages themselves that currently make use of backdrop-filter. I was only able to locate two high-ranking sites that have a visible element styled with backdrop-filter. One is Apple, and the other is the Github Blog. Both use nearly the same DOM structure, as I mentioned above: an element nested directly within the
We are still curious what effects would be difficult to achieve, if backdrop-filter were specified to respect isolation boundaries. Input appreciated!
I took a closer look at the example from #53 (comment) and found a potential problem with making
In Chrome, it seems that the opacity on the element does not reduce the opacity of what's rendered by backdrop-filter on that element; the blur in the example fully blocks out the non-blurred element underneath. In Safari, the blurred backdrop is only rendered at 0.1 opacity. I think Safari's behavior makes more sense here.
However, if we want to adopt Safari's behavior for this case, in terms of the compositing effect graph, I think this requires rendering the backdrop filter inside the opacity, if opacity and backdrop-filter are applied to the same element. But if the backdrop filter rendering goes inside of the opacity, then we have the same problem as in this issue: Opacity is an isolation boundary, so backdrop-filter on such an element would not have any effect. @mfreed7, any ideas for how we should solve this case?
Instagram uses it for their "please log in" banner when you follow a link directly to a photo page. It's nested many divs deep & some of those divs use
@AmeliaBR, thanks for the comment, I hadn't noticed the Instagram photo page in my search. The numbers I quoted were for any document containing "backdrop-filter", including CSS or embedded style within an HTML. The platform stats numbers are counted any time the feature is actually used, e.g. when the pop-up pops up. So I think my numbers are still good; correct me if I'm wrong. My subsequent hand-analysis was to just use document.querySelectorAll() for the selector containing backdrop-filter and see what comes back, and it is definitely possible I missed some cases there. Again, thanks for the pointer to Instagram. From the sound of it, though, the Instagram banner would filter everything on the page, given that its parent stacking context is the root element. I am assuming none of the position:relative parents use z-index. Let me know if you disagree. (And if you could post a link directly to a photo from Instagram, that'd be helpful too.)
@mstange, thanks also for the comment about mixing opacity and backdrop-filter. It is definitely an interesting question, though I don't think it actually affects the isolation question. It does call into question the order-of-operations for backdrop-filter. We are debating it now, and I'll have a more detailed response soon.
@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:
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
@mstange, we were discussing your comment above concerning opacity. There are several examples where it would make sense for the filtered backdrop to form the starting point for the backdrop-filtered element, so that opacity (and other filters) would apply to that filtered content. One example would be a dialog box that “fades out”. Given that this change should not cause any performance issues, I’ve modified our proposed definition for backdrop-filter. I also included more detail about transforms applied to the backdrop-filtered element, to clarify those as well. Your feedback is appreciated:
Again, we believe that having backdrop-filter only apply up to the parent stacking context makes sense for these reasons:
In trying to demonstrate what we see as a fundamental problem with allowing backdrop-filter to filter everything that comes before it, we created this example page. This page did not behave as we (or anyone?) would have expected, when loaded within Safari, which filters everything behind the element. I have included screenshots from Chrome and Safari below.
This example contains a parent element (the big one containing the text) that has an invert filter applied, so it shows up as black background with white text. The "dialog" element is a child of that inverted element, so it should inherit the invert filter. So our expectation was that the already-inverted backdrop of the dialog would be used as the starting background for the dialog element, then the remainder of the dialog would be rendered (e.g. the blue border) and then the entire thing would be inverted again, because of the inherited filter. That should result in the text within the dialog going back to white background with black text, and a yellow, inverted border. What happened instead is some strange mix of the two. Only one invert was applied, as the text inside the box is still white on black background (inverted only once). The borders did get inverted, because they're yellow. And even more confusing, the background outside the text region is also inverted to black background and white text. So the right half of this dialog is inverting the background, and the left half is not. And this is all interesting, because naively, we expected almost exactly the opposite. It is this confusion that we are concerned about, in general. It will lead to differences in implementation, and general confusion among developers. Keep in mind - the point here isn’t that there is a bug in this particular implementation. The point is that it is very difficult to define what “correct” means, when filtering passes beyond an element with effects applied.
The most common argument we've heard against making backdrop-filter respect stacking context isolation boundaries is that it is too restrictive. Particularly when the stacking context is created by an operation that shouldn't cause any real problems for backdrop-filter, such as 2D transforms and fixed position elements. These are definitely valid points. We still believe (strongly) that there are fundamental problems with having backdrop-filter "see" above an element with effects applied, however. To attempt to relax some of the constraints of stacking contexts, while still retaining the needed boundaries for effects, we have defined a new concept, which we're very tentatively calling the Backdrop Root. Please see this document for a detailed explanation of both the solution and the problem, as we see it. Comments are very welcome - this is a draft idea.
I realize I'm a bit late to the party, but I'm really glad to see motion in the direction of a formal definition of "backdrop", and I think Mason's doc also does a great job of outlining possible problem scenarios that we should be able to iterate through and reach consensus on what should happen. I suspect everyone on the thread would agree that at minimum the root element should form the root of the backdrop, so then it's just the other bullets we'll need to agree on :)
I also share concerns about the restrictions surprising developers or blocking potentially valid usage, so I think it will be good to reason out why each of these scenarios can't be solved or alternatively how to overcome that challenge. I see some of this discussion in Mason's doc already - what would be the most productive way to open up discussion/iterate on each of these points? Maybe we can resolve to start by adding an initial formal definition of "backdrop" or "backdrop root" to the spec with minimal restrictions (just root element) and then open issues for each additional restriction we'd like to consider for discussion? Or just comment directly in Mason's doc and later try for a resolution on the full definition all at once? Or something else?
A final couple thoughts:
We would like to publish a proposal for spec changes for backdrop-filter. It includes many of the ideas discussed on this issue, plus a lot of extra background and motivation for the changes. I have created a PR for the fxtf-drafts repo, and I've included the rendered spec output here:
We would love to hear comments on this proposal.
@ChumpChief, thanks for your comments. In our proposed spec, I've included a lot of detail in the "Motivation" section. In particular, I added a rationale for each of the restrictions included in the definition of the Backdrop Root. Hopefully that's a good starting point for the discussion!
Good question, @AmeliaBR. Only one browser currently ships backdrop-filter: Edge. Webkit has a prefixed version, and Mozilla and Chromium don't have a shipped backdrop-filter implementation.
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.
Now, to my main objection: The creation of a containing block for the backdrop root. Quoting from the proposed text:
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:
<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
I realize that this point was brought up in November by @chrishtr on this issue.
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
Would it be possible to extend
This would address the authoring issue (authors often expect the backdrop filter to filter everything behind the element, but maybe they also expect isolation to limit it if they're using blending or opacity). But it could be more complicated for implementers, as they would need to implement both behaviors, both for backdrop filtering and for blend modes.
Edit: Whoops, missed the comment about this above: #53 (comment)
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: Backdrop Filters
<fantasai> chrishtr: Backdrop filters was discussed last year at F2Fs and at tpac, and the concerns raised were all about efficient implementaility and clear semantics
<fantasai> chrishtr: In aprticular cases having to do with whatppanes if there are filters above backdrop filter element
<fantasai> chrishtr: Did a bunch of research on explicit examples
<fantasai> chrishtr: looking for undesired behaviors
<astearns> github: https://github.com//issues/53#issuecomment-451599995
<fantasai> chrishtr: Also researched use case that are considered important
<fantasai> chrishtr: Number of uses cases involving rtransforms, for example, the folks at Apple, smfr et al. mentioned wnating to use transforms to rotate something inside an overlay of a video element
<fantasai> chrishtr: So don't want backdrop filter to stop at the transform
<fantasai> chrishtr: New proposal that avoids strange behavior of filters and opacity
<fantasai> chrishtr: And problems of not applying atomically
<fantasai> chrishtr:while also supporting stacking context without visual effects
<fantasai> chrishtr: or stacking contexts that should be able to with more clever code support in compositing systems
<fantasai> chrishtr: ...
<fantasai> chrishtr: backdrop filter root would only be applied for elements with filters
<fantasai> chrishtr: opacity
<fantasai> chrishtr: and masks and clip path and mix-blend-mode
<AmeliaBR> The proposal: https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html
<fantasai> chrishtr: and in our proposal a border ardius clip
<fantasai> chrishtr: got general positive feedback from experts form MSFT
<fantasai> chrishtr: and also some feedback from Markus from Mozilla
<fantasai> chrishtr: Markus raised some concerns, Mason and I were whiteboarding to solve
<fantasai> chrishtr: Feedback was browers have a lot of complexity around how containing blocks and DOM parentage don't agree
<fantasai> chrishtr: Browsers in effect have to push clips, particularly background corner clipis, and apply them non-atopically
<fantasai> chrishtr: can have undesired bleeding and fringes around rounded corners
<fantasai> chrishtr: we thought it through and agreed that's the case, and agree that it shouldn't be necessary to require backdrop root for rounded corner clips
<fantasai> chrishtr: second concern was that current spec proposal, there's an action at a distance going on
<fantasai> chrishtr: If you put background filter on an element, the background filter root implied by that element becomes a containing block for all of its descendants
<fantasai> fantasai: including fixedpos items?
<fantasai> chrishtr: Yes
<florian> fantasai: this seems a little extreme
<fantasai> fantasai: that seems really extreme
<fantasai> smfr: That's the same as filters?
<fantasai> chrishtr: That has to do with excessive difficulty of composititng
<fantasai> chrishtr: Under same rationale under roposal
<florian> fantasai: hang on, what?
<fantasai> chrishtr^: This creates situation where a descendant can change behavior of the parent
<fantasai> chrishtr: Let's suppose you have an element with opacity on it, and then you have a descendant with a backdrop filter
<fantasai> chrishtr: Element with the opacity is the backdrop filter root on that other element
<fantasai> chrishtr: under this proposal, the backdrop filter root becomes a contianing block for all descendants
<fantasai> chrishtr: That means presence of a property on a descendant has side effecct of making some ancestor that has opacity on it ecome a containing block
<florian> fantasai: that's really bad
<fantasai> chrishtr: This avoids the complexity of the problems of mismatch beteween conianing block and dom order
<fantasai> chrishtr: Because the content underneath the backdrop filter root that paints before the backdrop filter element is stuff that needs to be drawn into an image behid the element
<fantasai> chrishtr: that's the point of the feature
<fantasai> chrishtr: We concluded that Markus is right htat we don't need this so we cna remove it from the spec proposal
<fantasai> AmeliaBR: You've obsoleted my question by removing this
<fantasai> AmeliaBR: what are you replacing it with?
<fantasai> chrishtr: There will still be a backdrop root
<fantasai> chrishtr: Everything here except the border radius would be a backdrop root?
<fantasai> AmeliaBR: Are these all things that create a conaining block?
<fantasai> chrishtr: no, opacity doesn't create a containing block
<fantasai> chrishtr: in certian stiuations you'll be able to see a fringing effet
<fantasai> chrishtr: Way opacity is implemented, browsers commute with clip
<fantasai> chrishtr: we push the clips down below the opacity
<fantasai> chrishtr: multiple clips that can occur
<fantasai> chrishtr: can even have mutliple mask textures happening
<fantasai> chrishtr: these clips are not necessarily atomic. Opacity is atomic but others aren't
<fantasai> chrishtr: you might see certian effets at the corners
<fantasai> chrishtr: We have no choice but to push down the clip because of opacity vs clip
<fantasai> chrishtr: because clip is applied before the blur filter, someof the colors of pixesl that were outside the clip will no longer appear in the output
<fantasai> AmeliaBR: My general comment is that I don't like having yet another category of properties that cause a special behavior
<fantasai> AmeliaBR: we already have stacking contexts and containing blocks and isolation and certian properties affect one but not the other
<fantasai> AmeliaBR: if anyone wants to make a table which propertis trigger which behaviors?
<fantasai> dbaron: I did that!
<fantasai> dbaron: My table came with tests, and I filed a bunch of bugs with it
<fantasai> dbaron: Some of the bugs are just described at the bottom of the table
<fantasai> dbaron: not necessarily all filed...
<fantasai> chrishtr: Table was great!
<fantasai> AmeliaBR: If we can make sense to synchronize one of the existing definitions, would be great
<fantasai> AmeliaBR: Otherwise need to be really clear with authors why differences
<fantasai> AmeliaBR: With transform-style and 3D, authors got really annoyed when some browsers triggered flattinging on opacity and others didn't
<fantasai> chrishtr: Things that trigger flatting are almost the same as this list
<fantasai> AmeliaBR: If we can sync the lists that'd be very helpful
<fantasai> chrishtr: Transforms spec has a lot of compat restrictions. Open question of can we move the Web to that model without breaking things.
<fantasai> chrishtr: Could have a common name for htis
<fantasai> chrishtr: new concept
<dbaron> (and the above table is actually a *test* and will produce different results in different browsers)
<fantasai> chrishtr: When mix-blend-mode was specified, the final decision was to make it only to the conaining stacking context
<fantasai> chrishtr: I think that was chosen because it doesn't introduce a new concept
<fantasai> chrishtr: but there's been rightly some concern that this make the feature not as expressive as it could be
<fantasai> chrishtr: Apple engineers had this position
<fantasai> chrishtr: So we could maybe even change mix-blend-mode to match this and make it better than today
<fantasai> astearns: So you are concerned about introducing notion of backround root?
<fantasai> AmeliaBR: Just concerned that it's similar but slightly different from other concerns
<fantasai> AmeliaBR: If we can sysnc them, that woudl be great.
<fantasai> chrishtr: Wrt your comment about isolation, yeah, isolation: isolate creates a stacking context, not a contianing block. Maybe a different hting could do that.
<fantasai> AmeliaBR: Another thing is that contain: layout does almost the same thing
<fantasai> AmeliaBR: It creates stacking context, conatining block, etc. Maybe that property suffices
<fantasai> s/Amelia/christr/ x2
<fantasai> smfr: ...
<fantasai> smfr: Backdrop was always intended to be everyting under the element all the way up to the root
<fantasai> smfr: There are some issues with ancestors, but I think that's what the author want.s
<fantasai> dino: it also means they don't have to tweak their content to do what they want to do
<fantasai> dino: It's not difficult in our impl
<fantasai> dino: We do need to fix up to define edge cases like ...
<fantasai> dino: It's a shame that it's inefficient in some engines. It's not in ours.
<fantasai> dino: Want to build on what smfr says. Backdrop this way will require authors to change how their content works.
<fantasai> dino: We definitely have bugs in the webkit implementation that we should fix
<fantasai> chrishtr: I can't say I really agree with that.
<fantasai> chrishtr: This is just something that developers can know about. We can describe succintly
<fantasai> TabAtkins: We've had examples of things being double-filtered or otherwise being weird.
<fantasai> TabAtkins: Safaris' definition is just "whatever CoreGraphics does"
<fantasai> TabAtkins: That's not well-enough defined. We don't even know what it does.
<fantasai> smfr: I volunteer Dean to write that up.
<fantasai> Markus: I mostly agree with Chris.
<fantasai> Markus: I think Safari's current behavior is confusing and hard to define what should be the outcome with opacity effets.
<fantasai> Markus: I don't agree that authors will have to change their content
<fantasai> Markus: I think usually there will not be filters on the ancestor of the element with the backdrop filter
<fantasai> Markus: Have yet to see a case where Google's proposal imposes a limitation
<fantasai> dino: we do have example of backdrop filters and opacity on the ancestor
<fantasai> dino: Every video on iOS does this.
<fantasai> dino: The play button on videos fades in and out
<fantasai> dino: It works fine
<fantasai> dino: I we implement this new backdrop root, then have to fix that.
<fantasai> Markus: So opacity is on a different elent than the backdrop filter?
<fantasai> dino: yes
<fantasai> dino: Controls might have things that you don't wnat backdrop filters on, such as subtitles.
<fantasai> dino: With video and controls, have conmplicated structure under the video
<fantasai> dino: Sometimes things have backdrop filter, some don't; some things fade in/out, others don't.
<fantasai> dino: To Google's credit, they figured out how to do this, but it is a change.
<fantasai> dino: I agree that we haven't specced i well enough.
<fantasai> dino: I volunteer smfr to write it up
<fantasai> dino: It's up to us to define exactly what we've implemented.
<fantasai> dino: Will cause us to understand our bugs and fix them too
<fantasai> dino: And we can better analyze what Google has come up with so far
<fantasai> dino: Wrt efficiency, actually on mobile devices implementing it Apple's way might be more efficient based on the way mobile GPUs work.
<fantasai> dino: Also we thought about how wWebKit would implement Google proposal
<fantasai> dino: would have to clear away whatever's under the elemnet
<fantasai> dino: [gives an example]
<fantasai> astearns: ...
<fantasai> dino: Don't want to block work on the proposal. It's up to Apple to provide more info and counter-proposals.
<fantasai> dino: We object in the sense that we don't think it's the right thing to do, but not in the sense that we will fight you on the beaches.
<fantasai> astearns: We have a resolution on having backdrop-filter in general, right?
<fantasai> chrishtr: So we need a resolution to put this into the draft.
<fantasai> dino: The core difference in the proposal is adding backdrop-proposal. The core difference is where do you take the backdrop from.
<fantasai> chrishtr: In terms of web compat, this should be quite compatible. We did research finding no examples; didn't find the iOS example
<fantasai> chrishtr: Also Safari's implementation is prefixed. Edge's is not, but that will be Blinkified
<fantasai> chrishtr: With all that we propose to resolve on this?
<fantasai> astearns: So proposal is to add the backdrop-root proposal to the draft minus the rounded corners
<fantasai> chrishtr: and minus the part about backdrop-root causing containg block
<fantasai> fantasai: What are we doing?
<fantasai> chrishtr: We have a backdrop-filter property in the spec, we are adding concept of backdrop root
<AmeliaBR> Current spec definition: https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty
<fantasai> chrishtr: What I'd like to resolve on is that we define a backdrop root to be according to the thing on the screen minus the part about rounded corners and minus the part about backdrop-filter createing a containing block
<AmeliaBR> New section (plus other edits): https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html#BackdropFilterProperty
<fantasai> chrishtr: When a backdrop-filter is present, it means tha tyou draw all content underneath its containign backdrop root into an image buffer and the filters apply to that
<fantasai> chrishtr: and it's drawn underneath the backdrop filter element clipped to its rounded border rect
<fantasai> chrishtr: That clarification about rounded border rect is also a clarification
<fantasai> Markus: Also defines order of operations wrt opacity, wasn't defiend before
<fantasai> astearns: So by putting this into the draft, that becomes the place we discuss whether this is how we do it or whether there's an alternative proposal
<fantasai> dino: Add an issue describing this
<fantasai> hober: We're OK adding it to the spec provided there's an issue noted in the spec describing that this is still under discussion
<fantasai> astearns: So we're not waiting on Apple to have an explanation of CoreGraphics, but here's our current proosal and an issue saying it's still under discussion to maybe make more like Safari
<hober> s/this is still under discussion/there is no consensus on having such a property/
<fantasai> [discussion of how to make an issue note in the spec]
<florian> fantasai: we file issues in the tracker generally, but also sometimes we mark it in the spec, possibly with a link to a gihub issue, to warn the reader about the existing discussion, disagreement, etc,
<fantasai> astearns: Any objections to adding to spec with issue marker?
<fantasai> RESOLVED: Add the proposal with an issue
<fantasai> s/issue/issue noted in the spec/
I have updated my pull request per the discussion just now:
Link is (still) here: https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> Topic: backdrop filter disagreement
<TabAtkins> dbaron: My understanding is that there's disagreement between WK and Blink about how b-f should work
<TabAtkins> dbaron: previous state is that spec is kinda vague
<TabAtkins> dbaron: Current state is that blink engineers wrote a new spec that reflects their engine, and WK disagrees with this.
<TabAtkins> dbaron: a) if would be good to solve this to get with interop
<astearns> github: https://github.com//issues/53
<TabAtkins> dbaron: b) we have a summer intern that should work on this
<TabAtkins> dbaron: If this is a viable project we need to tell this intern what to do
<TabAtkins> dbaron: I think part of teh problem is that we don't necessarily have the righ tpeople in the room
<fantasai> TabAtkins: Sounds like our objection is based on our technical architecture
<fantasai> TabAtkins: WebKit's is based on their technical architecture
<TabAtkins> mstange: I agree with Chrome's proposal entirely; there were some objections, they got addressed
<TabAtkins> mstange: Chrome's proposal is easier to implement and make smore sense to authors imo
<fantasai> TabAtkins^: y'all presumably also have a preference based on your technical architecture?
<TabAtkins> mstange: Other resolution from last time is that if Apple wants their impl in spec they have to write up how that works
<TabAtkins> hober: As far as I understand, Dino still has that action.
<fantasai> TabAtkins: Given questions we had on "how does it work" were "we're not sure"
<fantasai> TabAtkins: I can't in good conscience accept their proposal
<fantasai> TabAtkins: Right now we have a choice between "here's an explicit algorithm" and "we haven't described this yet"
<TabAtkins> dbaron: Having seen some of the discussion...
<TabAtkins> dbaron: I think WK was arguing their stuff is betteer fo rusers
<TabAtkins> dbaron: I think I'm sympathetic to that, looking at examples, but it does require details of how it acutally works
<TabAtkins> mstange: Stil important questions, like does it punch thru group opacity, etc
<TabAtkins> mstange: So in examples where you have opacity but not group opacity, those are simpler cases.
<TabAtkins> mstange: So putting in a special case into the spec that lets you punch thru opacity when it's not acting as group opacity, that's tricky. And letting it punch thru when it *is* group opacity, that's hard to predict.
<TabAtkins> AmeliaBR: So all we can resolve right now is that we need a clear description...?
<TabAtkins> Rossen_: That's where we left it last time.
<TabAtkins> dbaron: And Apple engineers should be aware that if they don't give details, we're probably defaulting to Chrome's implementation.
<TabAtkins> myles_: The technical burden of altering Core Animation to support Chirome's behavior is on the sam eorder of magnitude of altering CHrome's compositor to support our behavior.
<AmeliaBR> s/.../ of the disagreements between the implementations/
<TabAtkins> iank_: Par tof our reason for our architectur eis because we care about very low-end memory gpu classes
<TabAtkins> dbaron: So that's about it.
Thanks @mstange. I think I understand what you're going for on the opacity comment - basically, you're saying that "filtering everything" will require special rules for what to do in the myriad nesting cases for opacity (and also filters). Unless the spec is basically "just put something on the screen there, I don't care what it is", it'll be tough to spec, I suspect.
Yeah, the core idea is that unless/until WK actually describes their behavior, which they were tasked with doing at the last meeting, we're going with the current spec (Chrome) behavior. And if they don't do that reasonably quickly, Firefox will likely follow the spec, and begin fully locking in that behavior.
The compat issue against changing
Connecting that back to
@mfreed7 yeah, there could be content that will suddenly look different. I'm unsure if this could be detected by a use counter; it could be too costly to calculate.
@AmeliaBR in one of the previous versions of the spec, we had the