Re: [fxtf-drafts] [filter-effects-2] Add recolor() shorthand (#334)

I like this a lot!

So, duotone() and tritone() seem great directly as stated. Useful, easy to understand, good names.

For the single-color ones, functionality seems good, but naming is harder.

So, tint() technically means "adding white to a base color", lightening it. (And its opposite, "shade", means to darken a color by adding black.) So saying `tint(red)` to mean "turn all the white into red" is somewhat wrong; it's the reverse of what "tinting red" should mean.

(People do casually use "tint" in these sorts of ways, but it's extremely varied; if we're relying on casual definitions, we can't rely on a meaningful distinction between "tint" and "shade" to distinguish our "shift black towards the color" from "shift white towards the color" functions.)

I suggest we avoid the issue entirely by just not providing the single-color functions. People can just write `duotone(<color>, white)` if they want a sepia-like effect, or `duotone(black, <color>)` if they want to do the opposite.

(Unlike the "you can implement duotone() with tritone()" argument, where you need to do some color math to make it happen, this requires no math. You just fill in one of the arguments with "white" or "black". That seems easy enough to make it reasonable to skip on providing a convenience function.)

--------

I agree that Apple's "tint" doesn't need a convenience function, as tritone() seems to handle it just fine.

I'm not even sure what the Android Lighting thing is doing, semantically. I always look askance at anything trying to add/multiply individual channels; it's smuggling in masking data via color channels in a way that doesn't feel very kosher.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/334#issuecomment-491068592 using your GitHub account

Received on Thursday, 9 May 2019 21:13:32 UTC