- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 05 Mar 2021 18:03:44 +0000
- To: public-css-archive@w3.org
> cross-fade() does compositing, not interpolation I'm very confused - cross-fade() is literally the way that images interpolate. Implementation hasn't caught up, but when you transition background-image/etc, cross-fade() is just how you write the intermediate state. I'm not sure what distinction you're trying to draw here. Regardless, tho, my argument is at a different level - both of these functions are *mixing two (or more) things*. The fact that we can implement "mixing" as "scaling and adding" doesn't mean that "scaling and adding" is the correct mental model we should be exposing to authors; that's a leaky abstraction. Like cross-fade() does, the interface we should be exposing to authors is mixing-focused, and that implies certain things about how we interpret overconstrained % situations. Unless there's a *very* good reason otherwise, the various value-mixing operations should look as identical as possible to authors; giving authors bespoke mechanisms for what are, to them, identical operations with different value types is bad design on our part. If you think there's a very good reason why color-mix() should act like this, then presumably it applies to cross-fade() as well, and we should harmonize the specs. If you think there's a very good reason why color-mix() should act like this *that doesn't apply to mixing images*, I'd love to hear it, so I can be convinced that these mixing functions should indeed act differently from each other. But right now I see absolutely no difference between the two. cross-fade()'s definition of "linear weighted average of each pixel's colors, in premultiplied sRGB space" is mathematically the same as "scale and add (in a particular colorspace)", so any argument you can give for why colors should act in a certain way due to the underlying math would apply to images exactly as well. (Also, the > The percentages on both values are merely syntactic sugar to avoid authors having to manually subtract from 100%. It's still only one percentage really. I don't understand what you mean by this, either. Could you elaborate? Unless I'm misunderstanding, it's *omitting* a % that allows authors to avoid manually subtracting from 100%. ------- Tangentially, you had said in the call that there were reasons to limit color-mix() to only two colors, and I thought that I remembered you or Chris explaining why in one of the issues, but I can't find it now. Can you point me to it, or restate it? If the math of color-mix() is literally just "interpolate the components, via scaling and adding", then I'm not sure why three colors are problematic. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6047#issuecomment-791587768 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 5 March 2021 18:03:48 UTC