- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Tue, 16 Jan 2018 05:30:36 +0000
- To: public-fxtf-archive@w3.org
Some filter effects rely on the fact that values are clamped after each operation. It is harder to create out-of-range channel values with the shorthand filters than with SVG filters, but you can still do it. The `contrast` filter is the only one that can create negative out-of-range values. What you're actually seeing with `hue-rotate` is too-high out-of-range values (greater than 255 when converted to RGB). Blown-out highlights like that can also be created with `brightness` and `sepia` filters. Here's an example of a filter effect that relies on `contrast()` values getting clamped: https://codepen.io/AmeliaBR/pen/zpJwYX?editors=0100 The real issue with the code @ConradIrwin posts is that the `hue-rotate()` filter is designed to preserve luminance while changing hue, and different hues have different potential luminance ranges within the RGB gamut. So when you rotate from a bright green to a blue hue, there is no way for blue to be as bright (by luminance measure) as the green was. The preserve-luminance adjustments are confusing in other situations, like trying to use `hue-rotate` to match an `hsl()` color (`hsl()` uses "lightness", not "luminance", treating the RGB channels equally; it's gamut directly matches the RGB gamut). Ideally, there would be an extra parameter to `hue-rotate` to switch it to preserve "lightness" instead of "luminance": ```css filter: hue-rotate(180deg lightness) ``` Since this would a new feature, instead of a change to default behavior, it could be added in a future level of the spec if there is sufficient interest. -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/221#issuecomment-357857911 using your GitHub account
Received on Tuesday, 16 January 2018 05:30:39 UTC