- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Jun 2023 16:41:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] Should mix-blend-mode be a part of the ua opacity animation?`, and agreed to the following: * `RESOLVED: Move mix-blend-mode behavior into the UA opacity animation` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> vmpstr: in the UA stylesheet, we add an animation, a cross-fade that changes opacity of new and old pseudos<br> <TabAtkins> vmpstr: We also added mix-blend-mode:plus-lighter<br> <TabAtkins> vmpstr: This way if you have the same content on both sides it doesn't look like it fades in the middle<br> <TabAtkins> vmpstr: We found since devs can customize this, if they change it to anything but cross-fade they're surprised by the plus-lighter behavior<br> <TabAtkins> vmpstr: So proposal is to bundle the plus-lighter to be part of the animation<br> <TabAtkins> vmpstr: A separate set of keyframes that animates from plus-lighter to plus-lighter<br> <TabAtkins> vmpstr: And put that in the UA stylesheet, so when devs change the animation, they'll get rid of the mix-blend-mdoe automatically<br> <TabAtkins> vmpstr: Also right now mix-blend-mode is marked as not animatable, but aiui this is an oversight, so we need to change this to discretely animateable;<br> <khush> q+<br> <Rossen_> q<br> <Rossen_> ack Rossen_<br> <Rossen_> ack khush<br> <TabAtkins> khush: There's a few syntax options about where to put it in keyframes<br> <TabAtkins> khush: Form an impl perspective, we also add isolation ot the image-pair elements to get the cross-fade right<br> <TabAtkins> khush: If you have an isolated node and something below has a non-normal blend mode, you have to do an off-screen compositing.<br> <dbaron> +1 to the proposed changes; I think all 3 properties in https://drafts.fxtf.org/compositing/ should be Animation type: discrete rather than Animatable: no.<br> <TabAtkins> khush: That's a lot of rendering work to do if it's not necessary<br> <TabAtkins> khush: We convinced ourselves that keeping the isolation is fine; if you rmeove the mix-blend-mode it goes back to a fast rendering path<br> <emilio> q+<br> <TabAtkins> khush: So wanted to run this past the group<br> <TabAtkins> emilio: I guess the isolation isn't partiuclarly side-effect-ful bc things are already stacking contexts<br> <TabAtkins> emilio: But still probably less confusing to authors if we mix it with the opacity aniamtion?<br> <Rossen_> ack emilio<br> <TabAtkins> khush: We just couldn't figure out a CSS way to tie the ancestor's isolation to the child's animation<br> <TabAtkins> emilio: Not sure i follow<br> <TabAtkins> khush: By default you have isolation on ancestor and mix-blend-mode+opacity on the child<br> <TabAtkins> khush: If author is overriding the opacity animation, we wanna get rid of mix-blend-mode and isolation both<br> <TabAtkins> khush: We can easily get rid of mix-blend-mode, but not sure how to get rid of the isolation too<br> <TabAtkins> emilio: I see. If there's not a great way to do it, it's probably not a big deal.<br> <TabAtkins> khush: Right, we can optimize it out if ther'es no mix-blend-mode<br> <TabAtkins> emilio: I suppose if someone writes their own thing they might get confused, but if devtools shows the right thing it's probably okay<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to react to emilio to comment on one vs two rules<br> <TabAtkins> fantasai: Should we be creating two different sets of keyframes? Or one set?<br> <TabAtkins> vmpstr: I think one set makes sense so we're not creating too many UA keyframes<br> <TabAtkins> fantasai: So we have a proposed resolution?<br> <TabAtkins> vmpstr: proposed res is to move the mix-blend-mode behavior into the opacity transition<br> <TabAtkins> Rossen_: Objections?<br> <TabAtkins> RESOLVED: Move mix-blend-mode behavior into the UA opacity animation<br> <TabAtkins> fantasai: This depends on the props being discretely animatable; they are, but we changed the format of the animatable line in propdef<br> <TabAtkins> fantasai: "No" used to mean "discretely"; later we changed it to say "discrete" and "no" really meant no.<br> <TabAtkins> fantasai: TAb and I went thru CSSWG and fixed everything, but missed FXTF.<br> <TabAtkins> fantasai: So all of the fxtf drafts need fixing and repubbing<br> <TabAtkins> fantasai: But many have had changes and no active editor, so that's hard<br> <TabAtkins> Rossen_: This sounds like a big topic on its own, should track as separate issue<br> <TabAtkins> (I suggest we move into csswg as we repub them, but we should open an issue for it.)<br> <dbaron> can we at least resolve to fix the fxtf EDs per the previous edits?<br> <fantasai> I don't think you actually need a resolution, we already agreed to make those changes<br> <TabAtkins> vmpstr: Can I confirm that mix-blend-mode *is* meant to be animatable?<br> <TabAtkins> TabAtkins: Yes, absolutely<br> <TabAtkins> dbaron: Can we at least resolve to fix the FXTF EDs?<br> <TabAtkins> TabAtkins: Shouldn't need another, we already have a reoslution to fix this stuff<br> <TabAtkins> dbaron: And potentially houdini, tho I'm not sure they have properties<br> <dbaron> dbaron: and maybe also css-houdini-drafts if there are any properties in them<br> <TabAtkins> Rossen_: Let's just make a tracking issue for this<br> <TabAtkins> I'd take it on but I'm gonna be too busy the next week and a half before vacation<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8924#issuecomment-1591630313 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 June 2023 16:41:50 UTC