W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > February 2018

[fxtf-drafts] [filter-effects-2] Add a shorthand color-channel adjustment function similar to feComponentTransfer

From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
Date: Wed, 21 Feb 2018 18:41:20 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issues.opened-299082624-1519238479-sysbot+gh@w3.org>
AmeliaBR has just created a new issue for https://github.com/w3c/fxtf-drafts:

== [filter-effects-2] Add a shorthand color-channel adjustment function similar to feComponentTransfer ==
*As discussed in #178, and supported in [the resolution to close it](https://github.com/w3c/fxtf-drafts/issues/178#issuecomment-367412693).*

It would be useful to have shorthand functions that can:

- increase the alpha channel, not only reduce it like `opacity()` can
- perform additive modifications to brightness, saturation, and alpha, not only multiplicative ones
- adjust other individual channels

In other words, something similar to [`<feComponentTransfer>`](https://drafts.fxtf.org/filter-effects/#feComponentTransferElement), but hopefully without so much mathematical terminology.

I'd suggest that the design of this shorthand should be as consistent as possible with the syntax of the [Colors 4 `color-mod()` functions](https://drafts.csswg.org/css-color-4/#modifying-colors).  I think there is still some debate about what the final color-mod syntax will finally be, but right now it is `color-mod(<starting-color-or-hue> <color-adjuster-list>)`.

For a filter function, the starting value would be the input layer to the filter (aka, the output from the previous filter in the chain, or the painted element layer). A color adjuster list would then be applied for each pixel in the layer.

A few of the adjuster functions duplicate existing shorthand filter functions, but I don't see that as a problem.

Compared to `<feComponentTransfer>`, the color-adjuster functions would currently only recreate the _linear_ effects, not gamma curves or discrete effects&mdash;but again, I don't see that as a problem. Maybe in the future those calculations could be added to `color-mod()` if there is a demand. In the meantime, there is the longhand SVG filter option.

## Proposed syntax: 

Add new [`<filter-function>`](https://drafts.fxtf.org/filter-effects/#supported-filter-functions) `<color-adjust()>`, where:

___color-adjust()___ = __color-adjust(__ [`<color-adjuster>`](https://drafts.csswg.org/css-color-4/#typedef-color-adjuster)* __)__


## Example uses:

```css
/* increase drop-shadow opacity while maintaining spread from the blur
   (assuming original element had strict 0 or 1 opacity) */
filter: drop-shadow(navy 5px 5px 3px) color-adjust(alpha(*1.5)); 

/* the gooey effect
   (merges nearby shapes and colors & rounds corners, while recreating sharp edges) */
filter: blur(10px) color-adjust(alpha(-0.5) alpha(*400%));

/* asymmetrical contrast adjustment,
   clamping almost-black to black without losing detail in almost-white areas */
filter: color-adjust(rgb(-2%) rgb(*calc(100%/98)) );

/* white-balance adjustment, to create warmer hues */
filter: color-adjust(red(*110%) blue(*95%));
``` 



Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/256 using your GitHub account
Received on Wednesday, 21 February 2018 18:51:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 November 2018 00:46:00 UTC