- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Feb 2019 19:37:21 +0000
- To: public-fxtf-archive@w3.org
The CSS Working Group just discussed `Backdrop Filters`, and agreed to the following: * `RESOLVED: Add the proposal with an issue` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Backdrop Filters<br> <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<br> <fantasai> chrishtr: In aprticular cases having to do with whatppanes if there are filters above backdrop filter element<br> <fantasai> chrishtr: Did a bunch of research on explicit examples<br> <fantasai> chrishtr: looking for undesired behaviors<br> <astearns> github: https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-451599995<br> <fantasai> chrishtr: Also researched use case that are considered important<br> <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<br> <fantasai> chrishtr: So don't want backdrop filter to stop at the transform<br> <fantasai> chrishtr: New proposal that avoids strange behavior of filters and opacity<br> <fantasai> chrishtr: And problems of not applying atomically<br> <fantasai> chrishtr:while also supporting stacking context without visual effects<br> <fantasai> chrishtr: or stacking contexts that should be able to with more clever code support in compositing systems<br> <fantasai> chrishtr: ...<br> <fantasai> chrishtr: backdrop filter root would only be applied for elements with filters<br> <fantasai> chrishtr: opacity<br> <fantasai> chrishtr: and masks and clip path and mix-blend-mode<br> <AmeliaBR> The proposal: https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html<br> <fantasai> chrishtr: and in our proposal a border ardius clip<br> <fantasai> chrishtr: got general positive feedback from experts form MSFT<br> <fantasai> chrishtr: and also some feedback from Markus from Mozilla<br> <fantasai> chrishtr: Markus raised some concerns, Mason and I were whiteboarding to solve<br> <fantasai> chrishtr: Feedback was browers have a lot of complexity around how containing blocks and DOM parentage don't agree<br> <fantasai> chrishtr: Browsers in effect have to push clips, particularly background corner clipis, and apply them non-atopically<br> <fantasai> chrishtr: can have undesired bleeding and fringes around rounded corners<br> <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<br> <fantasai> chrishtr: second concern was that current spec proposal, there's an action at a distance going on<br> <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<br> <fantasai> fantasai: including fixedpos items?<br> <fantasai> chrishtr: Yes<br> <florian> fantasai: this seems a little extreme<br> <fantasai> fantasai: that seems really extreme<br> <fantasai> smfr: That's the same as filters?<br> <fantasai> chrishtr: That has to do with excessive difficulty of composititng<br> <fantasai> chrishtr: Under same rationale under roposal<br> <florian> fantasai: hang on, what?<br> <fantasai> chrishtr^: This creates situation where a descendant can change behavior of the parent<br> <fantasai> chrishtr: Let's suppose you have an element with opacity on it, and then you have a descendant with a backdrop filter<br> <fantasai> chrishtr: Element with the opacity is the backdrop filter root on that other element<br> <fantasai> chrishtr: under this proposal, the backdrop filter root becomes a contianing block for all descendants<br> <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<br> <florian> fantasai: that's really bad<br> <fantasai> chrishtr: This avoids the complexity of the problems of mismatch beteween conianing block and dom order<br> <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<br> <fantasai> chrishtr: that's the point of the feature<br> <fantasai> chrishtr: We concluded that Markus is right htat we don't need this so we cna remove it from the spec proposal<br> <fantasai> AmeliaBR: You've obsoleted my question by removing this<br> <fantasai> AmeliaBR: what are you replacing it with?<br> <fantasai> chrishtr: There will still be a backdrop root<br> <fantasai> chrishtr: Everything here except the border radius would be a backdrop root?<br> <fantasai> AmeliaBR: Are these all things that create a conaining block?<br> <fantasai> chrishtr: no, opacity doesn't create a containing block<br> <fantasai> chrishtr: in certian stiuations you'll be able to see a fringing effet<br> <fantasai> chrishtr: Way opacity is implemented, browsers commute with clip<br> <fantasai> chrishtr: we push the clips down below the opacity<br> <fantasai> chrishtr: multiple clips that can occur<br> <fantasai> chrishtr: can even have mutliple mask textures happening<br> <fantasai> chrishtr: these clips are not necessarily atomic. Opacity is atomic but others aren't<br> <fantasai> chrishtr: you might see certian effets at the corners<br> <fantasai> chrishtr: We have no choice but to push down the clip because of opacity vs clip<br> <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<br> <fantasai> AmeliaBR: My general comment is that I don't like having yet another category of properties that cause a special behavior<br> <fantasai> AmeliaBR: we already have stacking contexts and containing blocks and isolation and certian properties affect one but not the other<br> <fantasai> AmeliaBR: if anyone wants to make a table which propertis trigger which behaviors?<br> <fantasai> dbaron: I did that!<br> <fantasai> dbaron: My table came with tests, and I filed a bunch of bugs with it<br> <fantasai> dbaron: Some of the bugs are just described at the bottom of the table<br> <fantasai> dbaron: not necessarily all filed...<br> <fantasai> chrishtr: Table was great!<br> <dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order<br> <fantasai> AmeliaBR: If we can make sense to synchronize one of the existing definitions, would be great<br> <fantasai> AmeliaBR: Otherwise need to be really clear with authors why differences<br> <fantasai> AmeliaBR: With transform-style and 3D, authors got really annoyed when some browsers triggered flattinging on opacity and others didn't<br> <fantasai> chrishtr: Things that trigger flatting are almost the same as this list<br> <fantasai> AmeliaBR: If we can sync the lists that'd be very helpful<br> <fantasai> chrishtr: Transforms spec has a lot of compat restrictions. Open question of can we move the Web to that model without breaking things.<br> <fantasai> chrishtr: Could have a common name for htis<br> <fantasai> chrishtr: new concept<br> <dbaron> (and the above table is actually a *test* and will produce different results in different browsers)<br> <fantasai> chrishtr: When mix-blend-mode was specified, the final decision was to make it only to the conaining stacking context<br> <fantasai> chrishtr: I think that was chosen because it doesn't introduce a new concept<br> <fantasai> chrishtr: but there's been rightly some concern that this make the feature not as expressive as it could be<br> <fantasai> chrishtr: Apple engineers had this position<br> <fantasai> chrishtr: So we could maybe even change mix-blend-mode to match this and make it better than today<br> <fantasai> astearns: So you are concerned about introducing notion of backround root?<br> <fantasai> AmeliaBR: Just concerned that it's similar but slightly different from other concerns<br> <fantasai> AmeliaBR: If we can sysnc them, that woudl be great.<br> <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.<br> <fantasai> AmeliaBR: Another thing is that contain: layout does almost the same thing<br> <fantasai> AmeliaBR: It creates stacking context, conatining block, etc. Maybe that property suffices<br> <fantasai> s/Amelia/christr/ x2<br> <fantasai> smfr: ...<br> <fantasai> smfr: Backdrop was always intended to be everyting under the element all the way up to the root<br> <fantasai> smfr: There are some issues with ancestors, but I think that's what the author want.s<br> <fantasai> dino: it also means they don't have to tweak their content to do what they want to do<br> <fantasai> dino: It's not difficult in our impl<br> <fantasai> dino: We do need to fix up to define edge cases like ...<br> <fantasai> dino: It's a shame that it's inefficient in some engines. It's not in ours.<br> <fantasai> dino: Want to build on what smfr says. Backdrop this way will require authors to change how their content works.<br> <fantasai> dino: We definitely have bugs in the webkit implementation that we should fix<br> <fantasai> q+<br> <fantasai> chrishtr: I can't say I really agree with that.<br> <fantasai> chrishtr: This is just something that developers can know about. We can describe succintly<br> <fantasai> TabAtkins: We've had examples of things being double-filtered or otherwise being weird.<br> <fantasai> TabAtkins: Safaris' definition is just "whatever CoreGraphics does"<br> <fantasai> TabAtkins: That's not well-enough defined. We don't even know what it does.<br> <fantasai> smfr: I volunteer Dean to write that up.<br> <fantasai> Markus: I mostly agree with Chris.<br> <fantasai> Markus: I think Safari's current behavior is confusing and hard to define what should be the outcome with opacity effets.<br> <fantasai> Markus: I don't agree that authors will have to change their content<br> <fantasai> Markus: I think usually there will not be filters on the ancestor of the element with the backdrop filter<br> <fantasai> Markus: Have yet to see a case where Google's proposal imposes a limitation<br> <fantasai> dino: we do have example of backdrop filters and opacity on the ancestor<br> <fantasai> dino: Every video on iOS does this.<br> <fantasai> dino: The play button on videos fades in and out<br> <fantasai> dino: It works fine<br> <fantasai> dino: I we implement this new backdrop root, then have to fix that.<br> <fantasai> Markus: So opacity is on a different elent than the backdrop filter?<br> <fantasai> dino: yes<br> <fantasai> dino: Controls might have things that you don't wnat backdrop filters on, such as subtitles.<br> <fantasai> dino: With video and controls, have conmplicated structure under the video<br> <fantasai> dino: Sometimes things have backdrop filter, some don't; some things fade in/out, others don't.<br> <fantasai> dino: To Google's credit, they figured out how to do this, but it is a change.<br> <fantasai> dino: I agree that we haven't specced i well enough.<br> <fantasai> dino: I volunteer smfr to write it up<br> <fantasai> dino: It's up to us to define exactly what we've implemented.<br> <fantasai> dino: Will cause us to understand our bugs and fix them too<br> <fantasai> dino: And we can better analyze what Google has come up with so far<br> <fantasai> dino: Wrt efficiency, actually on mobile devices implementing it Apple's way might be more efficient based on the way mobile GPUs work.<br> <fantasai> dino: Also we thought about how wWebKit would implement Google proposal<br> <fantasai> dino: would have to clear away whatever's under the elemnet<br> <fantasai> dino: [gives an example]<br> <fantasai> astearns: ...<br> <fantasai> dino: Don't want to block work on the proposal. It's up to Apple to provide more info and counter-proposals.<br> <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.<br> <fantasai> astearns: We have a resolution on having backdrop-filter in general, right?<br> <fantasai> chrishtr: So we need a resolution to put this into the draft.<br> <fantasai> s/so//<br> <fantasai> dino: The core difference in the proposal is adding backdrop-proposal. The core difference is where do you take the backdrop from.<br> <fantasai> chrishtr: In terms of web compat, this should be quite compatible. We did research finding no examples; didn't find the iOS example<br> <fantasai> chrishtr: Also Safari's implementation is prefixed. Edge's is not, but that will be Blinkified<br> <fantasai> chrishtr: With all that we propose to resolve on this?<br> <fantasai> astearns: So proposal is to add the backdrop-root proposal to the draft minus the rounded corners<br> <fantasai> chrishtr: and minus the part about backdrop-root causing containg block<br> <fantasai> fantasai: What are we doing?<br> <fantasai> chrishtr: We have a backdrop-filter property in the spec, we are adding concept of backdrop root<br> <AmeliaBR> Current spec definition: https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty<br> <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<br> <AmeliaBR> New section (plus other edits): https://mfreed7.github.io/fxtf-drafts/filter-effects-2/Overview.html#BackdropFilterProperty<br> <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<br> <fantasai> chrishtr: and it's drawn underneath the backdrop filter element clipped to its rounded border rect<br> <fantasai> chrishtr: That clarification about rounded border rect is also a clarification<br> <fantasai> Markus: Also defines order of operations wrt opacity, wasn't defiend before<br> <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<br> <fantasai> dino: Add an issue describing this<br> <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<br> <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<br> <hober> s/this is still under discussion/there is no consensus on having such a property/<br> <fantasai> [discussion of how to make an issue note in the spec]<br> <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,<br> <fantasai> astearns: Any objections to adding to spec with issue marker?<br> <fantasai> RESOLVED: Add the proposal with an issue<br> <florian> s/etc,/etc/<br> <fantasai> s/issue/issue noted in the spec/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-467152004 using your GitHub account
Received on Monday, 25 February 2019 19:37:23 UTC