- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Mon, 19 Aug 2019 19:07:12 +0000
- To: public-fxtf-archive@w3.org
The definition of saturation values over 1.0 is fairly clear: using the same formula, multiply the saturation until the color channels max out. This is the "oversaturation" mentioned in the note. It works the same as the `saturate(n)` shorthand. The Chrome and Batik result for `values="99999"` match what I expect. Not sure what's going on with Firefox. The other browsers clearly haven't been updated since SVG 1.1: librSVG is treating it as an error that disables rendering, the others are clamping to 1 and therefore treating it as a no-op effect. But I'm not sure a negative value makes sense. It's [disallowed in the shorthand](https://drafts.fxtf.org/filter-effects/#funcdef-filter-saturate). It certainly doesn't make sense to say these values "undersaturate" beyond grayscale. If you substitute the value into the matrix equation, you end up inverting the colors and then applying the saturation factor. And that seems to be what Chrome and Batik are doing. Firefox is ignoring the negative value, treating it as a no-op. The others are clamping to 0. (librSVG again treating as a fatal error) The invert & saturate calculation is definitely the most consistent with the current spec text, although I'm not sure what the use case is. I'd also be OK with clamping to 0, or making negative values invalid (to match the shorthand). Either way, it definitely needs to be defined. -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/364#issuecomment-522713391 using your GitHub account
Received on Monday, 19 August 2019 19:07:14 UTC